Hmmmm ive just made quite a shocking discovery (well shocking to me anyway).

My friend wanted a couple of domain names, and given the current Netfirms pricing and their half decent control panel, i recommended he went with them as he wanted them as cheap as possible.

Anyway, he went home and then phoned me up to ask me to register them for him (he hasnt got a credit card) and he would give me the cash etc when he see's me, so I did.

When I completed the purchase, I realised I had selected his name and address as the billing information for the credit card, which obviously isnt correct as its my card.

Upon recieving the invoice, I also realised the post code was slightly incorrect, and after checking the post code on the Royal Mail website, I found out it is not a valid postcode.

Since Netfirms manually process all transactions (well they say they do), I expected them to contact me to inform me the details where incorrect/card declined and advise me of what action to take next.

Anyway, a few hours later the account had gone through the payment authorization process and was now fully active, as where the domain names registered.

I have just checked my bank statements online, and wow, the payment has been taken.

Now obviously Netfirms are not at fault here, because this is down to the payment processor, and maybe this is a usual thing to happen, but how can they take a payment off a credit card, with not only an incorrect billing name and address, but also an invalid address anyway??

I am quite shocked that this payment has gone through (not bothered obviously about the payment, but I will be ringing the HSBC on Tuesday to find out where the payment was billed to on their records and how the transaction went through without problems).

Comments?? :confused:

Not all merchants are required to use Address Verification. Personally, I think they are crazy if they don't, but for some reason they apparently have chosen not to use it. Why not just call NetFirms and ask them why?

Now obviously Netfirms are not at fault here, because this is down to the payment processor

Actually it's the other way around. The merchant choses what policies to implement as far as accepting transactions, from very liberal (as apparently is the case here) to rigorous. At a minimum you only need to have the correct card number and expiration date; anything after that is up to the merchant to use in the decision-making process. Typically the merchant can set these rules via a web-based interface for their payment processor.

I haven't used all payment processors, but I'm familiar with many, and I'm not aware of any that actually validate to see if an address is correct (i.e. doing a Postal Service database lookup). AVS validates if the address provided matches what is on file with the card issuing bank, but not if the address is actually valid.

Actually it's the other way around. The merchant choses what policies to implement as far as accepting transactions, from very liberal (as apparently is the case here) to rigorous. At a minimum you only need to have the correct card number and expiration date; anything after that is up to the merchant to use in the decision-making process. Typically the merchant can set these rules via a web-based interface for their payment processor.

I haven't used all payment processors, but I'm familiar with many, and I'm not aware of any that actually validate to see if an address is correct (i.e. doing a Postal Service database lookup). AVS validates if the address provided matches what is on file with the card issuing bank, but not if the address is actually valid.
That's obviously true.

One provider of mine charges me by using just the CC No. and Expiration.

The rest charge me with CC No., CC Expiration and CVV Code.

I don't think they check the Billing Address. I haven't typed the wrong one yet but there can be typos.

That's why at other places I use Virtual CCs. They expire after single use and also you can pre-fill them with the amount which you'll be paying.

Thanks for the insight into how the system works guys, its much appreciated.

Why don't payment processors check basic things like the address of the cardholder matching that on file with the card issuer?

In this world of huge online fraud, should it not be compulsary for it to be checked? What is actually gained by not having these checks (other then it lets fraudsters in their illegal activities)??

It should be a basic feature imho. I am quite angry about this, because it means that should a card be robbed by a fraudster, they can spend on it with ease.

:(

There are two possible reasons why a merchant would not use AVS.

1) They may have to pay a fee in order to use AVS. (Lame reason, imho, because ultimately it is the merchant that pays for fraud, not the cardholder, and not the banks.)

2) Not all banks are quick to update AVS when a customer changes their address. This results in angry customers who don't understand why their transactions are being declined. Sometimes merchants just get fed up with it and turn it off altogether. (Still kind of a lame reason.)

Also, not all banks support AVS. I have two clients in Canada whose credit card companies are AVS-not-available. No idea why -- they just are that way. We quickly discovered that if we left AVS matching enabled on Authorize.net, that these two clients' payments were declined every month (because the system read it as a "mismatch"). Well, that's an inexcusable inconvenience to my clients... they are good people and they have done nothing wrong. They are providing legitimate CC info that does charge through successfully and appropriately when the restrictions are turned off.

Authorize.net does still check and report on whether the AVS matches or not. It's just that the transaction won't fail if they don't match. We have a very stringent manual fraud screening procedure in-house, and looking at the AVS result is just one of many things we check. So it is still checked ... it's just a question of whether or not:

(1) the merchant is choosing to auto-decline any transaction that doesn't match; or

(2) the merchant is doing a manual fraud screening and voids transactions which fail that screening.


Personally, if I was in your shoes, I would be more upset that Netfirms didn't find the inconsistencies sufficient to decline the transaction. The payment processing "system" is checking the data on every transaction... the question is, why didn't the merchant catch the problem??

:D Bailey

Lol, I should add that I have bought domains off Netfirms before using the exact same card, but with the proper credit card name and address, im actually shocked they didnt pick that up on their records either.

But they may not keep records, im not sure if their allowed to anyway??

Im gonna send them an email me thinks...

:)

I highly doubt they manually cross-reference every name and credit card number that comes through... that is something that would have to be done manually, and it is really not reasonable to expect it of them. It's just not a normal sort of data operation that merchants do. It is normal to screen transactions on a per-transaction (independent) basis, but only really extraordinary circumstances would trigger a manual review of a customer's (or CC number's) super-detailed history.

:D Bailey

the question is, why didn't the merchant catch the problem??

Probably because they don't see it as a problem until something happens.

As was mentioned earlier in this thread, it is up to the merchant how carefully they want to screen their orders before accepting them. The issue here is not a Visa or MasterCard or acquiring bank issue but a merchant-level decision that was made by the company in question.

The tools are readily available by which merchants can protect themselves substantially against fraud losses. AVS - which only works in the U.S./U.K., CVV - which works on all cards, Verified by Visa/MasterCard SecureCode, automated phone authentication tools, BIN/GEO/IP scrubbing and negative databases - these are all readily available at low or no cost to merchants to use.

The reasons WHY a given merchant does not use some or all of them can vary - sometimes they simply don't care or haven't run into an issue yet, other times you have merchants that are afraid that they will lose customers if they make them go through too many hoops and that the occasional fraud loss is less of a cost than the cost of lost sales.

However, more and more merchants are coming to the realization that with technologies like those listed above - you really do get the best of both worlds. You scrub out almost all of the fraud, you do NOT get false declines and the customer is NOT put through hoops.

AVS is an archaic fraud tool but it should be relied upon. Depending on your business, some companies might rely on it 100%.

But if Netfirms processes each transaction manually, I don't see how it can be the processor's fault. The electronic payment gateway sends back information, i.e. if the AVS matched; if the CVV2 / CVC2 / CID matched, etc. It is then up to the merchant to scrub the transaction (more) if needed / desired.

CVV - which works on all cards

I was recently doing some follow up consulting for a mid-sized e-commerce merchant (25k transactions/month, around $20m in sales per year), and I was surprised to see a decent percentage of cards (especially Amex) not supporting CVV. Has that been your experience as well?