One declined payment shouldn’t mean a lost customer
The problem
Every processor declines payments the others would approve
Each acquirer has its own risk rules, its own issuer relationships, its own bad days. A “do not honor” on one is often an approval on another. If you run one merchant account, every one of those declines is revenue you never see. If you run several but your checkout only talks to one, the backup accounts sit idle during the exact moment they’d earn their keep.
How cascading works
Decline, reroute, approve, all before the customer notices
Four moves, one session. The customer never sees a second form, a second challenge, or a second charge.
- 01
Card entered once
Customer enters their card once in your checkout (hosted, embedded, or your own via API).
- 02
First processor in the route
PaymentKit sends the charge to the first processor in your route.
- 03
Retriable decline, next processor
If it declines for a retriable reason, PaymentKit sends the same charge to the next processor in the route, in the same session.
- 04
Approved, success screen
Approved on the second (or third) try, the customer sees a success screen. They never re-enter anything.
What’s reused on the cascade
The vaulted card, and the 3DS authentication result (ECI, CAVV, DS transaction ID) if the first attempt authenticated. No second challenge.
What isn’t retried
Hard declines. Stolen card, closed account, do-not-retry codes stop the cascade. Retrying those gets you flagged, not paid.
Routing rules
You decide the order, we run it
Routes are ordered lists of your connected processors. Set a default order, or build routes by:
- Country and region
- Currency
- Card brand and BIN range
- Ticket size
- Decline reason from the previous attempt
- Price tier (cascade pricing: if the full price declines, offer a lower tier with its own route)
Routes are configured via API today. A visual route builder is available to enterprise clients.
Failover
Cascading for declines. Failover for outages.
Same mechanism, different trigger. If a processor is down, returns errors, or doesn’t support the currency, PaymentKit skips it automatically and continues the route. No code change, no incident call, no checkout outage.
What you see
Every attempt, every processor, every reason
Each payment shows the full attempt path: which processors were tried, in what order, what each returned, and where it succeeded. Decline reasons come through verbatim from each processor. Exportable, filterable, auditable.
Proof
- ~11%authorization-rate lift across the 20+ subscription brands in our own portfolio, from routing across multiple processors.
- 22%lift for one brand after moving from a single processor to a cascading route.
Who uses this
Anyone with a backup MID that sits idle while the primary declines
Subscription businesses with two or more merchant accounts. High-risk merchants whose acquirers decline aggressively. International merchants whose US and EU customers approve better on different acquirers. Anyone who has watched a backup MID sit unused while the primary declined half of Tuesday.
Only have one processor? Start there. Add a second when you’re ready and cascading turns on with a route change. We can also help you get the second account.