The Distribution Problem PSPs Won't Talk About
Here's a truth the payment industry avoids saying clearly:
PSPs don't lose to other PSPs. They lose to software.
When a merchant chooses an insurance platform, a contact centre system, or an ERP — the payment processor embedded in that software becomes the default. The merchant doesn't run a PSP evaluation. They use what's already there.
The platform chose the PSP. The merchant inherited it.
This dynamic is reshaping the payments industry. And for PSPs that aren't embedded in the right software, it's an existential problem.
How Payments Moved Inside Software
For decades, payment processing was a standalone decision. A business selected a PSP, integrated it, and processed transactions. The PSP's distribution model was direct — sales teams, bank partnerships, ISO relationships.
That model still exists. But it's losing ground to a different one:
Software-led distribution. Merchants adopt software to run their business — a vertical SaaS platform, a marketplace, an operating system for their industry. Payments are a feature of that software. The PSP is invisible.
Consider:
A property management platform includes rent collection. The PSP is embedded.
A dental practice management system handles patient billing. The PSP is embedded.
A field service platform captures payments on-site. The PSP is embedded.
A contact centre platform processes phone payments. The PSP is embedded.
In each case, the merchant's "payment decision" was actually a software decision. The PSP came along for the ride.
This means PSP distribution is increasingly a function of which software platforms have embedded which PSPs. Not which PSP has the best rates, the best API, or the best sales team.
The Math That Worries PSPs
A PSP's traditional sales motion:
Sales team → merchant → integration → live
Cost per acquisition: high (sales rep, onboarding, integration support)
Time to revenue: months
Scale: linear with sales headcount
A PSP embedded in a software platform:
Platform → builds integration once → every new merchant on the platform processes through the PSP
Cost per merchant acquisition: near zero (the platform does the selling)
Time to revenue: instant (merchant is live when they join the platform)
Scale: exponential with platform growth
A single platform deal can deliver hundreds or thousands of merchants. A single sales rep can't.
This is why every major PSP now has a "platforms" or "ISV" programme. Stripe has Connect. Adyen has Adyen for Platforms. Worldpay has its ISV partnerships. They've all recognised that software is the distribution channel.
Why It's Harder Than It Looks
PSPs face three structural challenges when trying to get embedded in software platforms:
1. Platforms Want Choice
The moment a PSP gets embedded in a platform, it controls that platform's payment infrastructure. The platform is dependent on the PSP's pricing, features, geographic coverage, and roadmap.
Smart platforms resist this dependency. They want PSP flexibility — the ability to support multiple gateways, switch providers, or let enterprise customers bring their own PSP.
A PSP offering "embed me exclusively" is asking the platform to accept lock-in. Increasingly, platforms say no.
2. Bespoke Integrations Don't Scale
Every platform has different requirements. Different checkout flows, different merchant onboarding processes, different channel needs (voice, links, AI agents), different compliance requirements.
A PSP building bespoke integrations for each platform is running a professional services operation, not a scalable distribution strategy. Each integration is custom. Each requires dedicated engineering resources. Each takes months.
PSPs can't resource bespoke integrations for every software platform in every vertical. They have to pick the biggest platforms and hope the long tail doesn't matter.
It does.
3. Channels Beyond Checkout
Most PSP platform programmes focus on online checkout — because that's what PSPs built their APIs for. But payments increasingly happen through other channels:
Voice: Contact centres, IVR systems, AI voice agents
Payment links: SMS, email, WhatsApp
Chat: AI chat agents, live chat support
AI agents: Autonomous payment capture across voice and chat
A PSP that only offers a checkout API covers one channel. The platform needs all of them. The PSP can't help — and the platform either builds the other channels separately or finds infrastructure that covers them all.
The Three Distribution Models
Model 1: Direct Platform Partnerships
The PSP negotiates directly with each software platform. The platform builds a custom integration. The PSP's sales team manages the relationship.
Pros: Full control. The PSP owns the relationship and the economics.
Cons: Doesn't scale. Each platform integration is custom. Engineering resources are finite. Only works for the largest platforms. Smaller platforms — which collectively represent massive merchant volume — are unreachable.
Who does this: Every major PSP. Stripe Connect is the most mature version. Adyen for Platforms is the enterprise version.
Model 2: Marketplace and App Store Presence
The PSP publishes an app or integration on platform marketplaces — Twilio Marketplace, Shopify App Store, Salesforce AppExchange. Platforms discover the PSP through the marketplace and activate it.
Pros: Lower-touch distribution. The marketplace handles discovery. Integration can be standardised.
Cons: Limited depth. Marketplace integrations are typically lightweight. Complex payment flows (voice, multi-channel, merchant management) are hard to deliver through an app listing.
Who does this: Mid-tier PSPs and niche providers.
Model 3: Distribution Through a Payment Layer
The PSP connects to a payment layer that's already integrated into multiple software platforms. When a platform supports a merchant that requires the PSP, the payment layer routes transactions to that gateway — without the PSP needing a direct relationship with the platform.
Pros: Massive scale. A single connection to the payment layer puts the PSP inside every platform the layer serves. No bespoke integrations. No per-platform sales motion. The PSP is "distributable" into software it's never directly touched.
Cons: The PSP doesn't own the platform relationship. The payment layer is the intermediary. The PSP gets transaction volume, but the platform relationship sits with the payment layer.
Who does this: PSPs that recognise the distribution problem and want reach into the long tail of software platforms.
Why "Default Rails" Matter More Than Rates
Here's the uncomfortable truth for PSPs:
Merchants don't switch PSPs for better rates. They switch software.
When a dental practice moves from one practice management system to another, it inherits the new platform's payment processor. The practice didn't evaluate PSPs. It evaluated software.
When a BPO wins a new client, it processes that client's payments through whatever gateway the contact centre platform supports. The BPO didn't choose the PSP. The platform did.
This means the PSP's competitive advantage isn't rates, API design, or customer support. It's distribution — being the default rails inside the software the merchant already uses.
The PSPs that understand this are investing in platform distribution. The ones that don't are watching their merchant base erode one software adoption at a time.
What This Means for Platforms
If you're a software platform, the PSP distribution dynamic works in your favour:
You control distribution. PSPs need you more than you need them. You choose which gateways to support.
PSP-neutral infrastructure gives you leverage. If you support multiple gateways, no single PSP controls your payment stack. You can negotiate rates, switch providers, and respond to enterprise customer mandates.
You can monetise the position. Platforms that embed payments earn revenue share on every transaction. You've become a distribution channel — and distribution channels get paid.
PSPs will compete for your platform. When a PSP knows you can easily switch or add alternatives, they offer better rates, more support, and faster integration. Single-PSP platforms don't get this treatment.
The platforms that recognise their distribution power earliest gain the most leverage.
FAQ
Why don't PSPs just build their own platform integrations for every software company? Scale. There are thousands of vertical SaaS platforms, each with different requirements. A PSP can't build and maintain bespoke integrations for all of them. Even the largest PSPs (Stripe, Adyen) focus on the top 50-100 platforms and rely on self-serve tools for the rest.
What's in it for the PSP when they connect through a payment layer? Transaction volume. A PSP connected to a payment layer that serves 50 platforms gets access to merchants across all 50 platforms — without building 50 integrations. The payment layer handles the platform relationship, integration, and merchant onboarding. The PSP handles transaction processing.
Does this make PSPs commodities? Not yet. PSPs still differentiate on rates, geographic coverage, payment method support, risk management, and enterprise features. But the distribution advantage that traditionally differentiated PSPs (better sales team, better bank relationships) is being replaced by software embeddedness. PSPs that don't adapt will see their competitive advantage erode.
How does this affect PSP pricing? Platforms with multi-PSP infrastructure have structural negotiating leverage. If a PSP raises rates, the platform can route volume to an alternative. This creates downward pricing pressure — which is good for platforms and merchants, but a concern for PSPs dependent on pricing power.
Is Stripe worried about this? Stripe's strategy is to BE the platform (Stripe Connect, Stripe Treasury, Stripe Issuing — the full stack). They want vertical integration, not distribution through a neutral layer. This works for platforms willing to commit to Stripe exclusively. It doesn't work for platforms that need PSP flexibility — which is where the neutral payment layer fills the gap.
[CTA section]
Making PSPs distributable into software. Shuttle sits between platforms and PSPs — giving platforms multi-PSP flexibility and giving PSPs distribution into software they'd never reach directly. 40+ gateways, one integration, every channel.
[Partner With Us (PSPs)] | [See Platforms]