Improve approvals

Retry failed payments through backup providers to recover revenue

When a provider declines a recoverable payment, Corefy retries it through the next provider in your chain in milliseconds, without the customer re-entering anything.

Use case summary

Connect a backup provider for each key method and currency, set the retry order and conditions in your cascading scheme, and Corefy automatically re-runs recoverable declines through the next route — up to 5 attempts by default. The customer completes one payment; the retries happen underneath. Smart retry setups recover a meaningful share of initially declined payments.

  • Payment Manager
  • Payment Ops

Why recoverable payments still get lost

Some share of your declines has nothing to do with the customer's ability to pay. A provider has a glitch or a minute of downtime; a risk filter overreaches on a legitimate card; a timeout kills a transaction mid-flight. The money is there, the intent is there, but the first route just failed.

In a single-path setup, that's where the story ends. The customer sees an error, and what happens next is out of your hands: some retry, many don't, and the damage outlives the transaction — 41% of customers say they won't return to a business after a declined payment. Meanwhile, on the ops side, these losses hide inside the overall approval rate: nobody can say how much revenue failed for recoverable reasons versus genuinely unpayable ones, so the leak persists quarter after quarter, priced in as normal.

How to give every payment a second chance

With cascading, a declined payment doesn't stop at the first provider. Corefy automatically resends it to the next provider you've lined up as a backup, following the order and conditions you set once in your payment scheme.

  1. 1

    Connect backup providers for the methods that matter

    Cascading needs at least two providers able to process the same method and currency. Any provider from Corefy's catalog of 600+ ready-made integrations can serve as the backup: you connect your merchant account with them by entering its credentials, without any integration work on your side.

  2. 2

    Define the chain and its conditions

    In the payment scheme's Routing & Cascading settings, set the order of fallback routes and which decline resolutions trigger a retry.

  3. 3

    Retry only what's recoverable

    Cascading targets soft declines: provider-side failures, technical errors, over-strict risk filters. Hard declines — a stolen card, genuinely insufficient funds — are final by nature, and retrying them wastes attempts and provider goodwill, so the conditions keep them out of the chain.

  4. 4

    Let it run in milliseconds

    On a qualifying decline, the platform re-runs the transaction through the next route immediately — up to 5 attempts by default. The customer doesn't re-enter card details or see an error between attempts; they experience one successful payment.

  5. 5

    Watch what the chain recovers

    Every attempt is logged per transaction, so you can see exactly which payments were saved, by which fallback provider, for which decline reasons — and tune the sequence as provider performance shifts.

What you get

Failed payments become something your setup recovers automatically.

  • Recovered revenue you can count

    Smart retry setups recover up to 30% of initially declined payments. Your own figure shows up in analytics from the first week — recovered volume per provider, method, and decline reason.

  • Resilience against provider downtime

    A provider outage stops being an outage for your customers — traffic cascades through while your team investigates without checkout pressure.

  • Customers who never knew

    The retry is invisible: no error screens, re-entering details, or abandoned second attempt.

  • A measurable decline picture

    Attempt-level logs separate recoverable failures from real ones, so 'our approval rate' turns into specific, fixable reasons.

How cascading helped a PSP stop losing recoverable payments

When a PSP client came to Corefy, their payment conversion sat at 56.2%. Cascading became one of the core fixes: transactions declined for recoverable reasons now automatically retry through alternative providers in the client's scheme, so a single provider's failure no longer ends the payment. Together with smart routing rules and checkout improvements, this setup lifted their conversion to 85.1% within a year.

Frequently asked questions

Prefer to talk to a person or the answer is not on the list?

Talk to a payment expert

No, and it shouldn't. Cascading targets soft declines: provider downtime, technical errors, timeouts, over-strict risk filters — failures where a different route can plausibly succeed. Hard declines like insufficient funds or a blocked card are final regardless of provider, so your cascading conditions exclude them. This distinction is what keeps retry attempts productive rather than burning provider relationships on unwinnable transactions.

Turn your declines into a recovery plan

Cascading works underneath the payment flow you already have. See how it would run on your traffic.

Cookie Settings