If you're a software platform trying to add payments, you've probably encountered four different approaches — and a lot of confusion about which one applies to you.
This guide breaks down each option: what it does, who it's designed for, and where it falls short for platforms. It also introduces a newer category — The Payment Layer — that was built specifically for the problem platforms actually face.
Quick Comparison
Gateway | Orchestrator | PayFac | Payment Layer | |
|---|---|---|---|---|
What it does | Processes transactions | Routes between PSPs | Makes you the PSP | Embeds payments inside software |
PSP relationship | Is the PSP | Sits above PSPs | Replaces the PSP | Distributes PSPs |
Who it serves | Merchants | Merchants | Platforms wanting to be PayFacs | Platforms wanting to NOT be PayFacs |
Channels | Checkout page | Checkout page | Checkout page | Voice, links, chat, embedded, workflows |
Multi-tenant | No | Limited | Yes (heavy) | Yes (thin) |
Time to live | Weeks | Months | 6-12 months | Days to weeks |
PCI scope | Merchant owns it | Merchant owns it | Platform owns it | Layer owns it |
Examples | Stripe, Adyen, Worldpay | Primer, Spreedly | Stripe Connect, Adyen for Platforms | Shuttle |
What Is a Payment Gateway?
A payment gateway is the core infrastructure that authorises and processes card transactions. When a customer enters their card number on a checkout page, the gateway communicates with the acquiring bank, the card network, and the issuing bank to approve or decline the transaction.
Gateways are the foundation of online payments. Every digital transaction flows through one. The most recognised gateways — Stripe, Adyen, Worldpay, Checkout.com — also function as acquirers and payment service providers (PSPs).
What gateways do well
Process transactions reliably at scale
Handle card-present and card-not-present payments
Provide fraud screening and tokenisation
Offer well-documented APIs for direct integration
Where gateways fall short for platforms
Gateways are designed to serve merchants, not platforms. When a platform integrates a gateway directly:
Each merchant on the platform needs a separate merchant account or sub-account
The platform is locked into that single PSP — if a customer already uses a different provider, the platform can't accommodate them
Expanding to new payment channels (voice, links, chat) requires separate integrations
PCI compliance falls on the platform or merchant
A gateway answers the question "how do I process a payment?" It doesn't answer "how do I embed payments inside my software for hundreds of merchants across multiple PSPs?"
What Is a Payment Orchestrator?
A payment orchestrator sits above multiple gateways and routes transactions between them. The premise: instead of integrating with one PSP, integrate with an orchestration layer that connects to many.
Orchestrators like Primer and Spreedly offer a single API that abstracts multiple gateway connections. They handle retry logic, failover routing, and transaction optimisation — sending each payment to whichever gateway is most likely to approve it at the lowest cost.
What orchestrators do well
Abstract multiple PSP connections behind a single API
Optimise routing for approval rates and cost
Reduce gateway lock-in for merchants with multiple processors
Provide a unified reporting layer across PSPs
Where orchestrators fall short for platforms
Orchestrators solve merchant-side routing complexity. They're designed for a single business that uses three or four gateways and wants to optimise which gateway handles which transaction.
For platforms, the problem is different:
Platforms don't need to route their own transactions across PSPs — they need each customer to use their own PSP
Orchestrators are still checkout-page-centric — they don't natively support voice payments, payment links, or AI agent conversations
Multi-tenancy is bolted on, not built in — onboarding hundreds of merchants through an orchestrator requires significant custom work
PCI compliance still falls on the platform
An orchestrator answers "how do I optimise routing across my PSPs?" It doesn't answer "how do I let each of my customers bring their own PSP?"
For a deeper comparison, see our guide on payment orchestration vs The Payment Layer.
What Is a PayFac?
A Payment Facilitator (PayFac) is a model where a platform becomes a registered payment processor. Instead of each merchant on the platform having their own merchant account with a bank, the PayFac holds a master merchant account and onboards sub-merchants underneath it.
Stripe Connect and Adyen for Platforms are the best-known PayFac-as-a-service models. They let platforms process payments on behalf of their merchants without obtaining a full PayFac licence independently — though the platform still takes on significant compliance and operational overhead.
What PayFac models do well
Give platforms control over the merchant experience
Enable revenue sharing on payment processing
Provide merchant onboarding and KYC workflows
Handle fund flows and settlement splits
Where PayFac models fall short for platforms
The PayFac model requires the platform to become a payment company:
Compliance overhead is substantial — even with managed PayFac services, the platform takes on PCI scope, AML/KYC responsibilities, and ongoing regulatory obligations
Time to market is 6-18 months depending on the approach
The platform is locked into the PayFac provider — if a customer already has a relationship with a different PSP, the PayFac model can't accommodate that
Revenue comes from payments margin, which requires volume to justify the investment
Engineering focus shifts from core product to payment infrastructure
A PayFac model answers "how do I own the payment relationship?" But most platforms don't want to own the payment relationship. They want payments to work inside their product — without the overhead of becoming a processor.
For alternatives to the PayFac path, see our guide on embedded payments without becoming a PayFac.
What Is The Payment Layer?
The Payment Layer is a different category of infrastructure — designed specifically for software platforms that need to embed payments without becoming a payment company.
Instead of processing transactions (gateway), routing between PSPs (orchestrator), or making you the processor (PayFac), The Payment Layer sits between platforms and PSPs as thin, portable infrastructure. The platform integrates once. The layer handles everything else.
How it works
The platform integrates once — a single API connection to The Payment Layer
**Each customer brings their own PSP** — or the platform connects them to any of 40+ supported providers
The layer handles compliance — PCI DSS Level 1 is owned by the layer, not the platform
Payments work across channels — voice, links, chat, embedded checkout, workflows — all through the same integration
Merchant onboarding is white-labelled — the platform's brand, not the layer's
What The Payment Layer does differently
**PSP-neutral by design.** The platform doesn't choose a PSP for its customers. Each customer uses their existing PSP — or picks from the full range. This is critical for enterprise deals where customers mandate specific processors.
**Multi-channel from day one.** Voice payments, payment links, embedded checkout, and chat payments all work through the same integration. Platforms don't need separate projects for each channel. See how this works for voice payments and payment links.
Thin, not heavy. The Payment Layer doesn't replace the PSP. It doesn't replace the platform's product. It connects the two — with the minimum infrastructure needed to handle compliance, onboarding, and payment capture.
Platform-native multi-tenancy. Every concept in The Payment Layer is multi-tenant by default. Merchants, PSP connections, payment channels, and reporting all scope to the platform's customer base — not to a single merchant account.
Decision Framework: Which Do You Need?
You need a gateway if...
You're a single merchant processing your own transactions
You need direct control over payment processing
You're building a checkout experience for your own customers
You need an orchestrator if...
You're a large merchant using multiple PSPs
You want to optimise routing for approval rates and cost
You process enough volume that gateway arbitrage matters
You need a PayFac if...
Payment revenue is core to your business model
You want full control over the merchant relationship
You're willing to invest 12+ months and significant capital in compliance infrastructure
Your customers don't have existing PSP relationships they need to keep
You need The Payment Layer if...
You're a software platform and your customers need payments inside your product
Your customers have their own PSPs (or need flexibility to choose)
You need payments across multiple channels — not just checkout pages
You don't want to become a payment company
You need to ship payments in weeks, not quarters
PCI compliance should not be your platform's responsibility
Most platforms that evaluate PayFac models or direct PSP integrations discover that what they actually need is The Payment Layer. The requirement isn't "own the payment relationship." The requirement is "make payments work inside our product — fast, flexibly, and without the overhead."
How The Payment Layer Compares to Specific Solutions
vs Stripe Connect
Stripe Connect is a PayFac model — it makes your platform the processor, locks you into Stripe, and limits you to Stripe's channels. The Payment Layer supports Stripe as one of 40+ PSPs without making the platform dependent on any single provider.
vs Adyen for Platforms
Adyen for Platforms is Adyen's equivalent — powerful but Adyen-exclusive. The Payment Layer lets platforms support Adyen alongside other PSPs, rather than choosing one and building around it.
vs Spreedly / Primer
These are orchestrators optimised for merchant-side routing. The Payment Layer serves platforms, not merchants — and adds multi-channel capabilities (voice, links, chat) that orchestrators don't offer.
vs Building It Yourself
Building multi-PSP support, PCI compliance, voice payments, and merchant onboarding internally takes 12-18 months and pulls engineering away from core product development. Getting payments off your roadmap is the primary value of The Payment Layer.
FAQ
Is The Payment Layer a gateway? No. Gateways process transactions. The Payment Layer connects platforms to gateways — any gateway — without the platform building each connection.
Is The Payment Layer an orchestrator? No. Orchestrators optimise routing for merchants with multiple PSPs. The Payment Layer enables platforms to support whichever PSP each of their customers uses — a fundamentally different problem.
**Do I still need a PSP?** Yes. The Payment Layer doesn't process transactions. It connects your platform to PSPs. Your customers either bring their existing PSP or choose one from the 40+ providers the layer supports.
**What about PCI compliance?** The Payment Layer handles PCI DSS Level 1 compliance. Card data passes through the layer's PCI-certified infrastructure — your platform never touches it, even during voice payment calls.
How long does integration take? Most platforms go live in days to weeks, depending on the channels they need. Compare this to 6-12 months for a PayFac setup or months of work for multi-PSP direct integrations.
**Can I start with one channel and add more later?** Yes. Many platforms start with payment links or embedded checkout and later add voice payments or chat payments — without new integration projects.
*Shuttle is The Payment Layer for software platforms. One integration. 40+ PSPs. Voice, links, chat, and embedded checkout. See how it works or book a discovery call.*