Cascading and decline recovery: which declines to retry, and how

When a card payment is declined, the decline is not always about the customer. Sometimes the issuer is cautious with a particular acquirer, sometimes the acquirer’s connection times out, sometimes the issuer is simply unavailable. The same card can be approved a moment later through a different provider. Cascading is the practice of sending the payment to that different provider automatically, and it is the first tool most merchants reach for when approval rates fall.

It is also easy to get wrong. Retrying the wrong declines wastes money on network fees, can look like card testing to issuers, and in some cases breaks card network rules. This article explains which declines to cascade, what the networks allow, how to design the rules, and how to tell whether it is working.

What is cascading?

Cascading means that when one payment provider declines or fails a payment, the orchestration layer checks which other providers are eligible for the same customer, card, currency and amount, and sends the payment to the next one in the same session. The customer enters their details once and sees one result.

Cascading needs three things:

1. More than one eligible provider for the payment. A cascade has nowhere to go if only one PSP supports that country and method.
2. A tokenized card that can be sent to more than one provider, usually from the orchestrator’s vault.
3. Rules that decide which responses trigger a cascade, which provider is next, and when to stop.

How is cascading different from retries and failover?

The three terms are often used interchangeably, but they describe different behaviour:

• Failover switches provider when the first one is down or times out. It reacts to technical failures, not issuer decisions.
• Cascading also reacts to issuer declines and sends recoverable ones to a different provider immediately.
• Retries resend the payment later, often through the same provider. They are common for subscriptions and for insufficient-funds declines, where waiting a few days can help.

All three count as reattempts under card network rules, so all three must respect the same limits.

Which declines should you cascade?

Sort every decline code you receive into four groups. The exact codes differ by provider, so build the mapping from each provider’s documentation.

Soft declines, cascade or retry. The issuer declined this attempt but may approve another. Examples: generic “do not honor”, insufficient funds (better retried later than cascaded), issuer unavailable, processing error, re-enter transaction. Stripe’s decline code list, for example, advises attempting the payment again for issuer_not_available, processing_error and reenter_transaction.

Authentication required, retry with 3-D Secure. The issuer wants strong customer authentication. Adyen’s refusal reason list advises “Retry with 3D Secure” for its Authentication required reason. Cascading to another provider without authentication is unlikely to help.

Hard declines, never retry. The card is lost, stolen, closed, invalid or blocked. Stripe tells merchants to present lost and stolen card declines to the customer as a generic decline, and these will fail everywhere. Retrying them looks like fraud.

Fraud and compliance declines, never cascade. If the issuer or your own risk rules flagged fraud, sending the payment to a second acquirer to find one that approves is exactly what card testing looks like, and it raises your chargeback exposure.

What limits do card networks put on retries?

Both major networks publish rules on reattempts, and both charge fees when merchants exceed them.

Visa groups decline responses into categories. Primer’s documentation summarises them: Category 1 means the issuer will never approve a retry; Category 2 means it may approve later; Category 3 means the card details are missing or out of date; Category 4 covers generic responses. Visa does not allow reattempts on Category 1. For Categories 2 to 4, reattempts are capped within a 30-day window. The Visa Rules of 24 October 2026 set the cap at 20 attempts in 30 days, which matches PayPal’s May 2026 guidance. Some older processor guides still say 15.

Mastercard monitors excessive attempts under its Transaction Processing Excellence program. PayPal’s guidance says Mastercard allows 10 retries in 24 hours and 35 in 30 days on soft declines, and charges a fee for each attempt beyond that. Separately, it charges when a merchant retries after Merchant Advice Code 03 (“do not try again”) or 21 (payment cancellation).

Two practical consequences follow. First, read the merchant advice code or decline category on every response, not just the reason text. Second, count attempts per card across all of your providers, because the networks see every attempt, whichever acquirer sent it.

How do you design cascade rules?

A good cascade rule set answers six questions:

1. Which responses trigger a cascade? Soft declines and technical errors only. Keep the list explicit and reviewed.
2. Which provider is next? Only providers eligible for the same card country, currency, method, amount and customer segment. Order them by recent approval rate for that segment, not by habit.
3. How many steps? Usually one or two after the first attempt. Each step adds seconds of waiting and counts towards network limits.
4. What happens to 3-D Secure? Decide whether the next provider can reuse the authentication result or needs a new challenge, and avoid challenging the customer twice where possible.
5. How are duplicates prevented? Use idempotency keys per attempt, so a slow response from the first provider cannot produce a second charge.
6. What is the source of truth? Credit the customer only from the final, verified webhook, never from a browser redirect, and store every attempt with its provider, response code and timestamp.

Worked example: what does cascading recover?

Example figures, for illustration only.

An online store’s checkout receives 10,000 payment intents in a week.

Step	Count
Approved on the first attempt	7,600
Declined on the first attempt	2,400
of which hard, fraud or authentication declines (not cascaded)	1,080
of which soft declines and technical errors (cascaded)	1,320
Approved on the second provider	462

• First-attempt approval rate: 7,600 ÷ 10,000 = 76.0%
• Recovery rate on cascaded attempts: 462 ÷ 1,320 = 35.0%
• Approval rate after cascading: 8,062 ÷ 10,000 = 80.6%

If the second provider charges 0.10 euros per attempt, the cascade costs 132 euros a week. With an average order of 40 euros, it recovers 18,480 euros of orders. Even if the merchant’s margin on those orders is small, the arithmetic usually favours cascading soft declines.

Now suppose the merchant cascades every decline, including the 1,080 hard and fraud declines. Those attempts recover almost nothing, add 108 euros in provider fees, risk network fees for retrying Category 1 and MAC 03 declines, and may approve some payments that the first issuer declined for fraud, which later return as chargebacks. The extra volume also makes the merchant look more like a card-testing target to issuers.

What else counts as decline recovery?

Cascading is one tool among several:

• Better first routing. Rules that send each payment first to the provider that handles that card, country and segment well avoid the decline in the first place.
• 3-D Secure step-up when the issuer asks for authentication, and exemptions where the issuer allows them.
• Retry later for insufficient funds and some recurring payments, with timing informed by the decline code.
• Updated card details through account updater services or network tokens, for expired or replaced cards.
• Offering another method. If a card fails, the checkout can suggest a local bank transfer, wallet or other method the customer already uses.

How do you know whether cascading works?

Track these numbers by segment and by provider pair:

• Recovery rate: approvals on cascaded attempts ÷ cascaded attempts.
• Intent-level approval rate before and after enabling the rule. Do not use attempt-level rates; cascading adds attempts and makes them look worse. Checkout.com’s documentation reports first-attempt authorization success separately for the same reason. Our article on how to calculate approval rate covers the formula.
• Cost per recovered approval: attempt fees on the cascade ÷ recovered approvals.
• Chargeback ratio of recovered payments, compared with first-attempt approvals. If it is much higher, the rule is cascading declines it should not.
• Network fee lines on acquirer statements for excessive retries.

How does Omno handle cascading?

Omno’s routing rules decide the first provider and the cascade order per country, method, currency, customer group and customer verification level. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts. Every attempt, the rule that fired and the response received are written to the routing-decision log, and the final status reaches your back office once, by webhook. The smart routing and cascading page shows the settings in detail.