Decline Code
A decline code is a numeric response from a card issuer or payment processor explaining why a transaction was rejected.
Key Takeaways
- A decline code is a two-character response value returned by the issuing bank inside an ISO 8583 authorization message, telling the merchant exactly why a card transaction was rejected.
- Decline codes split into hard declines (permanent: stolen card, closed account) and soft declines (temporary: insufficient funds, issuer unavailable), and merchants use this distinction to build retry strategies that recover 15 to 20 percent of failed payments.
- Crypto and stablecoin payment rails eliminate issuer-side declines entirely because they are push-based: the sender proves they have funds before the transaction leaves their wallet.
What Is a Decline Code?
A decline code is a standardized numeric response that an issuing bank sends back through the card network when it refuses to authorize a transaction. Every time a cardholder taps, swipes, or enters their card details online, the merchant's system sends an authorization request that travels through the acquiring bank, across the card network (Visa, Mastercard), and arrives at the issuing bank. The issuer evaluates the request and returns a response code: "00" for approved, or a specific two-character code explaining the rejection.
These codes are defined in the ISO 8583 messaging standard, the protocol that underpins virtually all card-based payment communication worldwide. The response code lives in Data Element 39 (DE 39) of the ISO 8583 message, a fixed-length, two-character alphanumeric field. While the issuing bank is the most common source of declines, any entity in the authorization chain (the payment gateway, the acquiring processor, or the card network itself) can generate a decline.
How It Works
The decline code is part of the broader authorization and capture flow that governs every card transaction. The full round-trip typically completes in under five seconds:
- The cardholder initiates a purchase at a merchant (in-store or online)
- The merchant's terminal or payment gateway formats an ISO 8583 authorization request (MTI 0100) and sends it to the acquiring bank
- The acquirer forwards the request through the card network (Visa, Mastercard) to the issuing bank
- The issuer validates the card number, checks available funds, runs fraud screening, and evaluates velocity limits
- The issuer returns an authorization response (MTI 0110) containing DE 39 (the response code) and, if approved, DE 38 (the authorization code)
- The response travels back through the network to the merchant, who either completes or cancels the sale
Common Decline Codes
While card networks and issuers define hundreds of response codes, a handful account for the vast majority of declines:
| Code | Meaning | Type |
|---|---|---|
| 05 | Do Not Honor | Soft |
| 14 | Invalid Card Number | Hard |
| 41 | Lost Card | Hard |
| 43 | Stolen Card | Hard |
| 51 | Insufficient Funds | Soft |
| 54 | Expired Card | Hard |
| 61 | Exceeds Withdrawal Limit | Soft |
| 65 | Exceeds Frequency Limit | Soft |
| 91 | Issuer Unavailable | System |
| 96 | System Malfunction | System |
Code 05 ("Do Not Honor") is a catch-all that issuers use when they decline without specifying a reason. It is the single most common decline code, and its ambiguity makes it particularly frustrating for merchants trying to diagnose payment failures.
Hard Declines vs. Soft Declines
The distinction between hard and soft declines determines what a merchant should do next:
Hard declines are permanent. The underlying condition cannot change without the cardholder taking action: replacing an expired card, opening a new account, or resolving a fraud flag. Codes 14 (invalid card number), 41 (lost card), 43 (stolen card), and 54 (expired card) are all hard declines. Retrying a hard decline wastes processing resources and can trigger fraud monitoring flags on the merchant's account.
Soft declines are temporary. The card and account are valid, but something about the timing or amount caused a rejection. Codes 51 (insufficient funds), 61 (exceeds withdrawal limit), 65 (exceeds frequency limit), and 91 (issuer unavailable) are soft declines. These can succeed on retry after conditions change: the cardholder deposits more funds, a new billing cycle begins, or the issuer's systems recover.
How Merchants Use Decline Codes
Decline codes are not just diagnostic: they drive automated retry logic, fraud prevention rules, and revenue recovery strategies. A well-optimized payment stack treats each decline code differently:
- For soft declines (codes 51, 61, 65): schedule an automatic retry after 24 to 48 hours, giving the cardholder time to replenish funds or reset velocity limits
- For code 05 (Do Not Honor): prompt the customer to contact their bank and retry after 24 or more hours
- For code 54 (expired card): use Card Account Updater services (like Visa Account Updater) to automatically refresh card credentials instead of retrying the stale details
- For system errors (codes 91, 96): retry after a short delay of a few minutes, since these reflect infrastructure issues rather than account problems
- For hard declines (codes 14, 41, 43): never retry automatically and instead prompt the customer to use a different payment method
Smart retry strategies can recover 15 to 20 percent of initially failed payments, making decline code handling a significant lever for merchant payment acceptance costs. Codes 05, 51, and 54 together cause roughly 60 percent of all failures, so optimizing for just these three codes delivers outsized impact.
False Declines
Not every decline is legitimate. False declines occur when an issuer rejects a valid transaction, typically due to overly aggressive fraud filters. For card-not-present transactions (e-commerce), false decline rates are significantly higher because the issuer cannot verify the physical card or cardholder presence.
The business impact is substantial. Research estimates that U.S. merchants lose over $150 billion annually to false declines, a figure roughly nine times larger than actual e-commerce fraud losses. Beyond the immediate lost sale, false declines damage customer relationships: studies indicate that over 40 percent of consumers will not return to a brand after experiencing a wrongful decline.
Why It Matters for Crypto and Stablecoin Payments
The entire decline code system exists because card payments are pull-based: the merchant requests funds from the cardholder's account, and a chain of intermediaries decides whether to approve. Every intermediary in that chain can say no, and the reasons are often opaque to both the merchant and the customer.
Cryptocurrency and stablecoin payments operate on a fundamentally different model. They are push-based: the sender initiates and authorizes the transaction from their own wallet, proving they have sufficient funds before the payment ever leaves. There is no issuing bank to decline, no fraud filter to trigger a false positive, and no ambiguous code 05 response. If the sender has the funds and signs the transaction, it succeeds.
For merchants accepting payments through networks like Spark, this eliminates an entire category of payment failure. There are no decline codes because there are no declines: the cryptographic proof of funds replaces the issuer's approval decision. This is particularly valuable for cross-border transactions where decline rates are highest, since issuers often flag international purchases as suspicious.
Decline Codes in Recurring Billing
Decline codes play an especially critical role in recurring billing and subscription models. When a stored card fails on a renewal charge, the decline code determines the dunning strategy:
- Soft declines trigger automatic retries on a schedule (often called "smart dunning"), spacing attempts over days or weeks to maximize recovery
- Hard declines trigger immediate customer notification to update their payment method, bypassing the retry queue entirely
- Expired card declines (code 54) trigger credential refresh through network-level updater services before the next retry
Without proper decline code handling, subscription businesses experience involuntary churn: customers who intend to keep paying but whose transactions fail due to preventable, retriable issues. Effective dunning systems recover a meaningful share of these payments by matching the retry strategy to the specific decline reason.
Risks and Considerations
Inconsistent Code Usage Across Issuers
While ISO 8583 defines the response code field, issuers have significant discretion in which codes they use. Many issuers default to code 05 ("Do Not Honor") for a wide range of reasons rather than providing specific codes. This inconsistency makes it difficult for merchants to build reliable automation, since the same underlying issue might produce different codes from different issuers.
Retry Abuse and Network Penalties
Card networks impose rules on how many times merchants can retry declined transactions. Visa's Transaction Acceptance Procedure, for example, limits retries for certain decline codes and charges excess retry fees for violations. Merchants who retry hard declines or exceed frequency limits risk penalties, increased scheme fees, or even account termination by their acquirer.
Privacy and Data Exposure
Decline codes can inadvertently reveal sensitive information about cardholders. A code indicating "insufficient funds" or "account closed" communicates financial status to the merchant. Payment systems must handle decline reason data carefully, limiting exposure to customer-facing interfaces and ensuring compliance with PCI DSS data handling requirements.
Chargebacks from Mishandled Declines
Poorly managed decline flows can increase chargeback rates. If a merchant retries a declined transaction and it eventually succeeds without proper customer notification, the cardholder may not recognize the charge and file a dispute. Transparent communication about retry attempts is essential for maintaining trust and keeping dispute rates within network thresholds.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.