Several months back, I was testing an application’s ability to charge credit cards before going live with it. The application allowed people to make one-time purchases, purchases using a previously saved credit card, and subscription purchases wherein people’s credit card information was saved for future use. Like many sites, we used a third party to charge and store the credit card information securely. (In our case we used Authorize.Net Customer Information Manager–also known as CIM.)
As a part of my testing, I employed the use of VISA, MasterCard, and American Express gift cards to make sure they worked too. We didn’t want to miss-out on any potential purchases. However, we ran into a curious situation when using gift cards as saved cards: the first transaction would be approved but any subsequent attempts would always be declined.
I spent the majority of a day talking with our merchant gateway (Authorize.Net), our payment processor, and the gift card issuing banks to try to understand what in the world was going on. Just like any perfectly-executed Department of Defense project, not one person knew or could explain the big picture. Each person could only tell me what they knew about my declined test transactions and point fingers at someone else. After speaking with everyone, though, I was able to extract what was going on.
To make a transaction with a credit card online or in the real world, you must provide a piece of verifying information. There are two options: (1) the 3-digit security code on the back of the card or (2) your physical address.
The catch about using your physical address for a gift card purchase is that you must first register the gift card with the issuing bank so that they have your address on file to verify it. The problem with address verification is that virtually no one registers their gift cards. (I didn’t even know it was possible.)
The problem with security codes is that no one other than the issuing bank is allowed to store it. The merchant gateway might capture and send along the code when making the initial purchase and even storing the card. However, it will never be available for subsequent transactions. This is why our gift cards were being declined when used as saved credit cards. We were sending the customer’s address to the payment gateway, but the issuing bank didn’t have an address on file to verify. And we couldn’t send the security code because Authorize.Net hadn’t stored it.
So, what could be done? Well, we couldn’t just reject gift cards on our site because there is no way to determine if the card is a credit card or gift card. (The only people who know this information is the card holder and the issuing bank. Credit card processors and banks are agnostic.) We could require the customer to provide a security code on every saved credit card transaction or subscription transaction, but that inconvenience to all of our customers would defeat the purpose of storing credit cards for automatic processing. The only viable option was to tell customers to register their gift cards with their issuing bank if they wish to use a gift card as a saved card or for subscriptions.
Hindsight is 20/20, so this makes perfect sense. However, it was quite confusing before the epiphany. Hopefully this will save some others a day of investigation.