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 face the annoyance of being unable to complete their purchase.
As a merchant, there are steps you can take to minimize that frustration and maximize the success of each transaction. It all begins with understanding why your payments are failing in the first place, and that means understanding 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?
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. Code 14, for example, means ‘invalid card number’ for both.
There are instances where they diverge, though. 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. Amex has its own set of error codes, which are three digits long. Code 100 is a generic decline; code 101 indicates an expired card.
Five common decline codes
Here are five of the most common payment decline codes you'll encounter when processing Visa and Mastercard payments.
- Code 65 (credit limit exceeded): The cardholder has exceeded their credit limit, which may be daily, weekly, or monthly
- Code 51 (insufficient funds): The account doesn't have enough funds to cover the transaction
- Code 54 (expired card): The card is no longer valid
- Code 97 (invalid CCV): The wrong Card Verification Value has been entered. This can also trigger code 63 (security violation)
- Code 05 (do not honor): The issuing bank has blocked the transaction and instructed the merchant not to accept the payment. Follow-up with the bank is required to understand why
The journey of a decline code
Card schemes define decline codes, but they don't 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. His issuing bank declines the transaction due to insufficient funds and sends decline code 51 back to the merchant's acquirer. The acquirer passes that code to the merchant, and from there, the merchant's own logic determines what happens next.
In a case like Billy's, that typically means prompting him to use an alternative payment method.
Why payment processors translate decline codes
To drive standardization and provide clarity for merchants, payment service providers (PSPs) map each decline code to their own set of decline reasons.
Here's what you'd see if a payment is declined for insufficient funds across three major PSPs:
- 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.
Once you start using more than one processor, the complexity compounds. You're forced to build custom logic into your payment systems to handle declines uniformly across each integration. We hear this from merchants around the world that this is time-consuming, technically costly, and it creates real headaches for reporting and data analysis.
How Primer unifies and simplifies decline code reasoning
Cutting through this complexity is one of the core reasons merchants choose Primer.
On a mission to unify the language of payments, we built the Unified Mapping Standard. It normalizes decline codes across every processor and payment method we integrate with — so you only ever need to understand decline codes one way: the Primer way.
That has real, practical benefits. You can immediately discard the custom logic you've built to interpret how each individual processor communicates decline reasons. And beyond that, the Unified Mapping Standard lets you:
- Create automated Workflows to handle specific decline scenarios, for example, triggering an email to a customer every time a payment fails due to insufficient funds
- View aggregated decline data in Observability to identify trends and surface opportunities to improve authorization rates.
- Trigger Fallbacks to automatically retry certain failed payments.
- Activate 3D Secure (3DS) for specific decline codes, rather than applying it blanket across all transactions
- Monitor decline reasons via Monitors to catch shifts in processor responses before they become a problem.
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.
Learn more about how Primer treats decline codes.
Make decline codes part of your payment optimization strategy
Decline codes are a vital tool in any merchant's payment optimization strategy. Used well, they help you recover revenue, improve the customer experience, and build smarter payment logic over time. But without a unified view across your processors, that potential is hard to reach.
Learn more about how Primer is cutting through payment complexity by unifying the language of payments.
.png)
Frequently Asked Questions (FAQ)
What are the most common payment decline codes?
Some of the most common decline codes include insufficient funds, do not honor, expired card, incorrect CVV, and suspected fraud. While the exact code can vary by card network and issuer, these categories account for a large portion of failed payments. Understanding which codes occur most frequently in your payment flow helps prioritize fixes — whether that means prompting customers to update card details, applying authentication, or adjusting routing rules.
Why do decline codes differ between payment providers?
Decline codes are issued by card networks and banks, but payment processors and gateways often map them differently. This means the same underlying reason for a failed payment may appear as different codes depending on the provider handling the transaction. A unified mapping system helps normalize these differences, making it easier for payment teams to analyze decline data consistently across multiple acquirers and payment service providers.
Can decline codes be used to reduce false declines?
Yes. By analyzing decline codes over time, merchants can identify patterns that suggest legitimate transactions are being incorrectly rejected. For example, a high rate of “suspected fraud” declines in a particular region might indicate overly aggressive fraud rules. Payment teams can then adjust authentication strategies, optimize routing, or fine-tune fraud controls to recover revenue while maintaining security.
%20(1).png)
.png)
.avif)