Payment failover
What is payment failover?
Payment failover is a mechanism that automatically reroutes a declined or failed transaction to an alternate payment processor or acquirer so it can be authorized on a second attempt. It acts as a backup path when the primary provider returns a decline or is temporarily unavailable.
When a payment fails at the primary provider – whether from a soft decline, a timeout, or a processor outage – failover logic resubmits the same transaction to a different provider in the routing chain. The cardholder experiences a single checkout attempt, while the retry happens in the background. This makes failover a core building block of multi-provider payment setups, where merchants connect to more than one or to avoid a single point of failure.
Key facts
- Also known as: transaction failover, cascading, or fallback processing
- Applies to: merchants connected to more than one processor or acquirer
- Triggered by: soft , processor timeouts, or provider downtime
- Primary goal: lift the by giving failed payments a second route
- Depends on: redundant connections to multiple processors or acquiring banks
How it works
- Initial attempt – The transaction is submitted to the primary or processor for .
- Decline or failure – The primary provider returns a decline, times out, or is unavailable.
- Evaluation – Failover logic checks whether the failure is retriable. Hard declines such as a stolen-card or closed-account response are not retried; soft declines and technical failures are.
- Reroute – The same transaction is sent to the next processor or acquirer in a predefined fallback order set by the merchant.
- Re-authorization – The alternate provider requests authorization from the , which can approve it where the first path failed.
- Result – If approved, the payment completes. If every configured provider declines, the transaction fails and the cardholder is notified.
Why it matters
A soft decline or a brief processor outage would otherwise end as a lost sale. Failover gives the same transaction another path to approval before the customer ever sees an error.
Issuers respond differently depending on which acquirer submits the transaction and where that acquirer holds a local banking presence, so a payment declined through one acquirer can be approved through another. For subscription and businesses, this reduces involuntary churn caused by a single failed renewal attempt, since the renewal can be retried through a different provider rather than dropped.
Common issues
- Duplicate charges – Poorly configured failover can submit the same transaction twice when the first attempt actually succeeded but its response was lost. Idempotency keys prevent this.
- Retrying hard declines – Rerouting a hard decline, such as a stolen or closed card, wastes attempts and can raise signals.
- Higher processing cost – Each retry adds a processing attempt, and some providers charge for declined authorizations.
- Masking real problems – Aggressive failover can hide an underlying integration or provider fault that would otherwise show up as a falling acceptance rate. A provider with a persistently high failover share usually points to a real integration issue rather than normal issuer declines.
