What Card Decline Codes Tell Merchants About Failed Payments

When a card payment fails, the issuing bank answers with a two-digit response code that traces back to ISO 8583, the bank card message standard first published in 1987. Code 05 tells a merchant almost nothing; code 14 tells it everything. Reading these codes correctly is the difference between recovering revenue and training customers to churn.

Nuv Media publishes information, not financial advice.

Where do decline codes come from?

The codes originate in ISO 8583, the international standard that defines how financial transaction messages are structured. In an authorization request, the issuer's decision rides back in a response field, and the two-digit code is the issuer's stated reason for a decline. Processors and gateways pass these codes through, sometimes with their own wording on top, which is why the same code can appear as DO NOT HONOR, 05, or a vendor-specific label.

One nuance matters before anything else: the code describes the issuer's response to the authorization request, not the quality of the payment data. A transaction can be perfectly formed and still receive 05. Conversely, a mangled card number returns 14 before fraud systems even look at the attempt.

What does decline code 05 actually mean?

05 — Do Not Honor — is the most common and least informative decline. The issuer is refusing the transaction without disclosing a reason, which can mean insufficient funds, a fraud-score trigger, a control on the cardholder's account, or a temporary issuer system state. The issuer will not elaborate to the merchant, and the cardholder often cannot see the reason in their app.

Operationally, 05 should be treated as an opaque, potentially temporary decline. One carefully timed retry is reasonable; aggressive immediate retries are not, because repeated attempts can raise fraud confidence scores and convert a soft decline into a hard block. When 05 dominates a merchant's decline mix, the productive investigation is internal: look at issuer concentration, ticket size, and whether the pattern tracks specific BINs or geographies.

What do codes 14, 51, and 57 tell the merchant?

14 — Invalid Card Number — means the primary account number failed the issuer's format or lookup. For card-on-file merchants this is a data problem: the customer moved, the PAN changed after a reissue, or the digits were mistyped. Retrying the same number will fail every time. The fix is a card refresh — through the customer or an account updater service.

51 — Insufficient Funds — is a timing signal. The card is valid and open; the balance is not there at this moment. For subscriptions, 51 is the classic retry candidate: schedule attempts around likely payday dates, and expect better recovery with patient spacing than with same-hour retries.

57 — Transaction Not Permitted to Cardholder — means the issuer allows the card but blocks this transaction type: a corporate card refusing e-commerce, a debit product blocked for certain merchant category codes, or a cross-border restriction. No retry strategy fixes 57; the customer must use a different card or the issuer must change the control.

Which declines are hard and which are soft?

The industry splits declines into two classes. A hard decline means the transaction cannot succeed as submitted: the card data, card status, or issuer policy is the blocker. A soft decline means the payment failed for a temporary or systemic reason that a later attempt can clear.

The classification has one operational warning attached: mislabeled hard declines are where revenue dies. A merchant that retries 14 or 54 on a fixed schedule burns authorization fees, inflates decline rates, and degrades card-on-file hygiene without recovering a single payment.

How should retry logic treat each code?

Codes 91 and 96 — issuer unavailable or system malfunction — are pure infrastructure declines. The payment never reached a credit decision, so a retry after a short interval is legitimate and effective. Routing the retry through a different processor can also help when the fault sits on one acquirer's connection.

Codes 51, 61, and 65 respond to calendar logic. Spread retries across days, weight attempts toward the first and fifteenth of the month for consumer cards, and cap the sequence — three to four attempts is the common commercial pattern before moving the account into dunning communication.

Codes 14, 54, and 82 respond to data logic. Enroll the card portfolio in a card account updater service, which refreshes reissued and expired PANs directly with the networks, and prompt customers to re-enter details when the updater returns no match. Retries have no role here until the data changes.

What should customer support actually tell the cardholder?

For 05 and 51, contacting the issuing bank is genuinely the fastest path, because only the issuer can see the reason behind the response. Merchants should tell customers the code verbatim and which bank issued the card, and avoid guessing at causes. For 14, 54, and 82, the merchant already knows the answer: ask the customer to update the stored card. Clear, code-specific messaging shortens support calls and recovers more payments than a generic declined-payment email.