Stripe Connect is the default starting point for platforms embedding payments. The developer experience is excellent. The documentation is best-in-class. For most early-stage platforms, it is the right choice.
This is not a hit piece on Stripe. Stripe is very good at what it does — processing payments through its own acquiring network with a developer-first API.
But Stripe Connect is a product built to serve Stripe's business model: every transaction processed through Stripe's rails, every merchant onboarded to Stripe's ecosystem. That alignment works perfectly when your platform is small. It starts to break when your platform scales, your merchants diversify, and your payment requirements extend beyond what a single PSP can cover.
Here are five specific limitations that platforms consistently hit. Not theoretical concerns — real constraints that force architectural decisions.
1. The 46-Country Ceiling
Stripe operates in 46+ countries. For a US or European platform, that coverage feels comprehensive. For a platform with global ambitions, it is a hard boundary.
The problem. Stripe's coverage is concentrated in North America, Europe, and selected APAC markets. Significant commercial markets — including much of the Middle East, Africa, Southeast Asia, and Latin America — either have no Stripe presence or limited acquiring capability.
Even within supported countries, Stripe may not have local acquiring relationships. Processing a transaction in a Stripe-supported country through a foreign acquirer means higher interchange fees, lower authorisation rates, and a worse experience for the end customer.
Why it matters. If your platform serves merchants in 60 countries, you cannot route all of them through Stripe. You need local acquirers in markets Stripe does not cover — which means building separate integrations, managing multiple PSP relationships, and maintaining parallel payment infrastructure.
**What platforms do.** Some build bespoke integrations with regional PSPs alongside Stripe Connect. This works but creates maintenance overhead — two (or more) payment codepaths, two reconciliation systems, two sets of webhooks. Others move to a PSP-neutral architecture that handles multi-PSP routing through a single integration.
2. Complex, Unpredictable Pricing at Scale
Stripe's pricing is transparent at the headline level: 2.9% + 30p in the UK (1.5% + 20p for European cards). Below the surface, the cost structure is significantly more complex.
The problem. Connected account fees ($2/month per active account), payout fees, identity verification charges, Stripe Tax fees, dispute fees, Instant Payouts surcharges, and cross-border fees all add up. For a platform with thousands of connected accounts, the blended cost per transaction can be materially higher than the headline rate.
Pricing also changes. Stripe has historically adjusted fee structures with limited advance notice. For platforms that have built financial models around specific unit economics, a pricing change from a sole PSP is an existential risk — not just a cost increase.
Why it matters. Platforms that take a revenue share on payments (application fees in Stripe's model) earn the margin between what the merchant pays and what Stripe charges. As Stripe's blended cost rises, the platform's margin compresses. At scale, even a 0.2% increase across millions of transactions significantly affects profitability.
**What platforms do.** The typical response is to negotiate. Stripe offers custom pricing for high-volume platforms, but negotiating leverage is limited when Stripe is your only option. Platforms with multi-PSP capability can benchmark Stripe's rates against Adyen, Worldpay, or regional acquirers — and route volume to the most competitive provider for each transaction type and geography.
3. No PSP Flexibility
Stripe Connect routes every transaction through Stripe's acquiring network. There is no mechanism to process through a third-party PSP.
The problem. Enterprise merchants frequently mandate their own PSP. A hotel chain with a global Worldpay contract, an insurance company with an existing Adyen relationship, or a retailer with negotiated interchange rates through a specific acquirer — none of these can use their preferred provider through Stripe Connect.
For the platform, the answer to "can you process through our PSP?" is "no." That answer costs deals.
**Why it matters.** This is the most common trigger for platforms outgrowing Stripe Connect. Enterprise PSP mandates are not preferences — they are procurement requirements. A platform that cannot accommodate them is excluded from enterprise RFPs.
The constraint also limits strategic flexibility. If Stripe experiences an outage, your entire payment capability goes down. If a competitor PSP offers better authorisation rates for a specific card type or region, you cannot take advantage of it. Every transaction, regardless of context, routes through one provider.
What platforms do. Some build parallel integrations — Stripe Connect for most merchants, plus direct integrations with Adyen or Worldpay for enterprise accounts. This is expensive to maintain and fragments the merchant experience. Others adopt a payment layer that abstracts PSP routing, allowing the platform to add or remove gateways without touching their core integration.
4. Support Quality Degrades at Scale
Stripe's developer documentation and self-serve tooling are genuinely excellent. For a platform processing a few hundred transactions per month, the support experience is good.
The problem. At enterprise scale — thousands of connected accounts, complex payout structures, multi-currency settlement, high-risk merchant categories — support needs change. Issues become more nuanced. Response times matter more. And the support experience does not always scale with the platform.
Common pain points include:
Account reviews and holds. Stripe's automated risk systems can freeze connected accounts or hold funds with limited explanation. For a platform responsible for thousands of merchants, a single account freeze can trigger cascading support tickets.
Dispute handling. At volume, chargeback management becomes operationally complex. Stripe's dispute tools are functional but not designed for platforms managing disputes across thousands of sub-merchants.
Onboarding friction. Stripe's Know Your Customer (KYC) process is automated, which is fast for straightforward businesses. For merchants in complex or regulated industries — insurance, travel, financial services — the automated process can stall, and escalation paths are not always clear.
Custom requirements. Enterprise platforms often need bespoke settlement schedules, custom reporting, or specific compliance configurations. These requests require human support, and response times for custom work can extend to weeks.
Why it matters. For early-stage platforms, Stripe's self-serve model is a feature. For platforms processing significant volume with enterprise merchants, it becomes a constraint. The mismatch between the platform's support needs and Stripe's support model creates operational friction that compounds over time.
What platforms do. Some platforms assign internal engineering resource to manage Stripe-specific issues — effectively building an internal Stripe support team. Others negotiate dedicated account management as part of custom pricing agreements. Platforms that move to a multi-PSP architecture gain leverage: if one provider's support is inadequate, they can shift volume to another.
5. Proprietary Tokens Lock You In
When a customer saves a card through Stripe, Stripe creates a proprietary token. That token works with Stripe and only with Stripe.
The problem. If you decide to switch away from Stripe — or even add a second PSP alongside Stripe — those tokens cannot be used with the new provider. Every stored card becomes inaccessible.
For a platform with 50,000 stored payment methods, this means one of two things:
Ask every customer to re-enter their card details. Industry data suggests 20-40% will not complete this. That is 10,000-20,000 customers who may churn, fail to renew, or simply stop paying.
Run Stripe indefinitely for legacy cards while routing new transactions through a different provider. This means maintaining two integrations, two reconciliation processes, and two support relationships — permanently.
Neither option is acceptable. Both impose significant cost on the platform.
**Why it matters.** Proprietary tokens are the strongest form of payment provider lock-in. They turn a commercial relationship into a technical dependency. The longer you stay, the more tokens accumulate, and the harder it becomes to leave.
Stripe supports network tokenisation in some configurations, but network tokens are not the default, and not all card types or regions support them. The majority of Stripe Connect platforms are holding proprietary tokens.
**What platforms do.** The cleanest solution is to adopt portable tokens from the start — either network tokens or provider-agnostic tokens issued by a payment abstraction layer. For platforms already holding proprietary Stripe tokens, gradual migration through natural re-entry points (subscription renewals, checkout sessions) is the least disruptive path. The full playbook is covered in our payment provider migration guide.
What PSP-Neutral Architecture Actually Looks Like
The common thread across all five limitations is architectural: Stripe Connect is a single-PSP integration, and single-PSP architectures create single points of failure, single points of negotiation, and single points of lock-in.
The alternative is a PSP-neutral architecture — a single integration that connects to multiple PSPs and routes transactions based on geography, cost, merchant preference, or performance.
In practice, this means:
One API for your platform, regardless of which PSP processes the transaction
Multi-PSP routing — Stripe for US merchants, Adyen for Europe, a local acquirer for Southeast Asia
Portable tokens that work across providers, eliminating lock-in
Failover capability — if one PSP goes down, transactions route to another
Commercial leverage — you can benchmark and negotiate rates because switching cost is near zero
Shuttle provides this architecture out of the box. A single integration connects your platform to 40+ PSPs across voice, links, chat, and embedded checkout. Tokens are portable. Adding a gateway is configuration, not code. Platforms that use Shuttle do not face the five limitations above — because they are not locked into any single provider.
If you are hitting one or more of these constraints, the question is not whether to move away from Stripe Connect. It is whether to move to another single-PSP dependency, or to an architecture that makes the question irrelevant.