Cascading
Cascading is the automatic resubmission of a payment that failed or was soft-declined on one acquirer or route to a second, and if necessary a third, within the same checkout — so an issuer's decline that depended on the acquiring path, or an acquirer's outage, is not the customer's failure. It is a feature of orchestration platforms, bounded by the schemes' reattempt rules and by the fact that a genuine decline cascades into another.
- Also known as
- Payment cascading, Cascade routing, Fallback routing
- Used at
- merchants with two or more acquirers, orchestration platforms, PSPs with several acquiring connections; most valuable for cross-border and high-risk merchants whose approval rates differ sharply by route
- Binding
- scheme reattempt rules apply — a cascade is a retry, counts toward the limits, and must not follow a hard decline; the cascade must use the same authentication result or repeat it
- Typical triggers
- technical failures (timeouts, acquirer errors), soft declines with codes that vary by route ("do not honour", issuer unavailable), and 3-D Secure failures that a second route may handle differently; not hard declines
- Typical gains
- 1–4 points of approval rate for merchants with meaningful route-dependent declines; near zero for a domestic merchant on one strong acquirer
- Parties
- the merchant, the orchestrator or PSP running the cascade, the acquirers in the chain, the issuers (which see two requests), and the schemes (which count them)
How cascading works in practice
A customer's payment is submitted to acquirer A, which returns a timeout — its connection to the issuer's network is slow. Without cascading the checkout shows "payment failed". With it, the orchestrator resubmits the same transaction, with the same authentication data and an idempotent reference, to acquirer B within a second; B reaches the issuer, which approves; the customer sees success and never knew. The same logic handles a soft decline on A that B, with a different acquiring BIN or country, may not receive — issuers decline cross-border acquiring more readily than domestic — and a 3DS failure where B's implementation succeeds.
The bounds are the schemes' and the customers'. A cascade after a hard decline is prohibited and pointless; a cascade after "insufficient funds" is pointless too, since the funds are missing on every route; and the reattempt counts toward the schemes' limits, so a cascade of four routes on every decline is a fee. The design is a decision table: which codes cascade, to which routes, how many times, and with what data — built from observed approval rates by route and issuer. Fraud teams also watch it: a cascade that retries a decline the issuer's fraud model produced is helping the fraudster try again.
For a merchant the value is proportional to the difference between its routes; for an orchestration vendor it is the feature that justifies the layer.
Example
A cross-border retailer processes through a European acquirer and adds a US acquirer for US cards, with cascading on technical failures and on soft declines with route-dependent codes. In a month: 1,200 timeouts on the primary cascaded to the secondary, 1,050 approved; 3,400 "do not honour" declines on US cards via the European acquirer cascaded to the US acquirer, 900 approved; 700 "insufficient funds" excluded from the cascade by rule. Approval rate up 2.3 points, €340,000 of monthly sales; reattempt fees €400. A rule cascading every decline would have added 4,000 retries for 80 approvals and €1,200 of fees — and a warning letter.
Common mistakes
- Cascading every decline, including hard ones and empty accounts. - A cascade that re-runs 3-D Secure and challenges the customer twice. - Non-idempotent cascades that charge the customer on both routes when the first was slow rather than failed. - Ignoring the reattempt count, which the schemes do not. - Adding a second acquirer for cascading alone, when the cost of the second contract exceeds the recovery.