Bank response codes explained

A payment may fail for many reasons. Response codes tell merchants why. Maybe it was because of insufficient funds, an expired card or fraud. Whatever the reason, response codes are generated every time an issuing bank approves or declines a transaction.

Response codes are extremely powerful data points as they tell a merchant precisely why an issuing bank has refused to authorize a transaction. Yet, unfortunately, most businesses are in the dark about what happens after their customers’ press pay. They may see that the payment was approved or declined, but they do not know why. 

Our research finds that 65% of businesses don’t receive detailed raw response codes on failed payments. This ranges from receiving no response codes to grouped response codes that only provide a generic overview of why payments have failed.

What are bank response codes?

Whenever you attempt to process a card transaction for a customer, you initiate a request to the issuing bank that details the purchase amount and relevant cardholder details. The bank reviews this information against their data and decides whether the transaction should be approved or declined, whether the cardholder needs to take further action, or whether you should retry the payment. This decision is then relayed to you in the form of a bank response code, a short letter or number sequence that’s displayed on your card terminal or in your payment processing software.

There are more than a hundred different response codes. They can indicate anything from successful payment to insufficient funds or even attempted fraud. It’s up to you to interpret the code and decide how to proceed. Sometimes a description is offered alongside the code, but not always, and often the interpretation isn’t obvious. That’s why it’s worthwhile for merchants to familiarize themselves with some of the most common response codes. 

For example, let's say you’re attempting to process a customer payment and the bank returns the code 05, meaning ‘Do Not Honor’. This is one of the most common codes for declined transactions and could be the result of mistyping, insufficient funds, or a failed security check. In this case, you can ask the customer to attempt the payment again using a different card.

Common reasons for payment failure

‍

1. Lack of funds
2. Expired card
3. Authentication required
4. Blocked for fraud
5. Account restricted

Learn more about why payments fail and what you can do about it.

Not having access to detailed transaction response codes is a problem for merchants. If they don’t know why the payment has failed, they cannot understand what to do about it. Should they retry the transaction? Was it actually fraudulent? Are they blacklisted by an issuer? Or is there a deeper underlying problem that needs solving?

These are fundamental questions for merchants to answer. If they can’t, it’s unlikely they’ll be able to build strategies that improve their authorization rates. This’ll mean they continue missing out on legitimate sales, impacting revenues and the business’s growth potential. 

And let’s not forget how sensitive consumers are to an inadequate payments experience. Our research finds that 33% of consumers have been permanently put off shopping on a site because their payment was declined. And more often than not, they will simply spend money with a competitor. In other words, a merchant is actively handing their competition a strategic advantage.

Super high growth (41%+ YoY) companies are 6.5% more likely to have an authorization rate of 96-100% than other businesses surveyed.

Why getting data about bank response codes is important

Understanding the payments value chain may help illustrate why so many businesses struggle to access the data they need.

Typically, a business connects to a gateway, which aggregates for multiple businesses, feeding into one or more acquiring banks. The acquirer uses a processing platform to interface into Visa and Mastercard, which in turn communicates with issuing banks. 

There are many different platforms and technologies between the business and the card issuer in this traditional model of payments. They’re in the transaction’s way, so to speak.

A vast amount of data may be sent in the authorization response. But the processing systems used by banks may be up to 30 years old and cannot retain and pass the data. A data set may be up to 90% diluted. And if merchants only see 10% of the data, it'll impact the accuracy of their decision-making.

That’s the challenge with payments. Data is often tantalizingly out of reach. Either it’s trapped in the web of interconnected systems and silos that make up legacy payment infrastructures. Or it’s consolidated and oversimplified by providers who are focused on serving the needs of smaller businesses that only need the most basic level of insights.

A full-stack acquirer that owns its technology end-to-end can set the transaction flags to know how the message actually gets to the issuer. And can pull off data on the payment at every point in its journey.

Get the data needed to drive improved payments performance with Checkout.com

Merchants that are serious about improving their payments performance — and thus supercharging their sales, revenues and business growth — must prioritize working with a payments partner that gives them access to raw response codes.

Download our guide to learn more. And find out how to optimize authorization rates with access to meaningful payments data.