Reviewed on November 7, 2026.
Having more than one PSP seems to solve an obvious problem: if one provider fails, just send the payment to another. In practice, this is precisely where an apparently resilient architecture can introduce new risks.
The reason is simple. In payments, no response does not necessarily mean no processing. A provider may have authorized an attempt even when the application received a timeout.
Failover, then, is not just switching routes. It means deciding when another attempt is safe, necessary, and consistent with the payment's actual state.
What is payment failover?
Failover is the mechanism that enables an alternative path when the primary route cannot continue under certain conditions.
In a multi-PSP architecture, this can mean directing a new attempt to another provider following an eligible technical failure.
The word eligible matters. Not every failure, decline, or timeout should trigger an automatic retry.
Why isn't redundancy enough?
Integrating two providers creates alternative paths, but does not define how to use them. Without a policy for state and failures, the second path may simply double the complexity.
A resilient architecture must know what happened on the first attempt, whether the result is conclusive, whether processing may still be pending, and which actions are allowed next.
Without those answers, switching providers can be more dangerous than waiting and reconciling the state.
Technical failures and declines are different
| Technical failure | Decline | Timeout | |
|---|---|---|---|
| What is known | The path did not complete | The issuer or provider answered no | No response arrived in time |
| Another attempt | It can make sense on another path | It should not always be retried | Only after checking the state |
| Risk | Retrying without idempotency | Persisting after a final decline | Charging again what was already processed |
A new attempt does not replace EMV 3-D Secure (opens in a new tab ↗) authentication and should not expose the PAN again when the operation already uses EMVCo payment tokenisation (opens in a new tab ↗). PCI DSS (opens in a new tab ↗) still applies to the environment that handles account data on that retry.
A technical failure may indicate unavailability, a communication error, or another execution problem. A decline may reflect a valid decision by the payment ecosystem.
Treating both situations the same is a conceptual mistake. Switching PSPs should not be an automatic response to every negative outcome.
Result classification must be part of the failover policy.
The most delicate case: a timeout
Consider an authorization sent to PSP A. The PSP receives and processes the request, but the response is lost. The application sees a timeout.
If the system assumes that a timeout means failure and immediately sends the same charge to PSP B, there may be a second authorization for the same business intent.
This scenario shows why resilience depends on state. Before retrying, you need to understand what may have happened on the previous attempt.
Idempotency helps, but does not solve everything
Idempotency is an essential mechanism for reducing duplicate effects when the same operation is repeated within a supported context.
But an idempotency key at one provider does not necessarily exist or have the same meaning at another. When switching PSPs, the infrastructure enters a new execution domain.
That is why idempotency must be part of a broader strategy that includes payment identity, attempt identity, status queries, and reconciliation.
Payments and attempts must be separate
A payment represents the business intent. An attempt represents a technical execution of that intent on a specific route.
This distinction allows the system to record an attempt as pending, a technical failure, declined, or completed without losing the original payment's identity.
With failover, this model becomes even more important because different attempts can coexist in the history of the same intent.
What is fallback?
Fallback means using an alternative when the primary path cannot continue. In payments, the term often appears alongside failover.
Definitions can vary across platforms. The architectural point is that there is a policy for choosing another path under specific conditions.
That policy should specify which errors allow fallback, which require a status query, and which end the flow.
What is cascading?
Cascading describes a controlled sequence of attempts across different routes. The idea may seem attractive because it increases the number of available paths.
But every additional attempt increases the need for control. Limits, conditions, state, and effects on experience, risk, and operations must be defined.
Cascading should not mean trying providers in succession until one accepts. Every new attempt must have a technical reason and a policy behind it.
How should errors be classified?
A multi-PSP architecture must translate different responses into understandable operational categories.
Two providers may use different codes for similar situations. Without normalization, the failover policy becomes coupled to each API's details.
A common layer can help distinguish conclusive results, technical errors, pending states, and situations that require further investigation.
Not every decline should be retried
A decline may result from an issuer's decision or conditions that do not change simply because the transaction went through another processor.
Beyond potentially being useless, an indiscriminate retry can worsen the experience and make operational analysis harder.
A mature policy starts by asking what the result means, not whether another integration is available.
Status queries are part of resilience
When the outcome is uncertain, checking the state with the provider may be safer than immediately creating another attempt.
The specific design depends on the available APIs and the flow in use. Webhooks can also deliver an asynchronous update after the original request has ended.
This means the architecture must accommodate intermediate states and information arriving out of the expected order.
Webhook handling must be idempotent
Asynchronous events may be delivered more than once. They may also arrive after a status query or another internal update.
The consumer must recognize the event or operation identity and apply state transitions safely.
Failover cannot be designed only around the API's synchronous path. The full payment lifecycle includes subsequent messages and reconciliations.
Reconciliation is the final line of consistency
Even a well-designed architecture needs mechanisms to compare its internal state with provider records.
Reconciliation helps identify discrepancies, payments left in an uncertain state, and events that were not processed as expected.
The more routes there are, the more important it is to have a consolidated view of the business intent and technical attempts.
Circuit breakers and route protection
When a route repeatedly fails, continuing to send traffic can amplify the incident. A circuit breaker mechanism can temporarily stop new attempts on that route according to defined criteria.
This differs from simply marking a provider online or offline. Degradation can be partial and affect only certain operations.
The policy must balance a fast response against the risk of removing a route because of temporary noise.
A health check does not tell the whole story
A health endpoint may respond correctly while real transactions encounter problems. Likewise, an isolated failure does not necessarily mean a general outage.
Operational availability can therefore combine different signals, such as technical errors, latency, and transaction results.
The design must avoid hasty decisions based on a single indicator.
How should a retry policy be defined?
A retry policy should define conditions, intervals, the maximum number of attempts, and behavior when states are uncertain.
Retries on the same route may be appropriate for certain transient failures. In other cases, an alternative route may be considered. And in some situations, the correct action is not to retry.
What matters is that the policy is explicit, testable, and observable.
Backoff prevents retry storms
When many payments fail at once, immediate retries can increase the load on an already degraded service.
Progressive waiting strategies can reduce this effect for operations where retrying is appropriate.
In payments, however, the interval does not replace the need to know whether an operation can be safely repeated.
Failover and the checkout experience
Every new attempt adds time. An architecture can be technically resilient and still deliver a poor experience if the user waits indefinitely.
Timeout and fallback policies must therefore account for limits on customer-perceived latency.
Sometimes, ending the flow with a clear state is better than extending a chain of uncertain attempts.
How do you measure failover?
Useful metrics include technical failures by route, fallback counts, added time, attempts per payment, and outcomes of transactions eligible for recovery.
The recovery rate must be interpreted in context. An increase may indicate that the mechanism is helping, but it can also reveal frequent degradation on the primary route.
Failover metrics must be analyzed alongside provider health and the checkout experience.
Test failures before they happen
A failover policy that has never been exercised may produce surprises at exactly the wrong time: during an incident.
Test environments, simulations, and controlled fault injection mechanisms help verify state transitions and rule behavior.
The goal is to discover before production whether a timeout creates a duplicate, a late webhook overwrites a state, or an alternative route is actually available.
When does automatic failover make sense?
It makes the most sense when an operation has genuinely alternative routes, can classify failures confidently, and maintains consistent state control.
Without these conditions, automating the switch can create a false sense of resilience.
In some scenarios, the first step is to improve observability and reconciliation before automating new attempts.
What does AZPay have to do with failover?
Failover is part of the broader discussion about building payment infrastructure that is decoupled, observable, and ready for multiple paths.
The techniques presented here are architectural principles. They should not be interpreted as a statement that all these mechanisms are specific features currently available in AZPay.
The actual implementation depends on the platform's capabilities, the connected providers, and the rules defined for each operation.
Safe redundancy requires state
The second PSP is not the hardest part of failover. The hardest part is knowing when to use it.
To do that, the infrastructure must distinguish intent from attempt, failure from decline, timeout from a conclusive result, and an alternative from indiscriminate repetition.
Payment resilience does not mean trying more often. It means continuing to operate without losing track of what happened to the money.