Two Solutions That Sound Similar But Solve Different Problems
If you're a software platform evaluating how to add multi-PSP payment support, you'll encounter two categories: payment orchestration and payment layers. If the question is how many providers to hold rather than which category of software to buy, start with single global PSP vs multiple local acquirers.
They share surface-level similarities: both connect to multiple PSPs, both promise to simplify payment infrastructure. But they solve fundamentally different problems, serve different audiences, and require different integration approaches.
Choosing the wrong one wastes months and creates technical debt that's expensive to reverse.
What Payment Orchestration Does
Payment orchestration platforms route transactions across multiple PSPs based on rules. They sit between a merchant (or platform) and a set of payment gateways, making decisions about where to send each transaction.
Core capabilities:
Smart routing: Send transactions to the PSP most likely to approve them, based on card type, geography, amount, or historical performance
Failover: If PSP A declines or is down, automatically retry with PSP B
Tokenisation: Store card tokens in a vault that works across multiple gateways
Analytics: Compare PSP performance (authorisation rates, fees, speed) in one dashboard
Who it's designed for: Merchants processing high volumes who want to optimise authorisation rates and reduce costs by routing intelligently across their existing PSP relationships.
The value proposition: "You already have multiple PSPs. We'll help you route between them better."
Key players: Primer, Spreedly, and a growing list of platforms positioning as orchestration solutions.
What a Payment Layer Does
A payment layer embeds multi-PSP payment infrastructure into a software platform, so the platform's merchants can accept payments through the compatible PSP they need, across whatever channel the platform supports.
Core capabilities:
PSP-neutral payment processing: Connect to 40+ gateways through a single integration. Merchants choose their PSP or the platform assigns one.
White-label merchant onboarding: Pre-built onboarding flows branded as the platform's own.
Multi-channel coverage: Embedded checkout, voice payments, payment links, chat payments, AI agent payments, all through the same integration.
Management portal: Branded dashboard for merchants to view transactions, process refunds, and manage payment settings.
PCI scope limited: the payment layer carries PCI DSS Level 1 certification, which limits the platform's PCI scope.
Who it's designed for: Software platforms that need to embed payment capabilities for their merchants, where different merchants may require different PSPs, and payments may happen across multiple channels.
The value proposition: "Your platform needs to offer payments. We make 40+ PSPs and every channel available through one integration, branded as yours."
The Core Distinction
Here's the simplest way to think about it:
Orchestration optimises how an existing merchant routes transactions across PSPs they already have.
A payment layer enables a platform to offer multi-PSP payments to merchants who don't have payment infrastructure yet, or who need their existing PSP to work within the platform's workflows.
Payment Orchestration | Payment Layer | |
|---|---|---|
Primary user | Merchant (or merchant's engineering team) | Platform (embedding payments for many merchants) |
Core function | Route and optimise transactions across PSPs | Embed multi-PSP payment capabilities into software |
Merchant onboarding | Not included: merchant manages PSP relationships directly | White-label onboarding included |
Channel coverage | Online checkout (web/mobile) | Checkout, voice, payment links, chat, AI agents |
PSP relationships | Merchant brings their own | Merchant brings their own OR platform provides |
PCI compliance | Reduces scope for tokenisation; card capture still requires PCI setup | Limited PCI scope: card data never touches the platform |
Management portal | Analytics dashboard for the merchant | White-label portal for merchants, branded as the platform |
Why This Matters for Platforms
If you're a software platform (a SaaS company, a marketplace, a CCaaS provider, an ERP) and you need to embed payments, here's why the distinction is critical:
Orchestration doesn't solve the platform problem
Orchestration assumes the merchant already has PSP relationships and wants to optimise routing between them. But most platform merchants don't have this setup. They need the platform to provide payment capabilities: onboarding, checkout, compliance, and all.
An orchestration layer gives you multi-PSP routing. It doesn't give you:
A way to onboard merchants onto those PSPs
A branded checkout experience for your merchants' customers
A merchant portal for self-service refunds and reporting
Voice or link-based payment channels
PCI DSS Level 1 card capture (not just token storage)
The enterprise PSP mandate problem
Here's the scenario that reveals the gap most clearly:
Your platform has embedded checkout using Stripe. An enterprise customer says: "We have a Worldpay contract and we're not switching."
With an orchestration layer, you'd need Worldpay already configured as a connection. Your enterprise customer would need their own Worldpay account provisioned and connected. And you'd still need to handle onboarding, checkout rendering, and PCI compliance for the Worldpay flow.
With a payment layer, you configure Worldpay Access as an available gateway. The enterprise customer's existing Worldpay Access credentials are connected during onboarding. Their payments route through Worldpay using the same checkout, the same portal, and the same compliance envelope that every other merchant on your platform uses. It's a configuration change, not an engineering project.
Multi-channel is the multiplier
Orchestration focuses on online checkout: routing a web transaction to the optimal PSP. But payments increasingly happen beyond checkout:
A contact centre agent takes payment over the phone
An AI voice agent processes a renewal
A payment link is sent via SMS after a service call
A chat agent captures payment mid-conversation
Orchestration doesn't cover these channels. A payment layer does, through the same integration, the same PSP configuration, and the same compliance environment.
When Orchestration Is the Right Choice
To be clear: payment orchestration solves a real problem. It's the right choice when:
You're a merchant (not a platform) processing high volumes across multiple PSPs and want to optimise authorisation rates through intelligent routing
You already have PSP relationships and need a technical layer to manage routing, failover, and retry logic
Your primary goal is transaction optimisation: improving approval rates, reducing processing costs, A/B testing PSP performance
You don't need to embed payments for others: your payments are for your own business, not for merchants on your platform
If you're processing $100M+ annually and losing revenue to failed authorisations, orchestration can pay for itself through routing optimisation alone.
When a Payment Layer Is the Right Choice
A payment layer is the right choice when:
You're a platform that needs to offer payment capabilities to merchants or customers
Your merchants need PSP flexibility: different merchants require different gateways
You need white-label payments: branded onboarding, checkout, and merchant portals
You need multi-channel coverage: payments happen via checkout, voice, links, chat, or AI agents
You want one integration across 40+ PSPs
You want to limit your PCI scope: card data goes to the gateway through the payment layer's certified environment and never touches your platform
The Convergence Question
"Won't orchestration platforms add embedding features? Won't payment layers add routing?"
Some convergence is inevitable. But the architectures are fundamentally different:
Orchestration is built merchant-out: it starts with transaction routing and adds features around it. The merchant is the primary user.
A payment layer is built platform-out: it starts with embeddability and adds PSP connectivity behind it. The platform is the primary user, and merchants are the platform's customers.
Adding white-label onboarding, multi-channel capture, and platform-level merchant management to an orchestration architecture is a ground-up rebuild.
FAQ
Is a payment layer just orchestration with extra features? No. The architecture is different. Orchestration optimises routing for a merchant's transactions. A payment layer provides payment infrastructure that a platform embeds for its merchants. They share multi-PSP connectivity but differ in who they serve, how they're integrated, and what they include.
Can I use both? Technically yes: a platform could use a payment layer for embedding and an orchestration layer for routing optimisation. In practice, this adds unnecessary complexity. A payment layer already sets which gateway handles each payment method and each merchant, and the added value of standalone orchestration diminishes when the platform layer is handling PSP connectivity.
Which has better PSP coverage? Depends on the provider. Orchestration platforms typically connect to 50-100+ gateways. Payment layers may connect to fewer (40+) but include white-label onboarding and multi-channel support for each. Coverage numbers alone don't tell the story: what matters is whether the PSPs your merchants need are supported, and whether the channels you need are covered.
What about Stripe/Adyen: are they orchestration or payment layers? Neither. Stripe and Adyen are PSPs: payment gateways that offer platform tools (Stripe Connect, Adyen for Platforms). They're excellent PSPs, but they lock you into their processing network. You can't "orchestrate" to Worldpay through Stripe Connect, and you can't embed Worldpay through Adyen for Platforms. They want to be your only PSP, which works until an enterprise customer demands otherwise.
Need a payment layer, not an orchestration platform? Shuttle gives platforms a single integration for 40+ PSPs across embedded checkout, voice, payment links, and AI agent payments, with white-label merchant onboarding and PCI DSS Level 1 certification that limits your PCI scope.