Cascading retries explained: recovering soft declines on another account

When a payment is declined, most checkouts simply show an error and hope the customer tries again. Some customers do, many do not. If you operate several merchant accounts, there is another option: automatically retrying the transaction on a different account, within the same checkout session, before the customer ever sees a failure. This is called cascading, and it is one of the main reasons merchants adopt payment orchestration.

Cascading is powerful, but it is not a 'retry everything everywhere' button. Used carelessly, it increases costs, irritates issuers and can conflict with card network rules. This article explains how to use it well.

Why the same card can succeed on another account

Issuers do not approve or decline cards in a vacuum. They evaluate the whole transaction, including the merchant, the acquirer, the acquiring country, the merchant category and the data sent with the request. Two accounts processing the same card for the same amount can receive different answers because:

• The acquiring country differs from the card's issuing country on one route and matches it on another, and some issuers treat cross-border transactions more cautiously.
• One account has a longer, cleaner history with that issuer.
• One acquirer sends richer data, such as full address details or network tokens.
• One route had a temporary technical problem, such as a timeout or an issuer connectivity error.

Only cascade the right declines

The foundation of good cascading is classifying decline responses. Soft declines are temporary or route-dependent and can sometimes be recovered. Hard declines mean the card should not be charged, and retrying them is wasteful at best and a rule violation at worst. A sensible starting point (an example policy, to be tuned with your own data):

• Good cascade candidates: issuer or switch unavailable (91), system errors (96), timeouts, and in many setups generic 05 'do not honor' responses.
• Poor cascade candidates: 51 'insufficient funds'. The card is valid but the balance is not there, and a different acquirer will not change that. Retrying later, as part of dunning, is more appropriate.
• Never cascade: 54 'expired card', 14 'invalid card number', 41 'lost card', 43 'stolen card', and any response that explicitly tells you not to retry.
• Handle separately: responses indicating authentication is required. The right answer is to run 3DS, not to try another account without it.

Designing a cascade

A cascade is an ordered list of accounts to try for a given transaction, plus the rules that determine when to move to the next one. Good cascades are short. One or two additional attempts capture most of the recoverable value, and longer chains mostly add latency and noise.

An illustrative configuration might look like this:

{
  "name": "EU Visa cascade",
  "when": { "card_brand": "visa", "issuer_region": "EU" },
  "route": ["mid_eu_primary", "mid_eu_secondary"],
  "cascade_on": ["05", "91", "96", "timeout"],
  "never_cascade_on": ["14", "41", "43", "54"],
  "max_attempts": 2
}

Note that the cascade only applies to a defined segment, lists the responses that trigger it explicitly, lists the responses that must never trigger it, and limits the attempts. All four elements matter.

Latency matters

Each additional attempt adds time while the customer waits on the payment screen. Most authorisations return quickly, but timeouts by definition do not. Set sensible timeout values and an overall time budget for the cascade, so that a slow acquirer does not leave the customer staring at a spinner.

Descriptors and customer experience

If the cascade succeeds on a different account, the charge may appear on the customer's statement under a different descriptor. Make sure all accounts in a cascade use descriptors the customer will recognise as your brand. Otherwise, you may recover the sale only to lose it later as an 'unrecognised charge' dispute.

Avoid double charges

Timeouts are the trickiest case. When a request times out, you do not know whether the issuer approved it. Cascading a timeout to another account can result in two successful authorisations for the same order. Mitigate this with idempotency keys, by checking the status of the original attempt where the acquirer supports it, and by automatically voiding any duplicate authorisation. Customers who are charged twice tend to dispute both charges.

3DS and cascading

If the customer completed 3DS2 authentication on the first attempt, that authentication result is generally tied to the specific transaction flow and may not carry over to another acquirer. Depending on your setup and market, the cascaded attempt may need its own authentication or may lose the liability shift. Work out with your acquirers how authenticated transactions should be handled before enabling cascades in markets with strong customer authentication.

Measuring whether cascading works

Measure the incremental approval rate from cascading, not just the number of rescued transactions. Useful views include:

• Recovery rate by decline code on the first attempt.
• Recovery rate by route pair (first account, second account).
• Dispute and refund rate for cascaded transactions compared with first-attempt approvals.
• Added latency per cascade step.
• Fees from additional attempts and any network retry charges.

If cascaded approvals dispute at a much higher rate than first-attempt approvals, the cascade may be pushing through transactions that issuers were right to decline.

Cascading inside an orchestration layer

LumniPay applies cascades as part of its routing rules: by BIN, card brand, country, currency and amount, with explicit lists of decline codes that trigger or block a retry, attempt limits and duplicate protection. Because the same rules engine handles caps and load balancing, cascades respect the capacity of each account instead of piling extra volume on the one with the best approval rate.