How do payment operators set up fallback for their merchants?
They define, per merchant account, which provider takes over when the first one declines or times out, and which decline codes allow a new attempt. Payment Resilience holds the fallback policy and routing rules decide the first provider.
In detail
They define, per merchant account, which provider takes over when the first one declines or times out, and which decline codes allow a new attempt. Payment Resilience holds the fallback policy and routing rules decide the first provider.
What fallback decides
Fallback retries a failed payment with another provider. It only helps when the failure is technical or provider-specific: a timeout, a connection error, a "do not honor" that another acquirer might approve. It should never retry a hard decline such as a stolen card or insufficient funds, which would add attempts without recovering sales.
The settings
- Per merchant account: which providers are eligible as fallback, in which order.
- Per decline code: which responses allow a new attempt and which stop the flow.
- Per method: fallback for cards differs from fallback for wallets or bank payments.
- Limits: a maximum number of attempts and a time window, so the customer is not kept waiting.
How it fits with routing
Routing picks the first provider for a transaction; fallback picks the next one when the first fails. The two rules live together in the platform, and the transaction record shows every attempt, with the provider and the response, so a merchant can see why a payment was recovered or lost. Reporting then measures the recovery rate per provider, which tells operators where to tighten or relax the rules.