Forum Moderators: buckworks
The CVV, expiration date, and card number were all checked and generated an error if filled out wrong, except two fields I could enter whatever I wanted:
Cardholder name...I put in mickey mouse for a cardholder name and no error was generated. Will this transaction be declined with it is sent to be settled?
The cardtype also did not seem to affect the transaction (I entered Mastercard although my card is a Visa).
I called up authorize.net and they said this is correct, those two fields are never checked. Is this really how it is supposed to work? If so, what are those two fields even for if they are never checked?
Card matching is pretty much irrelevant. You can add a bit of JavaScript to check that the card matches Visa or MC; all Visas start with a 4, all MC start with 5, and so forth. But you're only really interested in the validity of the card number, matching street address number, mathcing zip code, and matching CVV, which is what your processor is checking - and about all that you can do.
The main point of specifically asking people if they are using Visa or MC, is to make clear the point that you don't take Amex or Discover. (Or maybe you do, but it doesn't really matter.) Card/address/CVV verification is 'strictly by the numbers'.
You'll get lots of people that have credit cards associated with a street address, and they give a PO Box, or vice versa. The checks are simply matching valid numbers. You'll want your design to ensure that people distinguish between their actual 'official' credit card address, and the shipping address. It may even be the same location, but people just don't understand that if the numbers don't match, the order can get kicked out. (No end to the number of people that barely know where they live:))
I've seen some merchants uncheck practically every security option, i.e., if the card number is valid, they'll handle the transaction on that basis alone - taking their chances on fraud and chargebacks.
For my own accounts, I require most all matching options - but am on the hook regardless. If a charge goes bad, the merchant can plan on holding the short straw:))
A lot depends upon the niches and price points. Some products and services are fraud targets (magnets) - and I've seen others that have never had a single fraud or chargeback situation.
Every card number has a checksum and exp. If either of these are entered wrong authorize.net will return an error.
On CVV - we do not refuse a charge based on CVV no-match provided we get a Y or X in AVS. On a lot of older card the CVV may be partially worn off and the customer will enter what he thinks is the right number (or 000). Whatever they enter for CVV will either be a match or no-match on the charge receipt so it's probably not a good idea to setup auto-rejection for an incorrect CVV number.
In our setup we decline charges that return AVS N or G. Often a customer will use a wrong address on placing an order and then get a bad address error message. Then they read that we require the actual billing address so they enter that and it goes thru. Not sure if you know this but even tho we decline the charge it still goes thru as an authorization on the cardholders account. So if your setup declines a charge and the customer calls you to complain about being double billed then you generally have 1 settled charge and 1 authorization that will auto-delete from the customers account usually in 2-3 days.
.
