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.
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 whatever 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. Merchants are live in minutes, not weeks.
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 compliance included — The payment layer carries PCI DSS Level 1 certification. The platform's PCI scope is effectively zero.
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 every PSP 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 — merchants go live in minutes
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 | Full PCI coverage — card data never touches the platform
Management portal | Analytics dashboard for the merchant | White-label portal for merchants, branded as the platform
Time to value | Weeks-months (PSP relationships must exist) | Weeks (PSP configuration included)
Revenue model for platform | Not applicable — orchestration serves the merchant | Revenue share on transactions — platform monetises payments
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 compliance that covers 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 as an available gateway. The enterprise customer's existing Worldpay 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 to monetise payments — earning revenue share on merchant transactions
You don't want PCI compliance burden — the payment layer carries it for you
You need to go live fast — weeks, not a multi-quarter engineering project
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. Adding smarter routing to a payment layer is a feature. The direction of travel matters.
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 good payment layer includes routing capabilities, 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 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.
[CTA section]
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 compliance included.
[Book a Demo] | [See Platforms]