Decline Code

A decline code is a short code sent back to a merchant when a payment is refused. In card payments it is the response code that the card issuer, or occasionally the network or processor acting for the issuer, places in the reply to an authorization request. An approval has one code; every other value signals a refusal or a request for further action, and the particular value gives the reason in general terms.

Merchants and payment providers rely on these codes to decide what to do next: ask the customer for another card, try again later, request authentication, or stop. The codes are also a main input for analysing a merchant's authorization rate. Their usefulness is limited by the fact that issuers often give only a vague reason, partly so as not to help fraudsters.

Card authorization messages follow the ISO 8583 standard, in which a two-character response code reports the outcome of each request. The issuer's authorization system sets the code after checking the card's status, the available funds or credit, its fraud rules and any restrictions on the card. The card network passes the code to the acquirer, which passes it to the merchant's gateway or processor.

Gateways and processors usually translate the raw value into their own vocabulary of error names and messages, and add codes of their own for failures that never reach the issuer, such as a transaction blocked by the merchant's fraud rules, a formatting error or a timeout. The same underlying refusal can therefore appear under different labels at different providers.

Networks define their own code lists, but a core set is shared widely. The values below are among the most frequently seen; exact wording differs by network.

• 05, do not honor. A general refusal with no reason given. It is the most common decline code and often reflects the issuer's fraud scoring.
• 51, insufficient funds. The account lacks the balance or credit for the amount. See insufficient funds.
• 54, expired card. The expiry date has passed or does not match.
• 14, invalid card number. The number does not correspond to a valid account.
• 41 and 43, lost or stolen card. The card has been reported lost or stolen and should not be retried.
• 57, transaction not permitted to cardholder. The card is not enabled for this type of transaction or merchant, for example because of card controls.
• 61 and 65, limits exceeded. The amount or number of transactions exceeds a limit set on the card.
• 91, issuer unavailable. The issuer's system could not be reached.

Providers group codes by whether another attempt could succeed. A soft decline is temporary: insufficient funds, a limit reached, a technical fault, or a signal that the cardholder must be authenticated. A hard decline is final for that card: closed account, invalid number, or a card reported lost or stolen. A generic refusal sits between the two, since the issuer has not said which it is.

In Europe, issuers use particular soft decline codes to tell the merchant that strong customer authentication is required. The merchant is expected to send the customer through 3-D Secure and resubmit, and a correctly handled soft decline of this kind frequently ends in approval.

Good handling depends on the code. After a hard decline, the merchant should stop and ask for a different payment method. After a soft decline, a planned payment retry may succeed, for instance a day later or near a typical payday for insufficient funds. Subscription businesses build this into dunning schedules, and routing platforms may send a soft-declined transaction to another acquirer through cascading. Automated retry logic uses the code to choose whether and when to try again.

Card networks regulate this behaviour. They classify decline codes into categories that indicate whether a retry is allowed, cap the number of reattempts permitted within a period, and charge fees to acquirers, generally passed on to merchants, for retrying transactions that were refused with a do-not-retry code. Mastercard supplements the response code with a separate advice code telling the merchant whether to update the card details, try again later or stop.

What the customer is told matters as well. Showing the raw reason can embarrass the customer or assist a criminal, so checkout pages usually display a neutral message suggesting another card or contact with the bank, while the detailed code is kept in the merchant's records.

Decline codes are an imperfect guide. Issuers apply them inconsistently, and a large share of refusals arrive as a generic code that hides the real cause. A decline for suspected fraud is rarely labelled as such. Some issuers return insufficient funds for accounts that are actually closed, or a generic refusal for a merchant category they block. Patterns in the codes are nevertheless informative: a sudden rise in invalid-number declines suggests a card testing attack, and a cluster of generic refusals from one issuer may indicate a rule that the acquirer can raise with the network.

Other payment rails have their own equivalents. ACH debits that fail come back with an ACH return code, and bank transfer and direct debit schemes define a return code or reason code for each rejection.