The Pattern
It starts the same way for every platform.
A customer asks: "Can we pay through your software?" Then an enterprise prospect says: "We need embedded payments, and we need Worldpay, not Stripe." Then your product team is fielding payment questions in sprint planning. Then your CTO is estimating a months-long roadmap for payment infrastructure.
Payments have gone from a nice-to-have to a requirement. And the first answer most platforms hear is: "Become a PayFac."
Don't.
What Is a PayFac (and Why Platforms Consider It)
A Payment Facilitator (PayFac) is a business that processes payments on behalf of sub-merchants under its own merchant ID. Think Stripe, Square, or PayPal. They're PayFacs. Your merchants don't have individual merchant accounts; they process through the PayFac's account.
The appeal for platforms is clear:
One integration across every transaction your merchants process
Control over the payment experience
Stickiness: merchants using your payments don't churn easily
It sounds like the right move. Here's why it usually isn't.
Why Becoming a PayFac Is Harder Than It Looks
Regulatory Burden
PayFacs are regulated entities. You're responsible for:
KYC/AML compliance for every merchant you onboard
Transaction monitoring across your entire merchant base
Fraud liability: chargebacks and disputes are your problem
State and federal licensing in every jurisdiction you operate
Ongoing reporting to your acquiring bank and card networks
This isn't a checkbox exercise. It's an operational function that requires dedicated compliance staff, legal counsel, and ongoing investment.
PCI Compliance
Processing payments means handling card data. That puts you in PCI DSS scope, potentially at Level 1, the highest certification level.
Capital Requirements
Your acquiring bank will require a reserve: capital you hold against potential fraud, chargebacks, and processing losses. The amount depends on volume and risk profile, but it's real money sitting in a trust account.
Time to Market
Building PayFac infrastructure takes months. That includes acquiring bank relationships, compliance frameworks, technology integrations, underwriting processes, and certification. Your enterprise customers are asking for payments now, not months from now.
Ongoing Maintenance
PSP APIs change. Compliance requirements evolve. Card network rules update. Fraud patterns shift. Each of these requires engineering time, compliance review, and operational adjustment: time that comes directly off your product roadmap.
The Real Cost
Platforms that pursue PayFac status typically spend:
Months before processing a single transaction
Ongoing costs for infrastructure and operations (one platform saved $360K in a year by not building and maintaining its own)
Engineering capacity diverted from core product
What Platforms Actually Need
Most platforms don't need to be a PayFac. They need four things:
1. Embedded Payments That Feel Native
A checkout, payment form, or payment flow that lives inside your platform, branded as yours. The merchant's customer never leaves your interface. They never see a third-party brand.
White-label means your brand, your colours, your domain. The payment infrastructure is invisible.
2. Merchant Onboarding That Doesn't Require a Compliance Team
KYC, compliance checks, and PSP provisioning handled in a single flow, without your team doing the underwriting.
3. PSP Flexibility
This is where most solutions fall short.
If you embed Stripe, your merchants use Stripe. If you embed Adyen, your merchants use Adyen. This works until an enterprise customer says: "We have a Worldpay relationship and we're not switching."
PSP-neutral infrastructure lets your merchants bring their own PSP, or you choose the PSP for each merchant. One integration, any compatible gateway.
4. Multi-Channel Coverage
Payments don't just happen at checkout anymore. Your platform may need:
Embedded checkout in your web or mobile app
Payment links sent via email, SMS, or chat
Voice payments for phone-based workflows
AI agent payments for automated sales or service channels
A payment layer supports all of them.
The Alternative: A Payment Layer
Instead of becoming a PayFac, use a payment layer that sits between your platform and PSPs.
Here's what that looks like:
You integrate once. A single API connects your platform to 40+ payment gateways. Adding a new gateway doesn't require new integration work.
Your merchants choose their PSP. Or you choose for them. Or different merchants use different gateways based on geography, volume, or preference. Each merchant's payments go to the gateway set for that merchant.
PCI scope is limited. The payment layer is PCI DSS Level 1 certified. Card data never touches your infrastructure, which limits your PCI scope.
You skip the build. Pre-built merchant onboarding, checkout components, and a management portal, white-labelled to your brand. No months-long build project.
You offer payments to your merchants. They keep their own PSP contracts and rates, and you avoid the regulatory and operational burden of being a PayFac.
You expand to new channels. Voice, links, chat, AI agents: all through the same integration. Add a new payment channel without re-engineering your payment stack.
PayFac vs. Payment Layer: A Direct Comparison
| Becoming a PayFac | Using a Payment Layer |
|---|---|---|
PCI compliance | You carry it | Limited; provider is PCI DSS Level 1 |
PSP flexibility | You are the PSP | Any compatible PSP, merchant's choice |
Merchant onboarding | You build it | Pre-built, white-label |
Regulatory burden | Full (KYC, AML, licensing) | Minimal |
Capital requirements | Reserve account required | None |
Engineering investment | Ongoing engineering time | Single integration |
Control | Full | High (white-label, configurable) |
The honest trade-off: PayFac gives you more margin per transaction and more control. But it costs more, takes longer, and consumes engineering resources that could be building your core product.
For most platforms, the math doesn't work.
When a PayFac Model Does Make Sense
To be fair, there are cases where becoming a PayFac is the right move:
Payments are your core product. If you're building a payments company, not a platform that needs payments, then owning the stack makes strategic sense.
You have the scale to justify the investment. Processing billions in annual volume with the margins to support a dedicated compliance and engineering team.
You need pricing control at the merchant level. Setting your own interchange-plus rates, controlling underwriting criteria, managing risk directly.
You already have the compliance infrastructure. Financial services companies, banks, and regulated entities that are already PCI certified and licensed.
If none of these apply, a payment layer is the faster, cheaper, and more flexible path.
The Enterprise PSP Problem
This deserves its own section because it's the pain point that pushes most platforms toward a payment layer.
Enterprise customers mandate their PSP. It happens in every industry:
Insurance platforms: carriers require specific payment processors
Travel and hospitality platforms: airlines, hotel chains, and operators have existing PSP relationships
ERP platforms: enterprise clients won't switch PSP for a software vendor. For a deeper look at the ERP-platform pattern specifically, see Embedded Payments for ERP Platforms.
Contact centres: clients bring their own gateway and expect the platform to support it
If you've built your payments on Stripe, and an enterprise customer requires Worldpay, you have three options:
Turn down the deal. This is what usually happens.
Build a Worldpay integration. And then another one for the next customer's PSP. And another. Each one takes months and expands your PCI scope.
Use a PSP-neutral payment layer. One integration supports any compatible gateway the customer brings.
Enterprise PSP mandates are a common reason platforms move from single-PSP to multi-PSP infrastructure. A payment layer makes this a configuration change, not an engineering project.
FAQ
What's the difference between a PayFac and a payment aggregator? A PayFac processes transactions under its own merchant ID, with sub-merchants beneath it. An aggregator pools transactions from multiple merchants through a single account. In practice, the terms are often used interchangeably, but PayFac implies more control and more regulatory responsibility.
Can I still offer payments without being a PayFac? Yes. A payment layer lets you offer payments to your merchants without carrying the regulatory, compliance, or operational burden of being a PayFac.
What about PayFac-as-a-Service (PFaaS)? Providers like Payrix and Finix offer "PayFac in a box": you get PayFac-like capabilities without building everything from scratch. This reduces the build time but still carries compliance obligations, and typically locks you into a single PSP. It's a middle ground that works for some platforms but doesn't solve the multi-PSP problem.
What if I've already started down the PayFac path? It's not too late to change course. Many platforms that began building PayFac infrastructure have switched to a payment layer approach after realising the ongoing cost and complexity. The sunk cost is real, but the ongoing savings usually justify the switch.
Related Reading
PayFac Alternatives for Platforms: the full landscape of PayFac alternatives
Shuttle vs PayFac-as-a-Service (Payrix, Finix): how PFaaS compares to a payment layer
How to Get Payments Off Your Product Roadmap: the hidden cost of building and maintaining payment infrastructure
Enterprise PSP Mandates: Why Platforms Need Multiple Gateways, the enterprise pain point that drives multi-PSP adoption
Shuttle vs Building In-House: the full build-vs-buy analysis
Gateway vs Orchestrator vs PayFac vs Payment Layer: how a payment layer differs from gateways, orchestrators, and PayFac models
Payment Links for Hotels & Holiday Accommodation: how travel platforms embed payment links without PayFac overhead
Car Dealership Payment Solutions: payment infrastructure for automotive platforms
Payment Infrastructure for Food Ordering Platforms: food platforms embedding payments without becoming a PayFac
Payments Are Eating 5-9% of Your Revenue: why the PayFac build cost surprises most platforms
Shuttle replaces the PayFac build with a single integration: 40+ PSPs, white-label checkout, merchant onboarding, voice payments, and a PCI DSS Level 1 environment that limits your PCI scope.
Book a Demo | See How It Works