What Is Payment Orchestration?
Payment orchestration is a software layer that sits between a merchant and multiple payment service providers (PSPs). Instead of integrating directly with each PSP individually, a merchant integrates once with the orchestration platform — and that platform handles the routing, failover, tokenisation, and reporting across all connected gateways.
The term "orchestration" is deliberately borrowed from distributed systems. Just as a service orchestrator coordinates microservices, a payment orchestration layer coordinates PSPs — deciding which one should process each transaction, what happens if it fails, and how payment data is stored and reused across gateways.
A critical point of clarification: payment orchestration platforms do not process payments. They direct them. The actual processing — acquiring, card network authorisation, settlement — still happens at the PSP level (Adyen, Stripe, Worldpay, Braintree, and so on). Orchestration is the routing intelligence on top of those processors.
How Payment Orchestration Works
The transaction flow through an orchestration layer looks like this:
Checkout → Orchestration Layer → Routing Decision → Selected PSP → Acquiring Bank → Settlement
Here is what happens at each stage:
1. The customer initiates a payment. The merchant's checkout page (or mobile app, or in-store terminal) captures payment details and passes them to the orchestration platform via API or SDK.
2. The orchestration layer makes a routing decision. Based on pre-configured rules or machine learning models, the platform selects the best PSP for this specific transaction. Routing logic might consider: the card's issuing country, the transaction currency, the BIN range, real-time PSP availability, historical authorisation rates by PSP for this card type, or fee structures.
3. The transaction is submitted to the selected PSP. The orchestration layer formats and forwards the payment request to the chosen gateway. The PSP communicates with the card networks and acquiring banks to authorise the transaction.
4. If the transaction is declined, failover kicks in. The orchestration layer automatically retries the transaction with a different PSP — without the customer needing to re-enter their details. This is sometimes called cascading or waterfall routing.
5. The token is stored in a PSP-agnostic vault. Rather than storing a card token that only works with one PSP, the orchestration platform maintains its own token vault. The same token can be used to submit subsequent transactions to any connected gateway — which is essential for subscriptions, one-click checkout, and card updater flows.
6. The result is reported centrally. The orchestration layer aggregates transaction data, authorisation rates, fee breakdowns, and performance metrics across all PSPs into a unified dashboard.
Why Payment Orchestration Exists
The multi-PSP problem is real. As merchants scale internationally, they accumulate PSP relationships: a primary processor for domestic transactions, a regional gateway in Southeast Asia, a specialist for recurring billing, a legacy relationship they cannot easily switch off.
Each direct PSP integration is a maintenance commitment. API versioning, webhook handling, token formats, error code translation, reconciliation formats — they are all different per PSP. Multiply that across five gateways and you have a significant ongoing engineering overhead.
The specific drivers that push merchants toward orchestration are:
Geographic coverage. No single PSP has optimal acquiring relationships, approval rates, and pricing in every market. A merchant expanding into Latin America or Southeast Asia often needs a local PSP to achieve acceptable authorisation rates on domestic cards.
Redundancy. PSPs have outages. A merchant processing thousands of transactions per hour cannot afford to have a single point of failure. Multi-PSP routing with automatic failover is insurance against downtime.
Rate optimisation. Different PSPs negotiate different interchange-plus fees with card schemes. High-volume merchants route transactions to minimise effective processing costs, often saving meaningful basis points at scale.
Regulatory requirements. Some markets require transactions to be processed by a locally licensed entity. Payment orchestration makes it straightforward to route specific transactions to a compliant local processor without rebuilding the checkout layer.
Legacy relationships. Enterprises often have existing contracts, minimum volume commitments, or reconciliation integrations with processors they cannot switch off immediately. Orchestration lets them add new PSPs without deprecating the old ones.
Key Features of Payment Orchestration Platforms
A fully featured payment orchestration platform typically includes:
Smart routing engine. Rules-based or AI-driven transaction routing. Routing rules can be deterministic (always route Visa cards in Germany to PSP X) or dynamic (route to the PSP with the highest approval rate for this BIN in the last 24 hours). More sophisticated platforms use machine learning to predict approval probability per PSP per transaction in real time.
Failover and cascade routing. Automatic retry logic when a transaction is declined or a gateway is unavailable. The platform defines the cascade sequence — which PSPs to try, in what order, under what conditions — without customer-facing friction.
PSP-agnostic tokenisation vault. A centralised card data environment that stores PAN data or network tokens independently of any single PSP. The vault issues its own token, which can be exchanged for PSP-specific tokens at the point of transaction submission. This is what makes it possible to route a returning customer's card to any PSP.
Unified API. A single integration endpoint for the merchant, abstracting away the differing APIs of each underlying PSP. When a new PSP is added to the platform, the merchant does not need to write new integration code.
Analytics and reporting. A consolidated view of transaction data across all PSPs — authorisation rates, decline reason codes, fee analysis, currency breakdown, PSP performance comparisons. Some platforms integrate directly with finance systems for reconciliation.
Fraud orchestration. Integration with fraud tools (Kount, Sift, Forter) as part of the pre-authorisation flow. Some orchestration platforms let merchants define fraud rules that influence routing decisions — for example, routing suspected fraud to a PSP with stronger 3DS support.
Payment method management. Support for multiple payment methods (cards, bank transfers, wallets, local payment methods) across the PSP connections, with the orchestration layer handling method-to-PSP mapping.
Who Uses Payment Orchestration?
Payment orchestration is primarily enterprise merchant infrastructure. The typical users are:
Large e-commerce retailers processing cross-border card transactions at volume
Online travel agencies managing high-value, multi-currency bookings
Digital media and subscription businesses needing high authorisation rates on recurring charges
Ticketing platforms handling card-on-file and retries at scale
The leading orchestration platforms are:
Spreedly — focused on vault infrastructure and gateway connectivity. Spreedly connects to over 120 gateways, making it one of the most widely integrated orchestration vaults. The core value proposition is PSP-agnostic card storage and network token orchestration. Strong with platforms and marketplaces that need flexible PSP routing without a rigid workflow builder.
Primer — positions around a no-code workflow builder and a unified payment API. Merchants and technical teams can configure routing logic, fraud rules, and payment method behaviour through a visual interface without writing gateway-specific code. Popular with mid-market to enterprise merchants who want rapid iteration on payment logic.
Gr4vy — cloud-native orchestration built on containerised infrastructure. Each merchant deployment runs in an isolated cloud environment, which Gr4vy argues improves security and compliance. Strong positioning around data residency and sovereignty requirements, particularly relevant for merchants operating in regulated markets.
Payment Orchestration vs Payment Gateway
These two terms are sometimes confused. The distinction is fundamental.
Payment Gateway | Payment Orchestration | |
|---|---|---|
Function | Processes transactions | Routes transactions between gateways |
Examples | Stripe, Adyen, Worldpay, Braintree | Spreedly, Primer, Gr4vy |
PSP relationships | Is the PSP | Connects to multiple PSPs |
Standalone? | Yes — you can use a gateway directly | No — requires at least one gateway behind it |
Integration complexity | One integration | One integration (replaces many) |
Who needs it | Everyone accepting payments | Merchants already using multiple PSPs |
Typical user | Any business accepting payments | Enterprise merchants, complex routing needs |
A payment gateway is necessary infrastructure for anyone accepting digital payments. Payment orchestration is optional infrastructure that becomes valuable once a merchant is operating across multiple gateways and the complexity of managing them directly becomes a real cost.
Payment Orchestration vs Payment Layer
This is the distinction that matters most if you are a software platform rather than a merchant.
Payment orchestration is merchant-focused infrastructure. It is designed to help merchants optimise their own payment stack — route transactions more intelligently, reduce declines, lower fees, consolidate PSP management. The merchant is the end user of the orchestration platform. The merchant's customers are the cardholders.
A payment layer is platform-focused infrastructure. It is designed to help software platforms embed payments for their own merchants. The platform is building a product that its merchants will use. The platform is not the end user — its merchants are.
These are different problems:
A merchant using orchestration asks: "How do I get more of my transactions approved, at lower cost, across the PSPs I already use?"
A platform building with a payment layer asks: "How do I embed payment acceptance into my product so my merchants can get paid — through cards, bank transfers, payment links, voice, and more — without each merchant needing their own PSP contract?"
Orchestration gives you routing APIs. A payment layer gives you white-label tools, merchant onboarding flows, multi-channel payment support, and a commercial model that lets you participate in payment revenue.
For the full breakdown of where these categories overlap and where they diverge, see the dedicated guide: Payment Orchestration vs Payment Layer.
Limitations of Payment Orchestration for Platforms
If you are building a SaaS platform, CX platform, or marketplace and evaluating orchestration as your payments infrastructure, there are structural limitations worth understanding.
No white-label merchant tools. Orchestration platforms expose APIs for routing and vault management. They do not provide hosted checkout pages, payment link generators, or embeddable payment components that your merchants can use directly. You would need to build those layers yourself.
No merchant onboarding. Orchestration platforms do not onboard your merchants as sub-merchants. Each merchant would need to establish its own PSP relationships, go through its own KYC/KYB, and manage its own settlements. For a platform with dozens or hundreds of merchants, this is not a scalable model.
No multi-channel payment support. Orchestration is built for web and API-initiated transactions. It does not include voice payment flows, payment links for agents or SMS, or pre-built integrations with contact centre or chat platforms. These are increasingly important for platforms serving industries like insurance, utilities, and financial services.
No platform revenue model. Orchestration platforms charge the platform (or merchant) for routing services. They do not provide a commercial structure for the platform to earn a share of payment processing revenue on transactions flowing through their product.
Complex integration timelines. Connecting to an orchestration platform, configuring routing rules, building out the merchant-facing tooling, and handling onboarding can take months of engineering time. The unified API simplifies PSP integration but does not eliminate the product development work on top.
Payment orchestration was designed for merchants optimising their own payment stack. It was not designed as a foundation for platforms building payment products for other businesses.
When You Need Orchestration vs When You Need More
Here is a straightforward decision framework:
You likely need payment orchestration if:
You are a merchant (not a platform) processing payments directly
You are already integrated with two or more PSPs
Your primary problem is authorisation rate optimisation or PSP redundancy
You need PSP-agnostic tokenisation for a card-on-file or subscription model
Your engineering team has the capacity to manage the orchestration integration and build on top of it
You likely need a payment layer if:
You are a software platform, SaaS company, or marketplace adding payments for your merchants or users
You need to onboard merchants and have payments flow to their accounts, not yours
You need payment support across channels — not just web checkout, but payment links, voice, and agent-initiated flows
You want white-label tools your merchants can use without your own product development
You want to participate in payment revenue as a platform
You need to go live quickly, without months of infrastructure build
The pattern that emerges: orchestration solves the multi-PSP complexity problem for merchants. A payment layer solves the "how do we make payments a core part of our platform product" problem for software companies.
Some platforms start by evaluating orchestration because the category is more visible and the vendors are well-funded. But orchestration was not designed to answer the questions a platform actually needs to answer — and that mismatch becomes apparent quickly once integration starts.
Related Reading
Payment Orchestration vs Payment Layer — the full deep dive on the distinction between routing infrastructure for merchants and embedded payment products for platforms
Payment Orchestration Alternatives for Platforms — why platforms outgrow orchestration, and what they reach for instead
Shuttle vs Spreedly — vault infrastructure and gateway connectivity vs an embedded payment product for platforms
Shuttle vs Primer — merchant routing workflows vs platform payments with multi-channel support
Shuttle vs Gr4vy — cloud-native orchestration architecture vs a payment layer built for platforms
PSP-Neutral vs Single-PSP Architecture — when PSP flexibility matters and when it is over-engineering
How Shuttle Fits In
Shuttle is not a payment orchestration platform. Shuttle is a PSP-neutral payment layer built for platforms.
The distinction matters. Orchestration optimises payment routing for merchants who already have PSP relationships. Shuttle gives platforms the infrastructure to embed payment products for their own merchants — including white-label hosted checkout, payment links, voice payments, and agent-assisted collection flows — without building it from scratch.
Shuttle connects to multiple PSPs (Stripe, Adyen, Worldpay, and others), so the routing flexibility that makes orchestration attractive is present. But the product layer on top — the merchant onboarding, the white-label tools, the multi-channel support, the platform commercial model — is what separates a payment layer from an orchestration platform.
If your problem is merchant routing optimisation, one of the orchestration platforms covered in this guide is probably the right answer. If your problem is embedding payments into your platform product so your merchants can collect money, that is a different category — and a different conversation.
Book a discovery call to explore whether a payment layer fits what you are building. Or see how Shuttle works for platforms to understand the product before we talk.