Cascading payments

Cascading payments: how automatic retries across acquirers recover declined transactions

Cascading is the automatic retry of a declined payment on another acquirer or provider of the same method, inside one checkout session, without asking the payer again. It recovers declines caused by the provider's risk rules, limits or outages rather than by the payer's card, and it is the single most measurable gain of orchestration.

How cascading works in Tranzify

The routing rule picks a route group: an ordered list of terminals that can take the payment, each with a priority and a weight.
The first terminal attempts the payment. A success ends the flow; the result is journaled and the webhook sent.
A decline is classified. A hard decline ends the flow with the issuer’s reason. A soft decline moves the payment to the next terminal in the group.
The next terminal attempts the payment with the same data; tokens work across acquirers because the vault belongs to the client, not to the provider.
The flow ends on a success, on a hard decline, or when the group is exhausted; every attempt stays in the journal with its reason.

What to cascade and what not

Decline	Cascade	Why
Provider risk rule, limit, outage, timeout	yes	the next provider may approve
Unsupported BIN, currency or method	yes	a routing gap, not a payer problem
Insufficient funds, invalid or expired card	no	the issuer’s answer will not change
Stolen or restricted card, fraud flag	no	retries harm the client’s standing with the schemes
3-D Secure failure	no	the authentication must be repeated by the payer

The classification uses the provider’s response codes mapped to the platform’s categories once, in the adapter, so every client’s cascade treats a given acquirer’s answer the same way, and the operations team can override the category of a code in the terminal’s settings.

Setting it up

Group terminals by method and country; keep one group small enough that a payer never waits through five attempts.
Set priorities by approval rate and cost; use weights to balance volume between equal acquirers.
Cap retries per payment and per minute to stay inside the schemes’ rules on repeated authorisations.
Watch the recovered share per group in the back office and move terminals as it changes.
Keep a time window for each acquirer’s maintenance, so the cascade does not start with a terminal that is known to be down.

Measuring what it recovers

The number that matters is the share of payments approved after a decline, per route group and per day: payments approved by a second or later terminal divided by payments the first terminal declined. The back office counts it from the journal, with the reasons of the first declines, so the client sees what the cascade recovers on its own traffic and which acquirer produces the declines. A rule change shows in the next day’s number; a vendor’s promised percentage never does. The blog post on measuring cascade recovery goes through the method and its pitfalls, such as counting the same payment twice when two groups overlap.

The schemes’ rules

Card schemes limit how many times a declined transaction may be reattempted and charge for reattempts beyond their rules; a cascade that retries every decline on every terminal would cost more than it saves and harm the client’s standing. The platform caps the attempts per payment and stops on hard declines; the journal shows every attempt per terminal, and the operations team adjusts the groups before a scheme’s programme notices.

Cascading beyond cards

The same mechanism applies to local methods with several providers: PIX through two Brazilian providers, Open Banking through two aggregators, Havale through two Turkish partners. The route group decides; the payer sees one checkout. For redirect methods the cascade happens before the redirect, on the provider’s refusal to create the payment, or after a failed return, when the routing offers the payer the next option on the same page. For payouts, a cascade moves a payout the first provider rejected to the next rail, and the ledger reserves the amount once.

Updated: 2026-11-08

Frequently asked questions

Which declines should be cascaded?+

Soft declines: the provider’s risk rules, limits, outages, unsupported BINs or currencies. Hard declines must not be retried: a stolen card, an invalid card, insufficient funds after the issuer said so, or a 3-D Secure failure.

Does the payer see the retry?+

No. The retry happens inside the same session; the payer sees one result. For redirect methods the payer may see the second provider’s page once.

How much does cascading recover?+

It depends on the first provider’s decline profile; the back office shows the recovered share per route group so that the client measures it on its own traffic instead of trusting a vendor’s number.

Can cascading charge the payer twice?+

No. The next terminal is called only after the previous one declined, timed out or errored; an authorisation that a terminal accepted ends the cascade, and a timeout is checked against the provider before the next attempt where the provider allows it.

Do the card schemes allow retries?+

They limit repeated authorisations of a declined transaction and charge for excessive reattempts, so a cascade must classify the decline and cap the attempts; the platform does both and journals every attempt with its reason.

Does cascading work with 3-D Secure?+

An authentication that failed is not retried; a payment authenticated once and then declined by the acquirer for its own reasons can be retried on another acquirer that accepts the authentication result, where the schemes’ rules allow it.