Failover
What Is Failover in Payments? Definition and How It Works
Definition
Failover in payments is the automatic rerouting of a transaction to an alternative acquirer, processor, or network path when the primary path is unavailable or returns a technical failure, maintaining transaction continuity without merchant intervention.
How it works
Payment failover is triggered by technical failures, such as a timeout, a connectivity error, or a system unavailability response, rather than by a standard authorisation decline. When the orchestration layer or switch sends an authorisation request and receives no response, a connection error, or a technical decline code within a configured timeout window, failover logic kicks in and reroutes the transaction to the next available path.
The failover path is pre-configured as part of the routing rule set. It may be a secondary acquirer, a different network path to the same acquirer, or a backup processor. Well-configured failover systems maintain a priority-ranked list of alternative paths and try them in order before returning a final failure to the merchant.
Automatic failover is distinct from manual retry. Manual retry requires a decision by the merchant's system to resubmit a declined transaction; it introduces latency and requires logic in the merchant's codebase. Automatic failover happens within the payment infrastructure layer, often within the same authorisation attempt from the merchant's perspective, without requiring merchant-side action.
The speed of failover matters: a failover that adds 3-5 seconds to transaction latency will produce checkout abandonment. Enterprise-grade failover implementations aim to complete the failover and return an authorisation response within the normal authorisation timeout window (typically 3-8 seconds total).
Why it matters
Single-acquirer setups have no failover path: when the acquirer is down, transactions fail entirely. This is the core operational risk of single-acquirer dependency: acquirer outages are not hypothetical events, and they occur without warning.
Failover speed determines whether customers notice: a failover that completes within the normal authorisation response window is invisible to the customer. A failover that adds perceptible latency to checkout creates abandonment. The failover implementation quality, not just its existence, determines whether it protects revenue.
Failover coverage should extend to network paths, not just acquirers: connectivity failures between the payment switch and a card network can be as damaging as acquirer downtime. Failover architecture should account for network-level redundancy as well as acquirer-level redundancy.
Scheme rules govern retry behaviour after declines: failover for technical failures is distinct from retrying a decline. Card scheme rules restrict how declined transactions can be retried; violating retry rules results in fines. Failover logic should enforce scheme retry restrictions to avoid inadvertent scheme violations.
With PXP
PXP's smart routing engine includes automatic failover across its acquirer connections. When an authorisation request returns a technical failure, the routing engine retries via an alternative acquirer within the same authorisation attempt. Failover behaviour is configurable per transaction type and can be monitored in real time through the PXP dashboard.
Frequently asked questions
What's the difference between failover and a retry?
Failover handles technical failures, including timeouts, connectivity errors, and system unavailability, by automatically switching to an alternative path within the same transaction attempt. A retry is a new transaction attempt submitted after a declined authorisation. Failover is transparent to the merchant; retries require explicit logic and must follow card scheme retry rules for declined transactions.
Does failover require multiple acquirer relationships?
Yes. Failover to an alternative acquirer requires that alternative to be connected and configured in the routing layer. Merchants with a single acquirer connection have no failover path at the acquirer level, though a well-architected payment provider may have redundant connectivity to the same acquirer via different network paths, which provides some resilience without a second acquirer relationship.
How do card scheme rules apply to failover?
Scheme rules restrict retry behaviour for declined transactions but generally permit rerouting for technical failures. The distinction matters: a failover triggered by a timeout or connectivity error can typically be rerouted without restriction. A failover triggered by a decline code requires checking whether the decline is a hard decline (no retry permitted) or a soft decline (retry permitted under scheme retry rules).
How should merchants test failover performance?
Failover should be tested in staging environments by simulating acquirer downtime and measuring response time and success rate on the failover path. Merchants should verify that failover completes within the configured authorisation timeout window and that the failover path returns equivalent approval rates for the same transaction types. Regular failover drills are good practice for enterprise payment operations.
Revolutionize your business with PXP
Take complete control of your commerce and payments with one platform.
Get Started