Routing
Soft vs hard declines: reading decline codes the right way
Not all declines are equal. Learn how to tell temporary soft declines from final hard declines, what the most common codes mean and what to do with each one.
July 1, 2026 · 4 min read · LumniPay team
Every declined payment comes back with a reason. Most checkouts reduce that reason to 'your payment could not be processed', but behind the scenes the issuer has returned a response code that tells you a lot about what went wrong and what you can do about it. Merchants who read those codes properly recover more revenue, retry less wastefully and stay on better terms with issuers and card networks.
The basic distinction
Declines fall into two broad groups. A soft decline is temporary or conditional: the card is valid, but this transaction could not be approved right now, on this route, or without additional steps. A hard decline is final: the card or the account should not be charged, and retrying will not change the outcome.
The line between the two is not always sharp. Some codes are generic and their meaning depends on the issuer. But the classification is still the foundation of every sensible retry, cascade and dunning strategy.
Common decline codes and what they mean
Response codes vary by network, acquirer and processor, and many platforms translate them into their own formats. The ISO 8583 style codes below are widely seen and are a useful reference:
05: Do not honor
The most common and least informative decline. The issuer refused the transaction without saying why. It can reflect issuer risk rules, unusual activity, a cross-border block or a temporary issue. It is usually treated as soft, but repeated 05 responses on the same card are a sign to stop.
51: Insufficient funds
The card is valid, but the available balance or credit is not enough. This is a soft decline in time, not in route: retrying the same amount immediately or on another acquirer will almost always fail again. Retrying later, or offering a lower amount where your offer allows, is more sensible.
54: Expired card
The expiry date has passed, or the date sent does not match. Retrying the same data is pointless. For stored cards, use an account updater service or network tokens to obtain the current details, or ask the customer for a new card.
14: Invalid card number
The card number does not exist or is not valid. Often caused by typos at checkout. Treat as hard: ask the customer to check the details.
41 and 43: Lost or stolen card
Hard declines with a fraud signal. Never retry. Consider blocking the card in your own system and reviewing other recent orders using the same email, device or address.
57 and 62: Transaction not permitted or restricted card
The card cannot be used for this type of transaction, merchant category or country. Some of these can be route-dependent, but most are effectively hard for your business. Ask for another payment method.
91 and 96: Issuer unavailable or system error
Technical failures rather than decisions about the cardholder. These are the clearest soft declines and the best candidates for an immediate retry on another route.
Authentication required
In markets with strong customer authentication, the issuer may decline a transaction because it wants 3DS2. The fix is not to retry elsewhere but to run authentication and resubmit.
Do not rely on one mapping table
Different acquirers map issuer responses differently, and some send their own codes or merchant advice codes alongside the issuer response. Build your classification from the raw responses you actually receive, and review it regularly.
Merchant advice codes
Some networks return additional advice with a decline, telling the merchant whether to retry later, update the card details or never retry. When present, these signals should take priority over your generic classification. Ignoring an explicit 'do not retry' instruction can generate network fees and hurts your standing with issuers.
What to do with each type
- Technical soft declines (91, 96, timeouts): retry once on another route, immediately, with duplicate protection.
- Generic soft declines (05): a single cascade attempt on a different account may help. Monitor whether it does for your traffic.
- Funds declines (51): do not cascade. For subscriptions, retry later in your dunning schedule. For one-off purchases, invite the customer to use another card.
- Data declines (54, 14): update the card through account updater or ask the customer to correct it.
- Fraud and restriction declines (41, 43, 57, 62): stop. Ask for another payment method or review the order.
- Authentication declines: run 3DS2 and resubmit.
What the customer should see
Decline messaging at checkout is a balance. You should not reveal fraud-related reasons, since that helps fraudsters probe stolen cards. But a generic error for every case loses customers who could easily fix the problem. A good compromise: for data issues, tell the customer to check their card number and expiry date; for funds or generic declines, suggest trying another card; for fraud declines, use a neutral message.
Why this matters at the account level
Decline patterns also tell you about the health of your merchant accounts. A sudden rise in 05 responses on one MID, concentrated in a specific issuer or country, can indicate that issuers have started to treat that account as risky. A rise in 54 responses suggests your stored cards need updating. Watching the decline code mix per account, per BIN range and per country turns declines from noise into an early warning system.
LumniPay classifies issuer responses for every transaction and uses that classification in routing: cascading only where a different route can plausibly help, feeding funds declines into subscription dunning instead, and reporting decline mixes per MID, BIN and country so you can see trends before they become problems.