Your platform started with one PSP, one integration, one currency. Now a second market needs a local provider, or a large client wants an alternative rail. Or a failed transaction with Provider A needs to retry automatically through Provider B. The gateway that got you here doesn't do any of that on its own.
TL;DR
A payment gateway moves data, not risk. It encrypts and routes transaction details to a processor or acquirer. It doesn't hold funds, underwrite risk, or decide which provider handles a transaction.
Payment orchestration is a coordination layer, not a rebrand of a gateway. It sits above other PSPs, gateways, and rails, and routes each transaction to the right one based on cost, success rate, or failover rules.
Most companies with one or two payment providers don't need orchestration yet. The trigger point is two or more active providers, multi-market routing, or a documented failover requirement, not a specific transaction volume.
The build-vs-integrate decision is organizational as much as technical. Someone owns provider relationships and failure handling either way. Orchestration decides whether that sits inside your team or with a partner.
What does a payment gateway actually do?
A payment gateway is a data pipe. It encrypts card or account details, passes them to a processor or acquiring bank, and returns an approval or a decline. That's the entire job.
A payment service provider (PSP) does more. It bundles the gateway with merchant acquiring and, often, underwriting, under a single contract.
That replaces separate deals with a processor, an acquirer, and a bank. Stripe and Adyen are PSPs, not plain gateways. An acquirer is the bank that holds the merchant relationship with the card scheme and actually settles the funds.
Confusing these three roles is where most orchestration conversations go wrong. Adding a second PSP integration and building an orchestration layer solve different problems, and the difference matters before you commit engineering time to either one.
Get payment gateway vs PSP vs orchestration straight first, because the wrong mental model here leads to the wrong build.
What is payment orchestration, and how is it different from a gateway?
Payment orchestration works one layer up from a gateway. It sits above your gateways, PSPs, and rails, and decides which one handles each transaction in real time. The rules are yours to set: cost, success rate, geography, or which provider is currently healthy.
That answers whether orchestration is just a gateway with a new name. It isn't. A gateway processes a transaction you've already routed. An orchestration layer makes the routing decision itself. It retries automatically through a second provider if the first one fails, and reconciles the result across every provider it touched.
That's the shape of a payment orchestration layer: a coordinating layer above every gateway, PSP, and rail a platform runs, not a bigger gateway. The distinction condenses into four roles:
Layer | What it does | What it doesn't do |
Payment gateway | Encrypts and routes transaction data to a processor | Doesn't hold funds or choose between providers |
PSP | Bundles gateway, acquiring, and a single merchant contract | Doesn't coordinate across other PSPs |
Acquirer | Settles funds with the card scheme on the merchant's behalf | Doesn't manage routing logic or failover |
Orchestration layer | Routes, retries, and reconciles across every provider and rail | Doesn't replace the providers themselves |
What does a payment orchestration platform actually do?
In production, multi-provider payment routing comes down to three jobs: routing, retries, and reconciliation. Each transaction goes to the right provider, retries automatically if one fails, and reconciles across every rail a platform runs.
xpate's multi-rail payment platform is what this looks like at full complexity. Gateway integrations support 3M+ monthly transactions with automated settlement. Multi-currency accounts run across SEPA, SEPA Instant, SWIFT, and FPS, through Ibanq, Incore, Inventi, and MyEuPay simultaneously.
An FX layer through CurrencyCloud and Banking Circle handles 300+ transactions a month. Crypto rails run through the CEX.io API at 240+ transfers a month. Card payouts move through Ginger and Silverflow at 440,000+ payouts a month.
That's six payment paths and four simultaneous provider integrations. It's the kind of complexity that shows up in serious fintech payment infrastructure work, and no single gateway integration handles it alone.
Do you need payment orchestration, or is a gateway enough?
"Do I need payment orchestration?" is the question that actually matters, and for most teams, the honest answer is not yet. Below that threshold, orchestration is over-engineering, not insurance.
Add it when you hit one of three triggers. Two or more active providers in production, routing across multiple markets or currencies, or a failover requirement your board or compliance team has flagged.
The large client asking for an alternative rail, from the opening, is trigger one. A second active provider, nothing more dramatic than that. It's also where the negotiating room comes from: two providers competing for the same volume gives you a real number to argue rates with, not a guess.
Market access is the other half of that trigger. A new market often needs a payment method or rail your current PSP doesn't support, and orchestration is what adds it without touching what already works.
A legacy payment system that grows market by market without a coordinating layer is a familiar pattern. One European bank's infrastructure expanded from three SEPA countries to 36 only after moving to a cloud-based, coordinated setup.
Below that threshold, bolting on a second gateway integration is usually the right call. Above it, the coordination becomes the actual engineering problem.
Who owns the orchestration layer: build, integrate, or partner?
Whichever gateway or provider you add next, someone owns two things: the provider relationship and failure handling when a transaction fails. Orchestration doesn't remove that ownership. It just decides whether it sits centrally, with one team, or gets split by rail.
In practice, that means one engineer or a small platform team owns provider SLAs, routing changes, and the pager when a rail degrades. Split it across rails instead, and nobody owns a failed transaction from start to finish.
That's harder to dodge because the market keeps blurring the line. Form3 positions itself as real-time payments infrastructure with API-first connectivity across SEPA, SWIFT, and UK and US rails. Banking Circle bundles SEPA, SWIFT, FX, and AML and KYC access under one BaaS platform.
Neither is a full orchestration layer, but both coordinate more than a plain gateway. That's exactly why 'just add a gateway' stops being a clean answer once partners like these are on the table.
That's the real build-vs-integrate question. Cost optimization favors owning every relationship yourself. Speed favors a partner who already owns the contracts. Treated as an architecture decision tied to that goal, most teams get the call right the first time.
Key insights
A gateway moves data. An orchestration layer moves decisions. Conflating the two is why pitches for either one end up sounding identical.
Two or more providers is the real threshold, not transaction volume. The trigger is provider count, market count, or a documented failover requirement.
xpate-style complexity, six rails and four simultaneous integrations, is orchestration's natural habitat. Below that, a second gateway integration is usually enough on its own.
The decision is organizational before it's technical. Whoever owns provider relationships and failure handling owns the outcome, whether that's your team or a partner.
Teams that get this right choose the threshold before they hit it, not after a failed transaction forces the question. The ones that wait usually end up building the orchestration layer under a deadline instead of on their own schedule.
Authors
Jakub Matuszak
Marketing Specialist at The Software House, focused on B2B tech insights and turning complex topics into actionable guidance for engineering leaders.