How do payment operators set up fallback for their merchants?

Short answer

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.

Still have a question?

Our team walks you through the platform with your use case on the table.

Book a demo