Payments
Decline code
A decline code is the reason an issuing bank gives for refusing a card authorization, and it determines whether retrying that card could ever succeed.
The operationally important split is soft versus hard. Insufficient funds is soft — a timing problem where the same card will likely work in a few days. Stolen card, lost card and closed account are hard: no retry will ever succeed on that credential.
Retrying hard declines is worse than not retrying. It recovers nothing and raises your overall decline rate, which can in turn affect authorization rates on legitimate charges. Route hard declines directly to a payment-method update request instead.
Where the code comes from, and why yours may not match anyone else's
An authorisation request leaves your server for a gateway, is passed to an acquirer, travels the card network to the issuing bank, and comes back with a response code. The issuer picks that code. Everything downstream of it — the gateway, your dashboard, your retry logic — is reading a translation.
The underlying ISO 8583 response codes are shared across the industry: 05 do not honour, 51 insufficient funds, 54 expired card, 41 lost card, 43 stolen card, 62 restricted card, 91 issuer or switch inoperative. What is not shared is the label your processor prints next to them. Two processors handling the same refusal will report it under two different names, which is why decline-rate comparisons between providers are close to meaningless unless both sides agree on the mapping first.
A second distinction matters more than most teams realise. Not every failure is an issuer decline. A request rejected by your gateway for a malformed field, blocked by your own fraud rules, or dropped by a network timeout never reached a bank at all. Grouping those with genuine issuer refusals produces a decline rate that moves when your validation changes and tells you nothing about your customers.
Alongside the decline, Visa and Mastercard both carry a merchant advice code. One value says new account information is available, which is an instruction to query the account updater. One says try again later. One says do not try again on this credential. Reading that field is the cheapest retry policy that exists, because the issuer has already told you the answer.
The soft and hard families, and what each one means operationally
Soft declines are refusals about this attempt: the money was not there, the limit was hit, the issuer wanted stronger authentication, the switch was down. The credential is intact and the same card can succeed later.
Hard declines are refusals about the credential itself: the account is closed, the card was reported lost or stolen, the number is not valid, the card is restricted from this kind of transaction. No amount of retrying changes any of those facts, and every attempt is a guaranteed failure you pay for.
The ambiguous middle is do not honour, which is an issuer declining to explain itself. It covers genuine insufficient funds, a risk model that did not like the transaction, and a card the issuer has quietly stopped approving for card-not-present use. It deserves a small number of spaced attempts and then an exit to a credential-update request, not an indefinite retry loop.
| Family | Class | What the issuer is saying | Correct action |
|---|---|---|---|
| Insufficient funds (51) | Soft | The account cannot cover this amount today | Retry against a plausible replenishment date, not a fixed interval |
| Do not honour (05) | Ambiguous | Declining without stating a reason | A small number of spaced attempts, then request an updated method |
| Expired card (54) | Soft only after the credential changes | The stored expiry is in the past | Query the account updater; retry only once new details arrive |
| Lost, stolen or pickup (41, 43) | Hard | This credential has been reported compromised | Stop immediately and ask for a new payment method |
| Closed or invalid account (14) | Hard | The account behind this number no longer exists | Stop immediately; the updater may return a replacement |
| Restricted card (62) | Hard for this transaction type | The card is not permitted to do this | Stop retrying; offer a different method or currency |
| Authentication required | Soft, but needs the customer | The issuer wants the cardholder to authenticate | Send an authentication link; a silent retry cannot resolve it |
| Issuer unavailable (91) | Soft and transient | The bank or the switch did not answer | Retry within hours; do not treat as a customer signal |
Why retrying a hard decline costs more than the attempt itself
Each attempt carries a direct cost, and on some processors a declined authorisation is billed like any other request. That is the smallest part of it.
The larger cost is reputational, in the literal sense that the networks and issuers keep a record. A merchant profile that submits a high proportion of declined requests is read by issuer risk models as either poor data hygiene or card testing, and both produce more conservative approval behaviour on the transactions that would otherwise have gone through. The damage does not stay inside the failures. The networks also cap how many times a declined credential may be retried within a window and charge for attempts beyond it, with the caps and the fees differing by network and by decline reason.
Take an example store with 2,000 renewals a month failing at 8 per cent: 160 failures. If 30 per cent of those are hard declines, that is 48 credentials that cannot ever succeed. Retried four times each, they generate 192 authorisation attempts in a month whose expected recovery is zero — and those 192 attempts are counted in every ratio an issuer or an acquirer looks at.
The correct branch is cheap to build and is the single highest-return change in most dunning systems: classify on the code, exit the retry path on hard declines, and route the customer straight to a payment-method update.
AVS and CVV results are not decline codes
Address Verification Service and card security code results come back alongside an approval, not instead of it. The issuer can approve the authorisation and report that the postcode did not match. What happens next is your rule, not the bank's.
Merchants who void or reverse on a mismatch will see those transactions in their dashboard as failures, but they were merchant declines, and they belong in a different bucket from issuer refusals. Conflating them makes a strict internal rule look like a customer payment problem.
It is worth measuring the rule on its own terms before tightening it. A mismatch rule catches some fraud and rejects some legitimate customers who typed their billing address wrong or moved recently, and the ratio between those two populations is specific to your book. It also leaves an authorisation hold on a real customer's card for the length of the issuer's hold period, which generates support contacts that cost more than the order.
Frequently asked questions
- What is a decline code?
- A decline code is the response an issuing bank returns when it refuses a card authorization. It states the reason for the refusal, and that reason determines whether retrying the same card can ever work. Codes are standardised at the network level, but each payment processor renames them in its own dashboard, so the same refusal appears under different labels on different platforms.
- What is the difference between a soft decline and a hard decline?
- A soft decline refuses this attempt while leaving the credential valid, such as insufficient funds or a temporarily unavailable issuer. A hard decline rejects the credential itself, such as a lost, stolen or closed account. Soft declines are worth retrying on a considered schedule. Hard declines are not: no retry will succeed, and each attempt adds to the merchant's decline record.
- What does decline code 05, do not honour, mean?
- Do not honour is an issuer refusing without giving a reason. It covers insufficient funds, a risk model rejecting the transaction, and a card the bank has stopped approving for card-not-present use. Because it is ambiguous, the right handling is a small number of spaced retries followed by a request for an updated payment method, rather than an indefinite retry loop.
- How many times can you retry a declined card?
- It depends on the decline reason, and card network rules cap attempts on a declined credential within a defined window, with fees for exceeding the cap. Hard declines should be retried zero times. Soft declines justify a small number of attempts spaced against the customer's likely replenishment date, bounded by the network validity window for merchant-initiated transactions.
- Does a declined payment hurt your authorization rate?
- Yes, in two ways. A decline lowers the measured rate directly, and a pattern of declines against a merchant profile is read by issuer risk models as poor data hygiene or card testing, which makes those models more conservative on subsequent requests. The consequence is that approvals fall on charges that had nothing to do with the original failures.
In depth: How to reduce involuntary churn