Why Platforms Don't Want to Be Payment Companies

By shuttle-team, February 18, 2026

The PayFac model traps platforms into owning payment infrastructure they never wanted. Here's why platforms need a payment layer, not a PayFac licence.

Nobody starts a platform company thinking about payments.

They think about the workflow. The vertical. The problem their software solves. Payments are assumed. A box to tick, not a business to build.

Then the first enterprise customer shows up and asks which PSPs you support.

That's when it gets complicated.

The conversation nobody planned for

Enterprise buyers don't just want payments to work. They want specific providers. They have existing contracts with Worldpay, or Adyen, or their regional acquirer. They have procurement rules. Compliance requirements. Treasury mandates.

And they expect the platform to support all of it.

For the platform, this creates a problem that gets worse with every new customer. Each PSP integration is a six-month project. Each one adds PCI scope. Each one drags engineering resources away from the product roadmap.

Multiply that by five enterprise customers with different PSP requirements, and suddenly payments aren't a box to tick. They're a roadmap tax.

The PayFac trap

The conventional answer is: become a PayFac.

Register as a payment facilitator. Own the merchant onboarding. Control the funds flow. Take a cut of every transaction.

On paper, it looks like a revenue opportunity. In practice, it's a trap for most platforms.

Becoming a PayFac means taking on regulatory obligations. KYC. AML. PCI DSS compliance at the highest level. Ongoing audits. A payments team you never planned to hire.

And here's the part nobody mentions upfront: it locks you into a single PSP relationship. Your enterprise customers don't get choice. They get whatever provider you chose when you became a PayFac.

That works for SMB merchants who don't have existing PSP relationships. It breaks the moment you sell to enterprise.

The platform that becomes a PayFac optimises for payment revenue. The platform that stays PSP-neutral optimises for enterprise deal velocity. Those are very different strategies.

What platforms actually want

Talk to any platform CTO or Head of Product about payments, and the same themes come up:

"We don't want to become a payments company." They want to ship payment features without taking on the operational weight of running payment infrastructure.

"Enterprise deals demand specific PSPs." Their customers already have provider relationships. The platform needs to support them, not replace them.

"Payments keep hijacking the roadmap." Every new PSP integration pulls engineers off product work. The cost isn't just development time. It's the features that don't get built.

"We need it live in weeks, not quarters." The platform market moves fast. A 12-month payments build project is a competitive disadvantage.

These aren't edge cases. This is the standard experience for any platform selling to mid-market and enterprise buyers.

The layer that solves this

What platforms need isn't a PSP. It's a layer between their software and PSPs.

A single integration point that connects to the providers their customers already use. That handles PCI compliance so the platform doesn't have to. That supports payments across every channel the platform operates in, whether that's embedded checkout, voice, links, or chat.

That's what Shuttle built.

One integration. 40+ PSPs. PCI DSS Level 1, ISO 27001, SOC 2. Voice, links, chat, and embedded checkout on the same layer. White-label merchant onboarding and a management portal included.

Platforms ship payment features in weeks. Enterprise customers keep their existing PSP. The platform roadmap stays focused on the product, not on payments plumbing.

Invoice Stack integrated Shuttle and went live across multiple PSPs without building a payments team. As Harry Bevan put it: "Shuttle let us add payments without having to own or manage payments ourselves. Our customers can bring their own gateways, and we were able to improve the payment experience and scale without hiring a payments or finance team."

Brightpearl did the same for commerce. INSTANDA for insurance. The pattern is the same: platform integrates Shuttle, enterprise customers bring their PSPs, payments ship fast.

The real cost of doing nothing

Some platforms delay the decision. They build one PSP integration, usually Stripe, and figure they'll deal with multi-PSP when it becomes a problem.

It becomes a problem faster than they expect.

The first enterprise deal that requires a non-Stripe provider forces a build-or-lose-the-deal decision. The second one makes it clear this isn't going away. By the third, the platform is maintaining multiple bespoke integrations with no abstraction layer, and every new one takes longer than the last.

The average platform that builds this themselves spends $360k per year maintaining payment infrastructure. That's before the $2M in PCI compliance costs and 12 months of development time that could have gone into product.

Doing nothing is also a strategy. It just shows up as lost deals and a slower roadmap.

The question to ask

If your platform is heading upmarket, selling to enterprise, or expanding into new channels like voice and chat, the question isn't whether you'll need a payment layer.

The question is whether you build it yourself or plug into one that already exists.


Related Reading

Talk to us

Make enabling payments for your platform and merchant users easy.

Book a Call