Explaining Credit Card Declines to Your Customers

I want to take some time to talk about something I find to be important in so many ways – explaining credit card authorizations and declines to your customers. This is child to the broader parent topic of handling your customers’ money, something I’ll likely write about in a number of sessions at a later date. For now, let’s focus on simplifying and understanding what happens when your customers attempt to use their credit card on your e-commerce site. After that, we’ll review some best practices for communicating these processes to your customer.

Please see my References section at the bottom for off-the-top-of-my-head notes and definitions as we go along.

And please remember that this topic involves aspects of fraud, security, and other people’s money.  These are my opinions that are based on my experience.  As such, you should never follow my advise directly, and instead always use judgment unique to your circumstances.

Online Credit Card Use – What Happens Behind the Scenes

Here we go! First an important note: This is a complicated a varied process. There is a great deal of documentation available online, particularly on Wikipedia, about this process. There may also be steps and processes that are included or skipped depending on your card processor and the nature of the transaction. For now though, let’s focus on the basics.

Commit this to memory: the only thing you need to get a credit card authorization is the credit card number. All other data fields (expiration, CVV2, address, name, etc.) are security measures that you should utilize.

Unfortunately, the more data fields you utilize for security, the more opportunities the customer has to enter erroneous information which results in their transaction being flagged for review. These flagged transactions still result in authorizations, and it’s these authorizations that the customer sees as “charges,” which further result in angry phone calls and e-mails.

The most common piece of data entered erroneously is the billing address. This security check, part of the AVS, is sent to the customer’s bank as the following simple question:

“How does this address supplied by the customer compare to the one you guys have on file?”

The bank then responds in a variety of ways. Here are some typical response codes, worded in a way that may help you remember them:

Y – Yes; The street address and ZIP code both match.
N – No; The street address and ZIP code are BOTH incorrect.
Z – ZIP code is correct, but the street address is not.
A – Address (street number) matches, but postal code does not.

Recall: the only thing required to get a credit card authorization is the number.

This means that regardless of your choice to accept or reject transactions based on AVS responses, the bank will still issue an authorization, and funds will still be allocated away from the customer’s account. Many e-commerce platforms support the ability to display AVS responses to the customer. The store may not specifically say “AVS: N,” but may simply say “AVS error” or “AVS failure” instead, halt the order, and provide the customer with an opportunity to re-enter his or her payment information.

Unfortunately, customers don’t know what AVS is, and will typically re-submit their erroneous information again and again – resulting in more authorizations, more funds allocated away from their account, more angry calls, and no completed order.

Causes and Explanations

Why do customers provide the wrong billing address? Don’t they know what address is on file with their bank?

In short – No. Likewise, some people don’t know they’re out of clean underwear until the drawer is completely empty. But in any case, mistakes can be made. Here are some:

The customer recently moved
This is by far the most common reason for AVS failure, and it has happened to me several times. Sometimes the customer moves without notifying their bank of their new address, yet uses that new address as their billing address. Conversely, the customer may notify their bank of an address change, and use that new address on their order, but AVS fails because the change hasn’t propagated through the bank’s records.

Misunderstanding of the word “bill”
Some customers think “billing address” means the address their bill (or receipt) will be sent to. This happens more than you may think.

Numbered street names
Another important note is this: When an address is queried as part of AVS: Only the numbers are checked. Here’s an example:

Submitted Address (as input by customer):
123 Home Street
City, State, 12345

What the bank sees:
Street: 123
ZIP: 12345

So, submitting a numbered street has the following implication:

Submitted Address (as input by customer):
123 W. 89th Street
City, State, 12345

What the bank sees:
Street: 123 89
ZIP: 12345

This, of course, would return an AVS response of Z; the ZIP code matches, but not the street. In this case, this response is a false positive. Clearly, the customer submitted the correct information, but the response indicates a partial match due to the nature of what information is transmitted and referenced. If your software is set up to decline orders with an AVS response of “Z” – then an order will not be created, and the customer may be presented with the payment entry screen again. And, once again, another chance for an error-based authorization is presented.

Communication and Damage Control

So let’s say that you do, in fact, have your software set up to flag AVS:Z responses. Our honest, eager-to-buy customer on 89th Street has tried several times to purchase from you. He’s finally given up and moved on to your competitor’s site. Now that he’s found a site that will take his information, his card declines again – this time due to insufficient funds. He checks his bank account online and sees that there are 5 or 6 pending “charges” from your business. Of course, he’s going to call you. Here are some simple do’s and don’ts of interacting with these customers:

DO: Sound apologetic and empathetic.
DO NOT: Sound robotic, scripted, and disinterested.
Few things get under my skin more than when I’m being read a call script instead of getting individual and unique attention. “I’m so sorry to hear that you are experiencing difficulties with our blah blah Mr. Peckenpaugh (and they can never pronounce my last name correctly)… I will do my best to assist you in this matter of bluh bluh…” Ugh. You don’t know me, and I’m not your boss. Please don’t talk to me like that.

DO: Assume good faith.
DO NOT: Assume you’re talking to a fraudster.
If you stole someone’s credit card, decided to use it online, and racked up a bunch of authorizations by failing security checks, would you call the merchant and grief about your experience? Not likely. Yes – it happens, but not nearly as often as honest mistakes. Treat the customer accordingly.

DO: Ensure the customer that they’re talking to the right person.
“Im sorry this has happened, Mike, but you’re talking to the right person. I’ll have all this sorted out for you by the time we’re off the phone.”
DO NOT: Immediately refer the customer to their bank.
“Well, those transactions were not approved, so we won’t collect them. You will need to talk to your bank about getting that money put back in your account.”

Don’t talk to the customer this way. They’re missing a lot of money, they’re convinced you have it and owe it to them, and they’ve already sifted through your touch tone answering service and waited in your call queue while the rest of their life buzzes by. Log in, reverse their authorizations, and thank them for their business.

At the same time, it is important to educate the customer on the fact that your authorization reversal may not be instant. In fact, each bank has their own rules and policies on authorization reversals. There have been times that I’ve had a customer on the phone, clicked for a reversal, and the change was reflected instantly on the customer’s online account. There have also been times when the reversal has taken days to go through.

With this in mind, I frequently smooth things over by saying this to the customer:

“So, I click some buttons here, and this is my way of telling your bank that we don’t intend to collect that money, and to please put it back on your account. How quickly that happens is up to them, and every bank has different rules for this, so I hope they treat you like a good customer and do it quickly.”

How can you argue with that?

Preventing Mass Repeat Authorizations
I once logged into a payment terminal and saw 18 pending authorizations from one customer – over $4200 in AVS-failed transactions allocated to the void. Aside from the fact that the customer’s credit card company should never have allowed that many attempts to pass through, it prompted me to take some steps to prevent it from happening any more.

Your e-commerce software should have configuration variables to prevent duplicate orders, or a maximum order quantity. I typically set the maximum order (attempt) quantity to 5 – this leaves room to make mistakes and corrections without giving the customer a way to rack up authorizations ad infinitum.

References and Terminology

(An) Authorization – An Authorization is an “all clear” from the customer’s bank or credit card company. They’ve said, “Yep – that’s one of our accounts. You need money from it? Okay, here.” This action issues an Auth(orization) code and allocates funds away from the customer’s account – into a sort of temporary holding limbo where they are reserved for you. When you settle your batch, you convert these authorizations into sales, and the money is transferred to your account.

AVS – Address Verification System. In short, an automated behind the scenes system that returns response codes to the question “Does this billing address match the billing address on file with the bank / credit card company?”
See Wikipedia’s article

Billing Address – This is the address that the customer’s bank or credit card company has on file.

CVV2 – 3-digit numeric code printed on the back of the card. 4-digits for AMEX. Also called CVV, CVC2, CVN, etc.
See Wikipedia’s article

Decline – True declines come as responses from the bank or processor, typically for “insufficient funds” or “do not honor.” These are rare, because people tend to be more aware of their available funds now days. There is nothing you can do to make these transaction go through. Most of what we call declines are actually Flagged transactions…

(Finalized) Charge – There are just as many terms for this as there are mis-usages, but they all mean the same thing – the customer’s money is now in your account – or – has been irrevocably directed/deposited to your account. This can ONLY be undone with a Refund.

Flagged (for review) – Transactions flagged for review are fairly common and simple to understand. Somewhere in your card processing software, you have criteria that must be met for the transaction to go through. A flagged transaction is simply one in which some of that criteria was not satisfied. Wrong CVV2, expired card, billing address mismatch, etc. Flagged transactions produce Authorizations, and multiple order attempts with erroneous data produce more authorizations.

(Authorization) Reversal – This varies by processor. On most modern platforms, this is a couple mouse clicks that reverses a pending authorization.  Do this when you see fit to keep from holding the customer’s funds for too long.

Settle (the batch) – All approved authorizations are converted to sales in a batch. You tell the bank “Take all the money that’s reserved for me on these authorizations and deposit them in my account.”

Shipping Address – The address the customer wants their order to be shipped to. This could be anywhere. Not on file with banks.

About Dean Peckenpaugh

Dean offers small business consulting services at DeanP, LLC - specializing in e-commerce and operations. Visit the contact page to request a consultation.