🚫 Payment declines and how to handle them

Anatomy of a decline

A payment decline is the negative response returned to an authorization request or to a payment order presented on a rail. The institution holding the payer’s funds makes the decision and transmits it as a two- or three-character code. That code almost never reveals the actual reason. What it mainly signals is what can be tried next. Handling a decline therefore turns on whether it is reversible, not on why it happened, which in most cases remains beyond the merchant’s reach.

A payment request passes through several links before it reaches the issuer, and any of them can reject it. The chain has six distinct rejection points, three of which sit with the merchant or its provider. The visible code doesn’t identify which link made the call. Attributing every decline to the issuer by default is the most common diagnostic error. A metric that rolls all six links into one average cannot tell them apart.

You can measure how declines are split across these links, provided you instrument every stage of the funnel, not just its exit. A risk engine that blocks 6% of traffic before anything reaches the network mechanically raises the authorization rate the network reports. The blocked attempts never reach the issuer, and the corresponding revenue vanishes without any network code recording it. The merchant sees a flattering authorization rate alongside falling revenue, questions the acquirer, and loses two weeks. The rejection came from its own engine.

Soft and hard declines: a practitioners’ distinction

In practitioners’ vocabulary, “soft decline” and “hard decline” refer to a temporary decline and a permanent one. No standard defines them. The pair appears neither in ISO 8583 nor in Visa’s or Mastercard’s rules; it comes entirely from industry usage. It classifies declines by reversibility, which is not the same as the seriousness of the reason. A decline for insufficient funds is far more common than one for an expired card, yet the two call for opposite handling.

Three families are enough to cover the ground, whereas a two-way split lumps together declines that call for different actions. The first family covers declines that time alone will clear. The second covers those that require a change to the instrument or the message before anything is resent. The third covers those that no later attempt will clear.

• Reversible with time. The instrument is valid, and the payer may have the funds tomorrow. Card 51, direct debit AM04, insufficient mobile money balance. Schedule the next attempt; don’t replay it within the minute.
• Reversible with an action. The instrument or the message must change before anything is resent. Card 54 on a reissued card, 65 or 1A when authentication is required, AC01 on a mistyped account. Resending the same request reproduces the decline.
• Irreversible. The decline holds for every route and every date. Card 41, 43, 59, direct debit AC04 or MD07, a network instruction prohibiting retries. Every new attempt uses up a counter and incurs fees.

These categories become a commercial issue as soon as a provider assigns them on the merchant’s behalf. A provider that returns a “soft decline” label without the original code imposes its own interpretation, and that interpretation can’t be audited. Two providers rarely put the same code in the same family. Classification is the merchant’s job, and to do it the merchant needs the raw data, intact.

ISO 8583: what the standard sets, and what networks rewrite

ISO 8583 is the international standard for the format of messages exchanged between payment systems during a card transaction. In an authorization message, the verdict sits in a single field, DE39, which the 1987 version defines as two alphanumeric characters. That version is still widely deployed. The ISO 8583-1:2003 revision extends the field to three characters. Both formats coexist in the global installed base, and converting between them is part of what processors do. The standard publishes a table of values but reserves ranges for private and national use, and every divergence has come from those ranges.

MTI  : 0110                response to an authorization request
DE38 : ------              authorization code: empty if declined
DE39 : 05                  response code: the verdict, two characters
DE44 : 2 M                 additional results: address check, CVV2
DE48 : ...84=02...         private field: at Mastercard, the Merchant Advice Code
DE54 : ...                 balances returned by the issuer, when it provides them
DE62 : ...                 network private field: internal reasons, indicators

Always store alongside DE39:
  the network that responded, the ISO version used (2 or 3 characters),
  the instruction code if any, the 3-D Secure authentication result,
  the attempt ID and the route ID.

In the ISO table, 65 means an exceeded frequency limit. Mastercard repurposed that value for the strong customer authentication requirement introduced by PSD2. Visa took a different route with 1A, a value absent from the original numeric table and outside any range reserved for that meaning. The two networks thus answer the same regulatory need with two incompatible values, and merchants have to handle both.

A second layer of rewriting happens on the acquirer side, because many processors normalize responses before passing them on. The goal is a consistent set of codes across networks, but normalization erases the information that distinguishes 65 from 61, or 1A from 05. Standard practice is to have the acquirer state in writing whether it remaps codes, and to receive the original field alongside the normalized one.

Proprietary codes: every network speaks its own language

A proprietary code is a decline value defined by a card network outside the ISO table. Each scheme publishes its own table in its rules, for its members. No global dictionary brings them together, so a merchant accepting six brands deals with six vocabularies, some of them not public. The list below covers the networks an international acquirer encounters, with their operator and launch year.

On top of the verdict, Mastercard provides an explicit instruction, the Merchant Advice Code, which tells the merchant what it is allowed to do after a failure. The value carries a retry instruction; it says nothing about the reason for the decline. It is the most directly actionable piece of data in the entire authorization response, and the one integrations most often ignore.

• 01 signals that updated account information is available: query the updater service before any retry.
• 02 allows a retry later: the cause is temporary, and the retry schedule applies.
• 03 prohibits retries: any further attempt violates the rules and is billed.
• 21 signals that the recurring payment has been canceled: the merchant must stop the subscription, not just let it keep failing.

Beyond cards: ISO 20022, ACH, UPI, and push rails

Every non-card rail has its own set of decline codes. European direct debit rejects with four-character ISO 20022 codes. US ACH returns codes starting with the letter R, while UPI responds with NPCI-specific values. Pix uses ISO 20022 messages governed by the rules of the Banco Central do Brasil. None of these vocabularies maps exactly onto another.

The US rail is the only one that explicitly caps the originator’s exposure with numerical ratios. The Nacha Operating Rules set an unauthorized return rate threshold of 0.5%, and review thresholds of 3% for administrative returns and 15% for overall returns. Enforcing these thresholds falls to the originating institution, which can shut off the rail at whatever notice it chooses, with no regulator involved. On this rail, the return rate is therefore a condition of access to the service, not a performance metric.

UPI poses a challenge because of the number of parties involved. A transaction passes through the third-party app, the sponsor bank, the NPCI switch, the payer’s bank, and the payee’s bank. The returned code doesn’t always identify which party caused the failure. That is why NPCI publishes decline statistics by bank, separating technical failures from business declines. The data shows the share of failures attributable to each bank, and no other rail currently offers anything comparable.

Payer-initiated push rails form a final family, in which the customer issues the payment order. PromptPay has been operated by National ITMX under a Bank of Thailand mandate since 2017, and PayNow by BCS on behalf of the Association of Banks in Singapore since the same year. DuitNow has been run by Payments Network Malaysia (PayNet) since 2018, with its DuitNow QR standard from 2019, while Bank Indonesia, together with ASPI, has mandated QRIS since 2019. On these rails, the merchant sends no authorization request. It presents a way to initiate payment, usually a QR code, and then waits for the settlement notification.

Retries: what the rules allow, and what they charge for

A retry is a new request submitted after a decline, on the same instrument and for the same amount due. Starting in 2021, the networks capped retries, quantified them, and began charging for them. The move followed years in which some merchants replayed hard declines dozens of times per card. The networks justify these limits by the authorization capacity each attempt consumes and by the strain repeated attempts put on the relationship between issuers and their customers.

• Count attempts per instrument and per merchant, across all providers. A multi-acquirer setup doesn’t reset any counter.
• Set an internal cap below the network’s, enforced in code rather than by team guidelines.
• Log the reason for each attempt, not just its outcome. Without it, no retry policy can be evaluated after the fact.
• Space out re-presentments on insufficient-funds declines. Replaying within the minute doesn’t change the account balance and uses up the quota.
• Separate technical retries, measured in seconds, from commercial retries, measured in days and owned by the product team.

What declines cost, and why no one sees it

The cost of a decline combines uncollected revenue and knock-on expenses. That makes declines the only payment cost that appears on no invoice: no statement, settlement advice, or fee line ever mentions them. At constant traffic, one extra point of authorization rate is worth one percent of collected revenue. A committee that spends six weeks negotiating two basis points of acquirer margin is therefore working on a variable often worth a tenth of what the authorization rate is worth.

The cost falls into four buckets, three of which escape payment reporting. The first is easy to read. The other three sit in product, marketing, and customer service, where no one has established the link to a response code.

Measurement: you can’t steer a rate, but you can steer a mix

Measuring declines relies on two distinct things: an overall rate and a distribution of codes. A change in the overall rate doesn’t point to any action on its own, since it tells you neither which segment moved, nor which code gained weight, nor whether the gap exceeds statistical noise. The code distribution, by contrast, identifies the segment and the code within the hour. A spike concentrated on 65 and 1A points to an exemption scope set too wide; a rise in 54 limited to subscriptions, to aging stored credentials; a burst of 14 on tiny amounts, to an attack.

Per attempt, stored as is:
  original_code         exact value returned, not remapped
  network               Visa, Mastercard, UnionPay, RuPay, TROY, Elo...
  iso_version           2 or 3 characters: changes the meaning of the value
  instruction_code      Merchant Advice Code, or empty if the network produces none
  auth_result           3-D Secure outcome, or no authentication
  issuer_bin            first 6 to 8 digits: the real diagnostic grain
  issuing_country       distinct from the customer's country
  channel               first transaction, stored credential, recurring, wallet
  attempt_rank          1, 2, 3... on the same instrument and the same merchant
  route                 acquirer and contract ID used

Derived ratios, calculated by code and by segment:
  code_share            weight in total declines
  recovery_rate         successful subsequent attempts / retried attempts
  unmapped_share        declines falling into the unknown state -- a debt, not a category

The minimum segmentation has six dimensions: issuer BIN, issuing country, card type, channel, amount band, and whether authentication was performed. An overall rate blends all six, so an anomaly confined to one segment shows up as a small wobble. A drop concentrated on two BINs, with every other segment flat, points to an issuer incident, whereas a drop across all segments at a specific time points to a deployment. The two profiles call for different responses, and an aggregate figure conflates them. Only segmentation tells them apart.

Improvement: the levers, ranked by return

Approval levers rank by increasing effort, and the order in which you pull them determines the result. Two are configuration changes that produce a measurable effect within weeks, while a third requires development work. The last involves setting up a legal entity and months of work, for the largest gain on international flows. Starting with that last lever ties up several months before any result, while the configuration levers could have been paying off in the meantime. It is the costliest mistake in the field.

Two common practices backfire. The first is switching off authentication to “unblock” a flow. The authorization rate rises for a few days, then fraud and disputes climb, and the cost outweighs the gain before the quarter is out. The second is piling retries onto a structural decline, which recovers very few transactions and fills up the networks’ monitoring counters.

• Tackle concentrated declines first: two BINs carrying 20% of volume are worth as much as all the global settings combined.
• Measure every change against a control group. A rate that rises after a deployment doesn’t prove the deployment caused it.
• Set a minimum n per segment before opening a ticket: a three-point gap on 200 transactions is not statistically meaningful.
• Escalate issuer incidents through the acquirer, with the exact time, the BIN, and a comparison with the same hour seven days earlier.
• Revise the code mapping table every time a network publishes new rules, and date it.