Payment orchestration: what it is, how it works, and why use multiple PSPs

Reviewed on November 7, 2026.

As a digital operation grows, payments become more than an API integration. Different providers, acquirers, methods, markets, operating rules, and availability requirements enter the picture. Simply adding a second PSP may reduce one dependency while also creating another layer of complexity.

This is where payment orchestration comes in: an architecture that separates the intent to charge from the decision about how, through which path, and under what conditions a transaction should be processed.

Rather than scattering provider-specific rules throughout the application, an orchestration layer can centralize responsibilities such as routing, normalization, failure handling, observability, and attempt control.

What is payment orchestration?

Payment orchestration is an infrastructure layer that coordinates payment flows between a company and different PSPs, acquirers, methods, and financial services. It allows the application to stop treating each integration as an isolated path and work with different processing routes instead.

In a direct integration, the application sends a transaction to a PSP, which connects to the infrastructure needed to process it. When the company adds providers, the application must handle multiple paths. But connecting three PSPs does not, in itself, mean orchestration exists.

The application may still need to understand each API's specifics, decide when to use each integration, interpret different error codes, and control each attempt's state. With an orchestration layer, the application expresses an intent, such as processing a payment, while the infrastructure decides which permitted path should execute it.

Are payment gateways and orchestrators the same thing?

EMV 3-D Secure (opens in a new tab ↗) specifies cardholder authentication in e-commerce, and EMVCo payment tokenisation (opens in a new tab ↗) describes using a token in place of the PAN. PCI DSS (opens in a new tab ↗) is the PCI SSC standard for protecting account data when an operation handles it.

Not necessarily. A gateway traditionally provides the technology layer connecting an application to the infrastructure needed to process payments. Orchestration adds another responsibility: coordinating different components and possible paths within that infrastructure.

In practice, modern products may combine gateway and orchestration functions. Understanding architectural responsibilities is therefore more important than the commercial name.

A gateway mainly answers how to connect the application to processing. An orchestration layer adds another question: among the available paths, how do you decide and control where each payment goes?

Why does an operation integrate multiple PSPs or acquirers?

Using a single provider is not necessarily a problem. For simple operations, it may be the most rational choice. Every additional infrastructure layer also brings cost and complexity.

The problem appears when a single path concentrates too many dependencies. An outage, increased latency, communication error, or partial degradation can directly affect the ability to process payments.

There are legitimate reasons for a multi-PSP strategy: reducing dependence on one path, serving different markets or methods, creating operational alternatives, and letting the infrastructure choose routes according to context.

The right question, then, is not how many PSPs a company should have, but which architectural or business problem it wants to solve by adding another path.

Having multiple PSPs is not the same as orchestrating

Imagine an application with three integrations. It might send Brazilian transactions to PSP A, European transactions to PSP B, and use PSP C when a specific condition occurs. That already represents a form of routing.

But if all this intelligence is scattered throughout the application code, each new condition increases coupling between the business and provider-specific details.

Over time, decisions may consider country, currency, payment method, availability, performance, transaction characteristics, and business rules. Orchestration aims to make those decisions an explicit infrastructure responsibility.

How does an orchestration layer work?

An orchestration layer receives a payment intent and uses the available context to determine a permitted path. Instead of checkout directly knowing every PSP's details, it talks to a common layer that coordinates integrations.

This layer may combine normalization, state, routing, handling of certain failures, and observability. Deciding which path receives the transaction is payment routing.

The goal is not to hide that providers differ. It is to prevent the entire application from needing to know those differences.

What is payment routing?

Payment routing selects the route through which a transaction is sent for processing. A simple implementation may use deterministic rules, such as directing different currencies, markets, or methods to different providers.

That is already routing. It becomes more sophisticated as more signals inform the decision.

An architecture might consider market, currency, payment method, route availability, operational characteristics, and business rules. The route stops being merely a fixed consequence of the integration and becomes an infrastructure decision.

What is smart routing?

Smart routing generally describes an evolution of simple routing: choosing the route considers multiple signals or rules to determine the processing path.

This does not mean all smart routing uses artificial intelligence. A well-designed deterministic engine can also make sophisticated decisions. Statistical models and machine learning can be incorporated into specific architectures, but are not required for intelligent routing.

The essential point is separating the transaction from its path. Instead of an integration being permanently tied to one provider, the infrastructure evaluates which allowed route should be used in that context.

What happens when a provider fails?

Consider a payment sent to PSP A that encounters a technical problem. If another path is available, the infrastructure can evaluate whether the situation qualifies for another attempt through a different route.

This mechanism may be called fallback or failover, depending on the architecture and terminology. But one rule is fundamental: not every failure should trigger another attempt.

A technical failure differs from a legitimate decline. Receiving an explicit error response also differs from a timeout where it is not immediately known whether the provider processed the operation.

A retry strategy must therefore understand the previous attempt's state before deciding the next step. A negative issuer response, for example, should not automatically be treated as PSP unavailability.

Retry, fallback, and cascading

Terms may vary across platforms, but a conceptual model helps. A retry is another attempt to execute an operation. Depending on the design, it may use the same route or a different one.

Fallback means using an alternative when the primary path cannot or should not continue. Cascading describes a controlled sequence of attempts through different routes.

The most important word is controlled. A well-designed cascade must consider failure type, state, idempotency, operational limits, and user experience. Indiscriminately repeating a charge is not resilience.

Idempotency: the detail that helps prevent duplicate charges

Imagine an authorization sent to PSP A. The provider processes the operation, but its response never reaches the application. The system sees a timeout; from the PSP's perspective, the payment may have been authorized.

If the infrastructure simply treats the timeout as a definitive failure and immediately sends the same payment to PSP B, there is a risk of a second authorization.

A timeout therefore does not automatically mean the transaction failed. A resilient architecture must carefully control attempt states. Concepts such as idempotency, attempt identifiers, status queries, webhooks, and reconciliation become essential.

Orchestration is not just choosing where to send the transaction. It also means knowing what happened to every attempt.

A payment and an attempt are not the same

A useful model separates the business intent from the technical attempts to execute it. The same payment may generate an initial attempt that times out, a second that is declined, and, when rules and context allow, another that reaches a conclusive outcome.

The payment represents the business intent. The attempts represent the technical efforts to execute it.

This separation answers important questions: how many attempts occurred, which routes were used, what each outcome was, how long it took, and which attempt determined the final state.

Without this model, multi-PSP observability becomes much harder.

Observability is part of orchestration

With several providers, investigating a performance drop may involve different dashboards, codes, and naming conventions. Each provider may represent states, errors, and events differently.

An orchestration layer can help create a normalized view of operations. The question shifts from simply what PSP A says to what happened to the operation's payments.

This requires events, metrics, and states that track transaction lifecycles independently of the route used.

Observability is also needed to evaluate routing itself. If a rule changed the traffic distribution, the team must be able to measure the outcome of that change.

Normalization: each provider speaks a different language

Different providers may represent similar situations using different codes and structures. An abstraction layer can translate specific responses into a consistent internal model.

This normalization reduces coupling between business rules and API specifics and helps establish an internal payment language.

Instead of every part of the system needing to know how each PSP represents a timeout, capture, or reversal, connectors can translate them into states understood by the platform's domain.

Adapters and integration abstraction

A common technical approach to this problem uses adapters. The domain works with a common interface, while each adapter translates the intent for the relevant provider API.

The domain may work with operations such as authorize, capture, cancel, and reverse, while each adapter knows the specifics of its integration.

This does not mean pretending all providers are the same. A mature abstraction must hide unnecessary complexity without erasing each integration's specific capabilities.

The danger of perfect abstraction

Trying to create a universal API that hides absolutely every difference can lead to two extremes. In one, the platform reduces everything to the lowest common denominator and loses useful features. In the other, the common interface accumulates provider-specific options and stops being an abstraction.

The balance lies in maintaining a common domain model while preserving mechanisms for specific capabilities when they are needed.

This is one reason orchestration is an architectural problem, not just an API integration problem.

Orchestration is not just high availability

Redundancy is a possible benefit, but limiting payment orchestration to backup would narrow the concept too much. The same layer can inform decisions about routing, fallback, availability, geography, payment methods, experimentation, and observability.

This transforms payments from a fixed integration into an operationally controllable system.

The company stops thinking only about which provider is integrated and starts considering which routes are available, under which conditions they can be used, and how to measure each route's behavior.

When should a company consider orchestration?

There is no magic transaction count. The most important signal is when payment complexity or criticality begins to justify another layer.

Some signs are clear. The company maintains more than one PSP. Changing traffic distribution requires code changes and deployment. A single provider's outage interrupts processing capability. Operations span multiple markets. Or the team cannot quickly explain why payments are failing.

Before smart routing, the first problem to solve is often simply observability. Automating decisions the team cannot yet measure makes little sense.

When should you not use orchestration?

Adding a layer means adding software, configuration, monitoring, operations, cost, and new failure modes.

If a company serves one market, uses one provider, and has low operational complexity, a sophisticated multi-PSP engine may be overengineering.

A good architecture is not the one with the most components. It is the one that solves the problem with the least necessary complexity.

The decision to orchestrate should therefore arise from concrete needs, not a desire to add another layer to the diagram.

Build internally or use a platform?

When the need appears, the choice arises between building the layer internally and using a specialized platform.

Building may make sense when payments are a core competency, a specialized team is available, rules are highly specific, and scale justifies investment. But costs do not stop with the first release. Connectors, API changes, webhooks, normalization, routing, retries, observability, security, and new methods need ongoing maintenance.

A specialized platform can reduce some of this work, but introduces trade-offs such as vendor dependency, cost, portability, and customization limits.

The decision should consider flexibility, availability, security, observability, support for required providers, and the ability to evolve.

Tokenization also influences a multi-PSP strategy

Imagine a card tokenized within PSP A's context. The generated token is not necessarily usable by PSP B. This means an apparently multi-PSP architecture may remain dependent on one provider for certain credentials.

Credential portability, vaults, and tokenization strategy must therefore be part of the design from the start. Multi-PSP on a diagram does not necessarily mean multi-PSP in practice.

This discussion also shows why routing cannot be analyzed in isolation. A route is only truly usable if the infrastructure has the elements needed to execute the transaction there safely and compatibly.

3DS and authentication are also part of the design

Authentication adds another dimension. If a transaction goes through 3DS before following a route and that route fails, switching processors may have implications for the authentication context.

The consequence matters: failover should not be designed in isolation. Routing, authentication, tokenization, state, and processing must be considered parts of the same flow.

The more operations distribute payments across different paths, the more important it becomes to understand which information is portable between them and which is tied to a specific integration.

How do you measure an orchestration strategy?

If routing exists, the team must know whether it works. Useful metrics may include authorization rate, success rate by route, latency, fallback rate, recovery of eligible transactions, traffic distribution, and technical errors by provider.

Metrics also need context. Comparing two PSPs without controlling for differences in market, method, transaction profile, or traffic distribution can produce wrong conclusions.

An overall average can also hide relevant behavior. A route may perform very well in one context and worse in another. Segmentation and explainability therefore belong in the analysis.

Routing should not be a black box

When money is involved, decisions that are hard to explain are also hard to investigate. Mature infrastructure should link a routing decision to the conditions that produced it, without relying on manual interpretation.

If a transaction was sent to PSP B, operations should be able to understand why that route was chosen. It may have been a market, availability, or method rule, or a fallback condition.

The principle is operational explainability. Automation can increase infrastructure decision-making capability, but should not eliminate the human ability to investigate what happened.

Payments as a decision system

Historically, much payment infrastructure was built around the question: how do I send a transaction to a processor?

Orchestration introduces a broader question: how do I decide the best permitted way to process this transaction?

The shift turns a provider into a possible route and an integration into an architectural decision. Infrastructure stops being just a path for carrying requests and starts coordinating alternatives.

This matters because payments stop being treated only as connectivity. They become a system that must observe, decide, execute, and explain.

Where does artificial intelligence come in?

Artificial intelligence can support analysis and optimization, but is not required for intelligent routing. Before sophisticated models, more important foundations come first: reliable data, normalization, observability, state, rules, explainability, and feedback.

Without those foundations, adding a sophisticated model does not solve the architectural problem. It merely automates decisions on a foundation that may not yet be reliable.

A coherent progression starts with integration, moves through normalization and observability, adds routing and automation, and, where appropriate, evolves toward more sophisticated optimization mechanisms.

Intelligence depends on infrastructure, not the reverse.

What does AZPay have to do with this discussion?

AZPay approaches payment infrastructure as a building problem: understanding how flows work, reducing unnecessary coupling, and creating paths for operations to evolve without turning each new integration into another rigid dependency.

This does not mean every technique described in this article is a specific feature available in an AZPay product. Dynamic smart routing, cascading, automatic failover strategies, and optimization algorithms depend on each platform's concrete implementation.

The distinction matters. Technical content only builds authority when it separates architectural principles from features that have actually been implemented.

Frequently asked questions about payment orchestration

What is a payment orchestration platform? It is a technology layer used to coordinate payment-flow components, such as PSPs and acquirers, potentially centralizing routing, normalization, failure handling, and observability.

Do I need more than one PSP to use orchestration? Not every capability requires multiple PSPs, but routing between providers and multi-PSP redundancy naturally depend on alternative paths existing.

Does orchestration automatically increase approval rates? No. It creates mechanisms that may enable optimization, but outcomes depend on providers, rules, transaction profiles, markets, and other factors. Promising an automatic increase would be technically incorrect.

Does smart routing use artificial intelligence? Not necessarily. It may use deterministic rules, statistical models, optimization algorithms, machine learning, or combinations of these approaches.

Does failover recover every declined payment? No. Technical failures must be distinguished from declines, and you must understand which situations qualify for another attempt.

Are gateways and orchestrators competitors? Not necessarily. The responsibilities may coexist in the same product or appear in different layers.

Is it better to integrate PSPs directly or use an orchestrator? That depends on operational complexity. Direct integrations may suit simple scenarios. As providers, markets, methods, rules, and availability requirements grow, an orchestration layer tends to become more relevant.

From payment integration to payment infrastructure

An operation's first stage is usually simple: we need to accept payments. So we connect a provider.

Growth brings another question: do we need another provider? But the next stage should not simply be accumulating integrations.

The question becomes: how do we want our payment infrastructure to make decisions?

That is where orchestration begins.

A mature architecture does not only consider who processes. It considers how to choose, switch, observe, recover, explain, and evolve.

That is the difference between connecting payments and building payment infrastructure.

In the next article in this series, we will explore one of these decisions in greater depth: smart routing in payments and how to approach route selection for each transaction.