Payment decline codes: a reference
What each decline code means, whether retrying will ever work, and what to do instead. The ISO 8583 response codes most processors map onto, in one table.
A decline code tells you two things: what the issuer said, and whether retrying can ever work. The second is the one that matters operationally, and it is the one most systems ignore.
The codes below are the ISO 8583 response codes that card networks use and that most processors map their own codes onto. Your processor’s exact values and wording may differ — check their documentation for the mapping.
The codes
Retry column: ❌ never · ⏳ after a delay · ⚠️ only with new details.
| Code | Meaning | Type | Retry | What to do |
|---|---|---|---|---|
| 01 | Refer to issuer | Hard | ❌ | Cardholder contacts their bank |
| 02 | Refer to issuer, special condition | Hard | ❌ | Cardholder contacts their bank |
| 04 | Pick up card | Hard | ❌ | Card is flagged; request another |
| 05 | Do not honour | Hard | ❌ | Issuer withheld the reason; cardholder must call |
| 12 | Invalid transaction | Hard | ❌ | Transaction type not permitted on this card |
| 13 | Invalid amount | Hard | ❌ | Check amount formatting and currency minor units |
| 14 | Invalid card number | Hard | ⚠️ | Re-enter; likely a typo or wrong card |
| 15 | No such issuer | Hard | ⚠️ | Card number does not map to an issuer |
| 41 | Lost card | Hard | ❌ | Request another payment method |
| 43 | Stolen card | Hard | ❌ | Request another payment method |
| 51 | Insufficient funds | Soft | ⏳ | Retry later, or ask for another method |
| 54 | Expired card | Hard | ⚠️ | Request updated expiry, or use an updater service |
| 57 | Transaction not permitted to cardholder | Hard | ❌ | Card restricted for this transaction type |
| 59 | Suspected fraud | Hard | ❌ | Cardholder must contact their bank |
| 61 | Exceeds withdrawal amount limit | Soft | ⏳ | Retry later or split the amount |
| 62 | Restricted card | Hard | ❌ | Often geographic or category restriction |
| 65 | Exceeds withdrawal frequency | Soft | ⏳ | Retry after a delay |
| 82 | CVV failure | Hard | ⚠️ | Re-enter the security code |
| 85 | No reason to decline | — | — | Approval for a verification-only check |
| 91 | Issuer unavailable | Soft | ⏳ | Retry; issuer system unreachable |
| 96 | System malfunction | Soft | ⏳ | Retry; processing error |
| N7 | CVV mismatch on a decline | Hard | ⚠️ | Re-enter the security code |
Soft versus hard, and why it decides your retry policy
Soft: 51, 61, 65, 91, 96. The condition can change. A balance rises, a daily limit resets, an issuer system comes back.
Hard: everything else. The card cannot be used for this transaction and will not become able to.
Retrying a hard decline achieves nothing and costs something. Repeated attempts on a card the issuer has refused raise your decline ratio, and a burst of attempts across many cards resembles card testing, which attracts attention you do not want. Configure your dunning to stop on hard codes.
The five that account for most volume
05 — Do not honour
The most common and the least useful. The issuer refused and declined to say why, which is deliberate: publishing the reason would expose the fraud rule that triggered.
There is nothing to fix on your side. The message to the customer should say the bank declined it and suggest they contact their bank or use another card — not “your payment failed”, which sounds like your fault and produces a support ticket instead of a resolution.
51 — Insufficient funds
Genuinely temporary. The single highest-value retry in subscription billing, and timing matters more than frequency — retries aligned to typical pay cycles recover materially more than fixed short intervals.
54 — Expired card
Entirely predictable, and the only decline you can prevent. Card account updater services supplied by the networks through most processors refresh stored credentials before they expire.
82 / N7 — CVV problems
Usually a typing error, sometimes a stored-card mismatch. Worth one re-entry, never a silent retry.
91 — Issuer unavailable
Infrastructure, not the card. Retry after a delay. If it clusters, the issuer is having an incident and nothing you change helps.
What the code does not tell you
Whether the customer can pay you at all. The issuer scores the transaction, not the card: the same card at a different amount, merchant category, country or time of day produces a different answer. A customer insisting the card works everywhere else is usually right and still cannot pay you.
Whether authentication would change it. A payment carrying strong customer authentication shifts liability and often changes the issuer’s decision. A decline on an unauthenticated transaction may approve when authenticated.
Anything about your account. A decline is the issuer refusing. It is not your processor holding funds, which is a different situation with different remedies.
What to log
The code alone is not enough to act on later. Store, per attempt:
- Code and processor’s own message — the mapping is not always one to one.
- Soft or hard — resolved at the time, so retry policy is queryable.
- Attempt number and elapsed time since the first failure.
- Whether authentication was performed.
- Amount and currency — limit-related declines correlate with amount.
Without these, a decline rate is a number with no explanation, and the difference between an issuer problem, a checkout problem and a customer problem is invisible.
Where Fynex fits
A failed payment is not just a lost sale — it leaves an invoice open and a customer record that no longer matches reality.
Fynex keeps the payment attached to what it was meant to settle, so a decline is visible as a specific unpaid invoice rather than as a gap discovered at reconciliation. Retries follow the soft-or-hard distinction rather than a fixed schedule, and a payment that eventually succeeds settles the invoice it was always for, at the point it succeeds.
Related: Why did my payment fail at checkout · Why payouts fail, by rail · dunning · strong customer authentication