What Stripe Actually Did
In a move that received surprisingly little attention given its strategic weight, Stripe began opening Checkout, Billing, and Radar to merchants processing on other payment providers — Adyen, PayPal, and others.
To be clear about what this means technically: a merchant could previously only use Stripe Checkout if they were processing transactions through Stripe. The checkout UI, the billing engine, the fraud tooling — all of it was bundled with Stripe's processing stack. Use Stripe's services, use Stripe's rails. That was the deal.
The unbundling changes that. Merchants can now access Stripe's value-added service layer without routing transactions through Stripe. Stripe Checkout on top of Adyen processing. Stripe Radar's fraud signals on top of PayPal. The experience layer and the processing layer become independently selectable.
This is not a minor product update. It is a structural repositioning — and it signals something important about where the payments market is heading.
Why Stripe Unbundled: The Strategic Logic
Stripe built one of the most successful lock-in strategies in the history of fintech. The logic was elegant: make the developer experience so good that switching becomes unthinkable. Bind the checkout UI to the billing engine. Bind the billing engine to the fraud tooling. Bind all of it to Stripe's processing rails. Every layer of the stack reinforces the others. Leaving one means leaving all.
That strategy worked exceptionally well — right up to the point where it started costing Stripe enterprise deals.
Enterprise customers mandate their PSPs. They have negotiated rates, compliance frameworks, and treasury infrastructure tied to existing gateway relationships. A CTO at an enterprise insurance carrier is not switching from Worldpay to Stripe because the checkout experience is nicer. A procurement team at a large travel operator is not unwinding a multi-year PSP contract to access Stripe's billing engine.
Stripe's response to this reality — for years — was to improve the product and wait for enterprise adoption to follow. But enterprise payment infrastructure is sticky in a way that developer-led adoption is not. The lock-in that protected Stripe's merchant base from leaving also protected enterprise customers from joining.
The unbundling is an acknowledgement of that reality. Stripe is saying: if you won't come to our rails, we'll bring our services to yours. It is a concession that the vertical integration strategy has a ceiling — and Stripe is choosing to grow through the ceiling rather than stay inside it.
There is also a competitive logic. Adyen, Checkout.com, and Worldpay are not standing still. Enterprise payment infrastructure has improved materially. The processing layer is increasingly commoditised at the high end. Stripe's genuine differentiation has always been in the experience layer — Checkout's conversion optimisation, Radar's fraud accuracy, Billing's subscription management. Unbundling these services lets Stripe compete on the dimensions where it is strongest, rather than trying to win processing volume against entrenched enterprise PSPs on their home turf.
What This Means for Platforms
The immediate read on Stripe's unbundling is merchant-centric: more flexibility for merchants who want Stripe's UX without Stripe's rails. That is true. But the deeper implication is about platforms.
If Stripe — the company that built the most successful vertically integrated payments stack in history — is decoupling its experience layer from its processing layer, it is because the market is forcing that decoupling. Stripe is not doing this out of generosity. It is doing it because the alternative is losing the market.
That market signal should inform how platforms think about their own payment architecture.
A platform that standardises on a single PSP is making a bet that the vertically integrated model still holds — that bundling checkout, processing, and value-added services through one provider is the right architecture for the next five years. Stripe's own move suggests that bet is getting riskier, not safer.
Enterprise customers are increasingly unwilling to accept payment infrastructure they did not choose. PSP mandates are a real and growing force in enterprise sales cycles. A platform that cannot support a customer's existing PSP relationship does not win that deal. This is already the reality — Stripe's unbundling is simply the market's most prominent player adapting to it publicly.
For platforms, the implication is direct: the architecture that protects your enterprise revenue is not the one that locks you to a single PSP. It is the one that separates the experience layer from the processing layer — so that when an enterprise customer arrives with a Worldpay mandate, the answer is "no problem" rather than "three months of engineering work."
The Horizontal Payment Layer
Stripe's unbundling reveals a structural shift in how payment infrastructure is being organised. The question it forces is: if the experience layer and the processing layer are separable, what sits between them?
The answer is what we would call a horizontal payment layer — infrastructure that connects across PSPs rather than within a single one.
The vertically integrated model — one PSP owning checkout, billing, fraud, and processing — made sense when the payments market was fragmented and the primary problem was developer friction. Stripe solved that problem better than anyone. But the next problem is different: how do you manage payment infrastructure across multiple PSPs, channels, and geographies without rebuilding everything for each one?
That problem is horizontal, not vertical. It is not about making one PSP's stack better. It is about making any PSP's stack accessible through a consistent interface.
A horizontal payment layer:
Connects to 40+ PSPs through a single integration point
Abstracts the processing layer so that changing or adding a PSP is configuration, not engineering
Applies consistent merchant onboarding, checkout experience, and compliance standards regardless of which PSP is underneath
Covers multiple payment channels — embedded checkout, voice, payment links, chat, AI agents — through the same infrastructure
Handles PCI scope so that neither the platform nor the merchant inherits it
This is structurally different from what either Stripe or an orchestration tool offers. Stripe unbundling its services layer still presupposes that the merchant has a Stripe relationship. An orchestration tool optimises routing between PSPs but does not handle merchant onboarding, channel expansion, or platform distribution. The horizontal payment layer does all of it — it makes PSPs portable into software platforms.
Stripe's move validates this model. When the market's most vertically integrated player starts unbundling, the market is telling you that horizontal infrastructure is the durable architecture. The control point in multi-PSP payments is not any individual PSP's stack. It is what sits across all of them.
What Platforms Should Do Now
Stripe's unbundling is a market signal, not a tactical instruction. Here is what it should change about how platforms think:
Stop assuming a single PSP is the safe default
The conventional wisdom — "standardise on Stripe and keep it simple" — was defensible when the market rewarded vertical integration. It is less defensible now. Stripe's own strategy is moving away from the all-or-nothing model. Platforms should move before enterprise deal losses force them to.
Separate your experience layer from your processing layer
This is the structural move Stripe is making at the PSP level. Platforms should make the same move at the platform level. Your checkout UI, your merchant onboarding, your payment configuration — these should not be tightly coupled to any single PSP's API. When you need to add a gateway, it should be a configuration change, not an engineering project.
If you are currently building direct PSP integrations one by one, you are building technical debt that compounds with every new enterprise customer mandate. The comparison between PSP-neutral and single-PSP architectures is no longer primarily about flexibility as a nice-to-have. It is about whether your platform can compete for enterprise customers.
Think in channels, not just checkout
Multi-PSP is part of the answer. But the broader shift is that payments are no longer a checkout event. Enterprise merchants are increasingly processing payments over voice calls, via SMS links, through AI agent conversations, and across embedded channels that have nothing to do with a web checkout page.
A horizontal payment layer covers these channels through the same integration. A direct PSP integration — even with multiple PSPs — typically covers online checkout only. Adding voice, links, or AI agent payment capture is a separate project.
Stripe's unbundling is, at its core, about separating the channel from the processor. Platforms should apply the same logic more broadly: payment infrastructure that works across all channels regardless of which PSP is underneath.
Treat PSP relationships as merchant assets, not platform constraints
One of the clearest signals from Stripe's move: PSP relationships increasingly belong to merchants, not platforms. Merchants want to keep their existing PSP relationships — their negotiated rates, their compliance certifications, their treasury integrations. A platform that forces merchants onto its chosen PSP is not winning on the basis of better payments. It is winning on the basis of convenience — and that advantage erodes as enterprise merchants become less willing to accept payment constraints from their software vendors.
Platforms that monetise payments without PSP lock-in capture more of the enterprise market and generate more durable payment revenue. PSP choice becomes a competitive differentiator in enterprise sales, not a concession.
Move before your competitors do
The platforms that recognise this shift early get to design their architecture for the multi-PSP world. The platforms that wait get forced into a costly migration when the first enterprise PSP mandate kills a deal they needed to close.
Stripe's unbundling tells you the direction of travel. The question is whether your platform's payment infrastructure is built for where the market is going — or where it was five years ago.
The Bigger Picture
There is a tempting read of Stripe's unbundling as a sign of weakness — that Stripe is losing ground and unbundling is a defensive measure. That reading misses the point.
Stripe is one of the most strategically sophisticated companies in payments. The unbundling is not a retreat. It is a recognition that the market is multi-PSP, and that Stripe's best position in a multi-PSP world is as a services layer — not as a monolithic stack that forces an all-or-nothing choice.
That is a smart move. But it validates something that PSP-neutral infrastructure providers have been building toward for years: the processing layer is separating from the experience layer, and the infrastructure that connects them horizontally is where durable value accumulates.
The multi-PSP world is not a transition phase on the way back to a winner-takes-all processing market. It is the destination. Payment infrastructure is becoming horizontal. The control point — for platforms, for PSPs, and for the companies that sit between them — is what connects across all providers.
Stripe's unbundling is the most visible signal yet that the market knows this.
Related Reading
Shuttle vs Stripe Connect — how single-PSP constraints play out in practice
PSP-Neutral vs Single-PSP: Which Approach Is Right? — the architectural decision for platforms
How Platforms Monetise Payments Without PSP Lock-In — why PSP flexibility drives more revenue
Enterprise PSP Mandates: Why Platforms Need Multiple Gateways — the business case for multi-PSP
Shuttle vs Stripe Connect (Alternatives) — evaluating your options
Shuttle is the PSP-neutral payment layer for platforms. 40+ PSP integrations through a single API. White-label checkout, merchant onboarding, and PCI DSS Level 1 compliance included. Your merchants keep their PSP. Your platform keeps its roadmap.