Decoding decline codes

Payment declines are an inevitable part of accepting online payments, and let’s be honest—they’re incredibly frustrating. Not only do you risk losing a sale, but your customers also face the annoyance of being unable to complete their transactions.

However, as a merchant, there are steps you can take to minimize frustration and maximize the success of each transaction. It all begins with understanding why your payments are failing in the first place.

Step forward: decline codes

In this article, we’ll explain what decline codes are, the most common ones merchants encounter, how payment service providers manage them, the complexity they add in a multi-acquirer environment, and how Primer helps you use these codes to optimize your payment strategies.

What is a decline code? 

Let’s start with the basics: a decline code is a two- to three-digit alphanumeric reference indicating why a card transaction was rejected. The payment schemes define these codes.

Visa and Mastercard generally use the same numbers for similar payment failures. For example, code 14 means “invalid card number” for both.

However, there are instances where they diverge. Visa's code 65 indicates “authentication required,” while Mastercard uses code 1A for the same issue.

Adding American Express into the mix complicates things further. American Express has its own set of error codes, which are three digits long. For example, code 100 is a generic decline, while code 101 indicates an expired card.

Five common decline codes

Here are five of the most common payment decline codes that you’ll see when processing Visa and Mastercard payments. 

• Code 65 (credit limit exceeded). You have exceeded the credit limit on your card, and the limit may be daily, weekly, or monthly. 
• Code 51 (insufficient funds). You don’t have sufficient funds in your account to pay for the transaction.
• Code 54 (expired card). Your card is no longer valid because it is out of date. 
• Code 97 (invalid CCV). The wrong card verification value has been used. This can also trigger code 63 (security violation).
• Code 05 (do not honor). The card issuer’s bank stopped the transaction and told the merchant not to accept (‘honor’) the payment). Follow-up is required with the bank to explain why.

The journey of a decline code

While card schemes define decline codes, they do not generate or transmit them when a payment fails. Here’s what actually happens:

Imagine Billy is buying trainers for $100 but only has $95 in his account. The issuing bank will likely decline the transaction due to insufficient funds.

To communicate this up the chain, the issuer will send decline code 51 to the merchant's acquirer, who will then communicate this to the merchant. It’s then up to the merchant, and the logic is built to determine what happens next. 

Typically, in the case of insufficient funds, that will be encouraging Billy to use an alternative payment method.

Why payment processors translate decline codes

To drive standardization and provide clarity for merchants, payment service providers have mapped each decline code to a specific set of decline reasons.

For example, here’s what you’ll see if you’re using Stripe, Adyen, and Braintree and a payment is declined due to insufficient funds:

• Adyen: 12 Not enough balance
• Braintree: 2001 Insufficient Funds
• Stripe: insufficient_funds

This is great when you’re using a single processor for your payments because you get a unified view of all your decline reasons. But, as you can see, they’re very different from one another. 

And, once you start using more than one processor, things begin to get complicated again. Each processor defines declines differently, forcing merchants to build logic into their payment systems to handle declines uniformly.

Speaking with merchants globally regularly, I know just how complex and time-consuming this is. And that’s without considering the challenges it creates around reporting and data analysis. 

How Primer unifies and simplifies decline code reasoning

Cutting through this complexity is one of the key reasons merchants choose Primer.

Following our mission to unify the language of payment we’ve developed a Unified Mapping Standard. The difference is this unifies the decline codes across all processors and payment methods we integrate with. This means that you, as a merchant, only have to understand decline codes in one way: the Primer way. 

This provides a ton of advantages for merchants using Primer. Not least, throwing away all the unnecessary complex logic they’ve built in their back end to interpret and reason with how each individual processor communicates decline reasons. 

It also you to:  

• Create automated workflows to handle decline scenarios, such as sending an automated email to the customer for every decline due to insufficient funds.  
• View aggregated data insights for every decline to identify trends and areas for improvement in our Observability platform. 
• Trigger fallbacks only for certain decline scenarios.
• Trigger 3DS only for certain decline scenarios.
• Monitor decline reasons to stay abreast of changes in processor responses. 

It’s also worth noting that Primer isn’t a black box. Yes, we have our own decline mapping standard, but we also surface the response code delivered by the processor on the Primer dashboard allowing you to build logic around to enable edge cases if necessary.

Make decline codes part of your payment optimization strategy 

Decline codes are a vital tool for every merchant's payment processing strategy, allowing you to maximize your payment performance. Yet, they’re also an area of huge complexity for many, preventing them from realizing their full potential.

Learn more about how Primer is cutting through payment complexity by unifying the language of payments.