Richard Rottman, one of our colleagues, wrote a great piece about chargebacks in his blog. For the benefit of our developer community, here it is.
When a brick-and-mortar merchant accepts a credit card for payment, the expectation on the part of the bank is that the customer will physically hand over the card for processing. The merchant then either swipes or inserts the card into a physical terminal so data stored on the card can be read and sent to the bank. This data, along with other information, assists the bank in deciding whether the transaction should be approved or declined.
Reading the card’s stored data, among other things, lets the bank know the credit card was physically present for the transaction. When a card is present at the time of the purchase, it’s extremely difficult for the cardholder to initiate a chargeback.
After the credit card is approved, the customer signs the receipt. The merchant can then compare the signature to the signature on the back of the credit card. This verifies that your customer is, in fact, the person the bank issued the credit card to.
In theory at least.
With e-commerce transactions, when a customer pays with a credit card, reading the data on the credit card is not an option. The e-commerce never sees the customer, let alone the physical card. The e-commerce customer’s signature cannot be obtained or compared to the signature on the back of the credit card.
Considering that a cardholder can initiate a chargeback on a transaction, even though the issuing bank approved it, these inherent limitations place an e-commerce merchant at a distinct disadvantage compared to their brick-and-mortar counterparts.
The credit card industry introduced extra tools that allow e-commerce merchants to verify a credit card. In this tutorial, I will show you how to use these tools.
Address Verification System
The first tool e-commerce merchants have available is the Address Verification System or AVS for short. It’s a system that verifies an address provided by the cardholder with the address the bank has on record.
Something to keep in mind is that AVS only checks the street address and the postal code.
It doesn’t check the street name.
It doesn’t check the city.
It doesn’t check the state.
It doesn’t check the country.
Even with the street address, it checks only the numbers, not the words or even the letters in the street address.
The means if the street address is 2120 Midlake Drive, AVS only checks 2120. The customer could enter 2120 Midlake Drive or 2120 Elmer Fudd Drive, and AVS will return the same positive response.
When submitting a credit card for approval, AVS will return a one-letter code to indicate the results. These codes are:
Y – The street address and the postal code match.
N – The street address and the postal code do not match.
Z – The street address doesn’t match, but the postal code does.
A – The street address matches, but the postal code does not.
Keep in mind that a bank will approve or decline a credit card independent of AVS. The issuing bank makes its decision without considering AVS. As an e-commerce merchant accepting a credit card for payment, the responsibility for considering the AVS results is solely yours. AVS is a tool for the merchant, not the bank.
Another aspect to consider with AVS is that it’s only supported by banks in the United States, Canada, and Great Britain. That means if your customer is using a credit card issued by Indonesia or Germany, AVS will not be applied to the transaction.
Card Security Code
The other tool e-commerce merchants have available to them is the Card Security Code. It’s often referred to as CVV2 or CID. On Visa, Mastercard, and Discover, it’s a 3-digit number located on the back of the card. With American Express, it’s a 4-digit number on the front of the card.
A unique aspect of the security code is that the only place it appears is printed on the card. It’s not on the magnetic strip or the EMV chip. It doesn’t appear in the transaction information. It’s never used for face-to-face transactions. It’s against credit card industry rules for a merchant to record or retain this number. It’s only to be supplied by the cardholder at the time of the transaction.
When submitting a credit card for approval with a security code, the issuing bank will return a one-letter code to indicate the security code results. These codes are:
M – The code submitted matches.
N – The code submitted does not match.
P – Card expiration not provided or card does not have a valid security code.
S – Merchant indicated the security code is not present on the card.
U – Card issuer is not certified for card security code verification.
I – Card security code is invalid or empty.
As with AVS, the issuing bank will approve or decline a card regardless of the outcome of the card security code check. The responsibility for accepting the card for payment is placed solely on the merchant.
E-Commerce merchants should be highly suspicious of any credit card payment where the address and the card security code doesn’t match what the bank has in its records. Just because the bank approved it, doesn’t mean the transaction cannot be reversed in a chargeback. If a customer initiates a chargeback, and the transaction record shows that the address didn’t match or that the card security code didn’t match, the chargeback will almost always be decided for the cardholder.
You don’t want that. Sometimes the best transaction to make with a customer is no transaction at all. Take advantage of AVS and the security code check and avoid getting unnecessary chargebacks.