A fallback can be understood as a backup plan or alternative solution that kicks in when the primary option fails or isn’t available. Let’s look at what using a fallback means in online payments and how it lets you recover payments that would otherwise be lost.

A reminder of how an online payment works

When a website accepts card payments online, it needs to connect to a PSP or card processor. At the moment of payment, the buyer’s card details travel through a chain of intermediaries: the processor, the card networks and the issuing bank. Any link in that chain can fail and return a decline.

If a decline happens, for example because the processor returns an error due to technical issues, the payment is declined and the merchant loses the sale.

Not all declines are the same:

• Soft declines are temporary. For example, insufficient funds at that moment, a one-off technical issue at the issuing bank or incomplete authentication. They account for between 80% and 90% of all declines, and this is where retrying through another processor makes sense.

• Hard declines are final: stolen card, closed account, confirmed fraud. Not only does retrying fail to recover the payment, you can also rack up penalties with the card schemes.

What is a “fallback”

A fallback is the mechanism by which, when a transaction fails with one processor, the system automatically reroutes it to an alternative processor to try to complete it.

The goal is to recover payments that would otherwise be lost. It’s a technical process that happens in milliseconds, so the buyer doesn’t have to do anything and doesn’t notice it.

The role of fallback in payment orchestration

Payment orchestration lets you decide where each payment is routed based on predefined rules and variables. Payment orchestrators work as a layer on top of PSPs, processors and payment methods. This gives the business a layer of control over its payment system.

It offers several advantages:

• Improve conversion

• Optimize costs

• Scale easily into other markets

• Recover failed payments with fallback rules

Fallback lives within that logic. It isn’t a separate layer: it’s one of the rules the orchestrator executes when a processor fails.

Challenges when implementing fallbacks

Implementing a fallback comes with three challenges worth knowing before you start.

The first: infrastructure. For it to work, the business needs to be connected to more than one processor. Without an alternative, there’s nowhere to reroute the payment. Building that infrastructure in-house involves integrations, contracts and ongoing technical maintenance.

The second: the buyer experience. Without Agnostic 3DS, every time the payment is retried through a different processor, the user has to authenticate again. What was a seamless reroute turns into visible friction.

The third: the logic. Defining when the fallback is triggered, and through which processor, isn’t trivial. If the logic doesn’t distinguish between a recoverable soft decline and a final hard decline, the fallback adds retries that recover nothing and can damage the relationship with processors.

That’s why it makes sense to rely on a payment orchestrator that already has this infrastructure in place and fallback logic built in.

What to consider when choosing a fallback provider

Not all providers let you manage fallback logic with the same level of autonomy.

With some, creating or changing a fallback rule means contacting the provider. The payments team can’t make that change on its own: it depends on the provider implementing it. That slows down any adjustment.

With others, the logic is managed via API. The decision shifts to the technical team: the Head of Payments or the finance team can’t change anything in day-to-day operations without involving development.

It’s worth asking whether the provider lets you manage fallbacks directly from the dashboard, without depending on them or on your own technical team, and whether that logic can be adjusted when operations require it.

How to create a fallback in Zru

In Zru, fallback logic is configured directly from the Orchestrations module in the dashboard. There’s no need to contact the Zru team to set it up, or for the merchant’s technical team to touch any code.

Creating or changing a rule takes minutes. If a processor starts having issues or you need to adjust behavior for certain markets, the change is made on the spot.

For the payments team, this translates into four concrete advantages.

• Independence from the provider: no waiting for Zru to implement any change.

• Independence from the technical team: the payments team manages the logic directly from the dashboard.

• Operational responsiveness: adjustments are made when operations require them.

• Combined rules: the fallback can be combined with other orchestration variables (card type, country, amount) and integrated with fraud logic.

In Zru’s orchestration editor, each processor you add can have one or more backup processors. If the primary one fails, the payment automatically moves to the next one in the chain. You set it up once and it runs on its own.

If you want to fine-tune when it’s triggered, conditions let you combine it with payment variables: amount, card type, country of issue or fraud score, among others. The fallback doesn’t have to be the same for every payment.

If you’d like to see a concrete example of how fallback logic is set up in Zru, we explain it in detail here.