A payment gateway is a single integration layer connecting your platform to one payment processor — handling authorization, tokenization, and transaction routing to that provider. Payment orchestration is a management layer sitting above multiple gateways or processors, routing each transaction to the best-fit provider based on rules like cost, authorization rate, geography, or failover priority. A gateway is required for any platform to process payments at all — it’s the baseline. Orchestration becomes necessary once a platform runs two or more gateways and needs unified routing logic, consolidated reporting, or automatic failover between providers, since a single gateway has no visibility into, or control over, any other gateway.
Payment gateway and payment orchestration are often treated as competing choices, but they aren’t alternatives — one sits on top of the other. The confusion persists because vendors use both terms inconsistently, and many platforms reach orchestration before recognizing it as a distinct layer. McKinsey’s 2025 Global Payments Report cites rising ecosystem complexity as a key driver of that shift. This article defines both terms, maps the stack, and gives signals for when each applies.
What a Payment Gateway Does
A payment gateway is the technology layer that accepts a payment request from your platform, validates and encrypts the card data, and routes the transaction to the connected payment processor or acquirer for authorization. For platforms building this from scratch, payment gateway integration in a website covers the entry-level implementation path.
Specifically, a gateway tokenizes cardholder data before it moves further into the transaction flow — a process governed by the PCI Security Standards Council’s tokenization guidelines, which define how sensitive card data must be replaced with a surrogate value to reduce PCI DSS scope. It then forwards the authorization request to the processor, receives the authorization response, and handles 3DS2/SCA authentication for transactions that require it. Finally, it returns the result — approved, declined, or requires-action — to the merchant.
Function | What the Gateway Does | What It Does Not Do |
|---|---|---|
Transaction routing | Routes to its connected processor or acquirer | Does not route between multiple processors |
Card data handling | Tokenizes PAN at point of entry; reduces PCI scope | Does not manage tokens across multiple providers |
Authentication | Handles 3DS2 / SCA for applicable transaction types | Does not manage authentication across provider-specific flows |
Authorization | Sends authorization request; receives and returns response | Does not retry on a secondary provider on decline |
Settlement | Passes settlement instructions to connected processor | Does not consolidate settlement across multiple processors |
Reporting | Provides transaction data for its own processing volume | Does not unify reporting across multiple gateway integrations |
Failover | None — single provider connection | Failover requires an orchestration layer above the gateway |
Function
Transaction routing
Card data handling
Authentication
Authorization
Settlement
Reporting
Failover
What the Gateway Does
Routes to its connected processor or acquirer
Tokenizes PAN at point of entry; reduces PCI scope
Handles 3DS2 / SCA for applicable transaction types
Sends authorization request; receives and returns response
Passes settlement instructions to connected processor
Provides transaction data for its own processing volume
None — single provider connection
What It Does Not Do
Does not route between multiple processors
Does not manage tokens across multiple providers
Does not manage authentication across provider-specific flows
Does not retry on a secondary provider on decline
Does not consolidate settlement across multiple processors
Does not unify reporting across multiple gateway integrations
Failover requires an orchestration layer above the gateway
What a gateway does not do: it doesn’t decide which processor to use, retry a failed transaction on a different provider, compare authorization rates across providers, or consolidate reporting across multiple processing relationships. Those functions belong to the orchestration layer.
For platforms scoping their own build, how to build a payment gateway walks through the implementation in more detail.
What Payment Orchestration Does
Payment orchestration is a routing and management layer that sits above multiple payment gateways, processors, and acquirers — directing each transaction to the optimal provider based on configurable rules, and managing failover, reporting consolidation, and token management across every connected provider.
What orchestration adds that a single gateway cannot: intelligent routing between providers based on authorization rate, cost, geography, payment method, or time-of-day; automatic failover that reroutes a transaction when a primary provider declines or goes down; a unified token vault that lets a customer’s card-on-file persist across providers without re-collecting card data when routing shifts; and consolidated reporting across all processing relationships, rather than separate dashboards per gateway.
Function | What Orchestration Does | Requires Underlying Gateways? |
|---|---|---|
Multi-provider routing | Routes each transaction to the optimal provider based on rules (cost, authorization rate, geography, payment method) | Yes — routes between connected gateways/processors |
Intelligent failover | Automatically retries declined transactions on a secondary provider in real time | Yes — requires 2+ connected providers to fail over between |
Unified tokenization | Single token vault maps cardholder data across all connected providers | Yes — tokens resolve to provider-specific credentials at routing time |
Authorization rate optimization | Monitors per-provider authorization rates and adjusts routing dynamically | Yes — requires transaction-level data from multiple providers |
Consolidated reporting | Single reporting layer across all processing relationships and currencies | Yes — aggregates from all connected gateway/processor data feeds |
Smart retry logic | Applies card-network-specific retry rules on soft declines before failover | Yes — retry happens within the same provider before failover triggers |
Payment method coverage | Routes alternative payment methods (wallets, local payment methods, BNPL) to method-specific providers | Yes — each payment method requires its own provider integration |
Function
Multi-provider routing
Intelligent failover
Unified tokenization
Authorization rate optimization
Consolidated reporting
Smart retry logic
Payment method coverage
What Orchestration Does
Routes each transaction to the optimal provider based on rules (cost, authorization rate, geography, payment method)
Automatically retries declined transactions on a secondary provider in real time
Single token vault maps cardholder data across all connected providers
Monitors per-provider authorization rates and adjusts routing dynamically
Single reporting layer across all processing relationships and currencies
Applies card-network-specific retry rules on soft declines before failover
Routes alternative payment methods (wallets, local payment methods, BNPL) to method-specific providers
Requires Underlying Gateways?
Yes — routes between connected gateways/processors
Yes — requires 2+ connected providers to fail over between
Yes — tokens resolve to provider-specific credentials at routing time
Yes — requires transaction-level data from multiple providers
Yes — aggregates from all connected gateway/processor data feeds
Yes — retry happens within the same provider before failover triggers
Yes — each payment method requires its own provider integration
Orchestration does not replace gateways — it sits above them. Every transaction still passes through a gateway to reach a processor. What orchestration controls is which gateway handles a given transaction, and what happens automatically when that gateway can’t complete it.
How They Fit in the Payment Stack
The gateway and orchestration layer are not alternatives — they occupy different positions in the payment stack. Every architecture that uses orchestration still uses gateways underneath it.
The payment stack has four layers, and every transaction moves through them in order. A checkout or platform sits at the top and initiates the payment request. Below that, an orchestration layer is optional — it only exists once a platform has two or more gateways to route between, and its sole function is to decide which provider handles a given transaction. That decision, or the request itself when no orchestration layer is present, passes down to the gateway layer, where a single connected gateway (or one of several, if multiple are integrated) forwards an authorization request to a processor. At the base of the stack, card networks, acquirers, and processors return an authorization response that travels back up through the same path to the checkout.
The orchestration layer is optional until you need to route between multiple gateways. Strip it out, and the stack collapses cleanly to three layers — checkout, gateway, processor — which is the standard architecture for any platform running a single provider. Add a second or third gateway, and the missing middle layer becomes the routing logic a platform is forced to write into its own application code instead. That’s the core distinction: orchestration doesn’t sit alongside the gateway or replace it, it sits directly above it, and every transaction still passes through a gateway to reach a processor regardless of how that gateway was chosen.
Andrii Semitkin
Delivery Director at SPD Technology
“A platform with a single gateway integration does not need orchestration. A platform routing transactions across three gateways without a dedicated orchestration layer is doing orchestration manually — in application code, without the failover, reporting, and optimization capabilities a dedicated orchestration layer provides. Most platforms reach this point between $20M and $100M annual processing volume.”
When You Need a Gateway vs When You Need Orchestration
The right architecture depends on your current processing volume, provider count, and what the payment stack needs to do. Use this checklist to map your situation to the right layer — and if you’re weighing whether to build the underlying gateway yourself, build vs buy payment gateway breaks down that decision separately.
Gateway vs Orchestration Decision Signals
✓ | Signal | Points Toward |
|---|---|---|
☐ | Single payment provider handles all your transaction volume | Gateway only |
☐ | Processing volume below $20M annually | Gateway only |
☐ | Single currency, single market, standard card payment types | Gateway only |
☐ | No failover requirement — downtime on the provider is acceptable | Gateway only |
☐ | Operating two or more payment gateways or processors simultaneously | Orchestration layer |
☐ | Need automatic failover when primary provider is unavailable or declines | Orchestration layer |
☐ | Processing in 3+ currencies or markets with different optimal providers | Orchestration layer |
☐ | Authorization rate varies by provider — want to route to the best performer | Orchestration layer |
☐ | Handling multiple payment methods requiring different provider integrations | Orchestration layer |
☐ | Need consolidated reporting across all payment relationships | Orchestration layer |
☐ | Need a unified token vault so customers don’t re-enter card details | Orchestration layer |
☐ | Currently managing multi-provider routing in application code | Orchestration layer — replace the ad hoc logic |
✓
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
☐
Signal
Single payment provider handles all your transaction volume
Processing volume below $20M annually
Single currency, single market, standard card payment types
No failover requirement — downtime on the provider is acceptable
Operating two or more payment gateways or processors simultaneously
Need automatic failover when primary provider is unavailable or declines
Processing in 3+ currencies or markets with different optimal providers
Authorization rate varies by provider — want to route to the best performer
Handling multiple payment methods requiring different provider integrations
Need consolidated reporting across all payment relationships
Need a unified token vault so customers don’t re-enter card details
Currently managing multi-provider routing in application code
Points Toward
Gateway only
Gateway only
Gateway only
Gateway only
Orchestration layer
Orchestration layer
Orchestration layer
Orchestration layer
Orchestration layer
Orchestration layer
Orchestration layer
Orchestration layer — replace the ad hoc logic
Score interpretation: One to three signals in the “orchestration layer” column mean it’s worth evaluating whether orchestration is the right next step. Four or more signals mean an orchestration layer is the correct architecture for your stack. Zero signals in that column mean a well-integrated single gateway is the right answer for now.
Gateway vs Orchestration: Side-by-Side Reference
With the stack mapped and the decision signals scored, it’s worth putting the two layers head-to-head on every dimension that actually differentiates them. The table below it’s a reference for what changes, concretely, when a platform moves from a single gateway to an orchestration layer sitting above multiple gateways.
Dimension | Payment Gateway | Payment Orchestration |
|---|---|---|
What it is | Single integration point connecting your platform to one payment processor or acquirer | Routing and management layer above multiple gateways — decides which provider processes each transaction |
Where it sits in the stack | Between your platform and a single processor/acquirer | Above your gateways; routes to one of several connected providers |
Number of providers | One — the gateway connects to its own processing network | Two or more — the orchestration layer manages routing between them |
Failover | None — downtime on the provider means downtime for payments | Automatic — failed transactions retried on a secondary provider in real time |
Routing logic | None — all transactions go to the same processor | Configurable rules: by cost, authorization rate, geography, payment method, time-of-day |
Tokenization | Provider-specific — token works only with that gateway’s network | Unified vault — single token resolves to any connected provider at routing time |
Reporting | Single provider’s transaction data only | Consolidated reporting across all connected providers and currencies |
Authorization rate optimization | Not possible — single provider, no comparison basis | Dynamic routing based on live per-provider authorization rate monitoring |
When to use | Single provider, single market, < $20M volume, no failover requirement | > $20M volume; 2+ providers; multi-market; failover required; consolidated reporting needed |
Build vs buy | Build: 3–6 months for a basic custom gateway; buy: Stripe, Adyen, Braintree integrate in days | Build: 3–6 month orchestration layer; buy: Spreedly, Corefy, Primer; or use a multi-gateway PSP |
Dimension
What it is
Where it sits in the stack
Number of providers
Failover
Routing logic
Tokenization
Reporting
Authorization rate optimization
When to use
Build vs buy
Payment Gateway
Single integration point connecting your platform to one payment processor or acquirer
Between your platform and a single processor/acquirer
One — the gateway connects to its own processing network
None — downtime on the provider means downtime for payments
None — all transactions go to the same processor
Provider-specific — token works only with that gateway’s network
Single provider’s transaction data only
Not possible — single provider, no comparison basis
Single provider, single market, < $20M volume, no failover requirement
Build: 3–6 months for a basic custom gateway; buy: Stripe, Adyen, Braintree integrate in days
Payment Orchestration
Routing and management layer above multiple gateways — decides which provider processes each transaction
Above your gateways; routes to one of several connected providers
Two or more — the orchestration layer manages routing between them
Automatic — failed transactions retried on a secondary provider in real time
Configurable rules: by cost, authorization rate, geography, payment method, time-of-day
Unified vault — single token resolves to any connected provider at routing time
Consolidated reporting across all connected providers and currencies
Dynamic routing based on live per-provider authorization rate monitoring
> $20M volume; 2+ providers; multi-market; failover required; consolidated reporting needed
Build: 3–6 month orchestration layer; buy: Spreedly, Corefy, Primer; or use a multi-gateway PSP
A gateway is built to move transactions through one processing relationship, while orchestration exists to manage the tradeoffs — cost, authorization rate, uptime, geography — that only appear once a second provider enters the picture. A platform outgrows a gateway-only setup not because the gateway stops working, but because the questions it was never designed to answer — which provider is cheaper, which one is failing right now, which one authorizes better for this card type — start requiring answers of their own.
For platforms evaluating multi-market or multi-payment-method coverage specifically, mobile payment gateway integration covers how to choose the right implementation partner.
Key Takeaways
- A payment gateway and a payment orchestration layer are not alternatives — orchestration sits above gateways and routes between them, so every orchestration architecture still relies on gateways underneath it.
- Operating two or more payment providers without a dedicated orchestration layer means the platform is already doing orchestration manually, in application code, without the failover, reporting, or optimization a dedicated layer provides.
- A single, well-integrated gateway is the correct architecture below roughly $20M in annual processing volume; adding orchestration before that threshold increases system complexity without a proportional reliability or cost benefit.
- Failover is the most common orchestration trigger: a platform that cannot tolerate downtime on its primary payment provider needs a secondary provider and a routing layer that automatically redirects transactions when the primary fails.
- Switching primary payment providers without a unified token vault forces every existing customer to re-enter their card details, since card-on-file data does not transfer between providers by default.
- Unified tokenization across providers is the orchestration capability platforms most often underestimate, since its absence only becomes visible at the moment of a provider migration — by which point re-collecting card data from customers is already required.
In short: A gateway processes payments through one provider; orchestration routes intelligently across several — and the shift from one to the other is triggered by provider count, failover needs, and tokenization requirements, not by revenue alone.
FAQ
Is a payment orchestrator a payment gateway?
No — a payment orchestrator is not a payment gateway. A gateway connects your platform to a single payment processor and handles transaction routing to that provider. An orchestrator sits above multiple gateways and decides which one processes each transaction based on configurable routing rules. Every transaction that goes through an orchestrator still passes through a gateway — the orchestrator decides which gateway, and the gateway handles the authorization.
Do I need payment orchestration if I already use Stripe or Adyen?
Not always. Stripe or Adyen integration alone can cover everything a mid-sized platform needs — solid authorization rates, adequate market coverage, pricing that doesn’t eat into margins — in which case layering orchestration on top just adds infrastructure to maintain without solving a problem you actually have.
The picture changes once a second provider enters, whether that’s driven by expansion into a market where your primary processor underperforms, a chance to route certain card types to better rates elsewhere, or simply wanting a fallback so one processor’s outage doesn’t take down checkout. Plenty of platforms still run Stripe in that scenario — just not as the only option, but as one processor among several, handling the corridors it happens to be strongest in while Adyen or Checkout.com picks up the rest.
What is the difference between a PSP, a payment gateway, and a payment orchestrator?
A payment service provider (PSP) is a company that provides payment processing services — it may include a gateway, processing network, fraud tools, and reporting in a single commercial offering (Stripe, Adyen, and Braintree are PSPs). A payment gateway is the technical layer that routes transactions to a processor — it can be part of a PSP or a standalone integration (Authorize.net, NMI). A payment orchestrator is a routing and management layer above multiple PSPs or gateways — it is not a processor itself, it directs traffic between processors. Compliance obligations differ across all three layers; see payment gateway compliance and security for how PCI DSS and SCA requirements apply at the gateway level specifically. Platforms unsure whether their tokenization setup is actually reducing PCI scope as intended, rather than just assumed to be, can confirm it with a payment gateway security audit.
Can I build a payment orchestration layer myself?
Yes, and many platforms do. A custom orchestration layer — built as an internal routing service that manages connections to multiple gateway APIs — typically takes 3–6 months to build at production quality and requires ongoing maintenance as provider APIs change. The build decision makes sense when your routing logic is specific to your business (unusual payment method mix, specific geographic corridors, proprietary risk signals) and commercial orchestration platforms cannot be configured to replicate it. For a cost baseline before deciding, how much does it cost to build a payment gateway breaks down the underlying gateway costs that factor into any orchestration build. For standard routing requirements, commercial platforms (Spreedly, Corefy, Primer) typically deploy faster than a custom build.
What is smart routing in payment orchestration?
Smart routing is the capability of a payment orchestration layer to direct each transaction to the optimal provider based on live performance data rather than static rules. It monitors authorization rates per provider, card type, geography, and transaction amount in real time, and adjusts routing decisions dynamically to maximize the probability of authorization. A static routing rule sends all Visa transactions to Provider A; smart routing sends Visa transactions to Provider A when its authorization rate is higher than Provider B’s, and switches automatically when the relationship reverses.