You signed up with a payment provider because they were easy to integrate, competitively priced, and ticked the right boxes. Two years later, they've raised fees twice, their support has deteriorated, and you're stuck — because migrating means losing stored payment tokens, rewriting your integration, and asking every customer to re-enter their card details.
This is payment provider lock-in, and it's one of the most common — and costly — mistakes platforms make when building their payment infrastructure.
What Creates Lock-In
Lock-in doesn't happen on day one. It builds gradually, through a combination of technical dependencies, commercial terms, and data ownership structures that make leaving progressively more painful.
Proprietary Payment Tokens
When a customer saves their card with your platform, your payment provider stores the actual card number and gives you a token — a reference ID you can use for future charges. The problem: these tokens only work with the provider that issued them.
Stripe tokens don't work with Adyen. Adyen tokens don't work with Worldpay. If you switch providers, every stored card becomes useless. Your customers must re-enter their payment details, which means:
Subscription businesses lose subscribers — failed rebills from expired tokens create involuntary churn
Marketplaces lose repeat buyers — friction at checkout drives customers to competitors
Platforms lose merchant trust — asking merchants to re-onboard their payment setup damages the relationship
For a platform with 10,000 stored cards, even a 5% customer loss during migration represents hundreds of lost relationships.
API Dependencies
Every payment provider has a different API. The deeper your integration, the harder it is to leave:
Webhooks and event handling — your entire order management, fulfilment, and accounting pipeline is wired to provider-specific event formats
Payout logic — split payments, marketplace disbursements, and platform fees are built around your provider's payout APIs
Fraud rules and risk scoring — custom fraud rules configured in your provider's dashboard don't transfer
Reporting and reconciliation — your finance team's workflows depend on provider-specific reporting formats
A platform that spent six months integrating Stripe Connect's split payment logic faces another six months rebuilding that logic on a different provider. That's engineering time that could be spent on product features.
Contract Terms and Exit Fees
Some providers lock you in commercially as well as technically:
Volume commitments — minimum processing volumes with penalties for falling short
Multi-year contracts — especially common with traditional acquirers and enterprise payment platforms
Exit fees — charges for early termination or data export
Data portability fees — some providers charge to export your transaction history and customer data
Even providers without explicit contracts create effective lock-in through the sheer cost and complexity of migration.
Institutional Knowledge Dependency
Over time, your engineering team builds deep expertise in your provider's API, quirks, and workarounds. That institutional knowledge has real value — and it's lost when you switch. The new provider has different edge cases, different error codes, different behaviour under load.
The Real Cost of Lock-In
You Can't Negotiate
The most immediate cost: you lose leverage. When your provider knows you can't easily leave, they have no incentive to compete on price, support quality, or feature delivery.
A platform processing GBP 5M annually that's locked into 2.9% + 20p can't credibly threaten to move to a provider offering 2.4% + 15p. The switching cost — token migration, engineering time, customer disruption — exceeds years of savings from the lower rate.
Your provider knows this. Their commercial team knows this. Your rate increases will reflect it.
Forced to Accept Fee Increases
Payment providers regularly adjust their pricing. Sometimes it's driven by card network fee changes (interchange increases, scheme fee adjustments). Sometimes it's driven by the provider's own margin targets.
When you're locked in, you absorb these increases because the alternative — migration — costs more than the price hike. Over time, small increases compound. A platform that started at 2.4% and accepted three annual 0.1% increases is now paying 2.7% — an effective 12.5% increase in payment costs.
Token Migration Means Customer Churn
If you do decide to switch, token migration is the hardest part. Options include:
Network tokenisation — Visa and Mastercard offer account updater services that can map old tokens to new ones, but coverage is imperfect and the process takes months
Customer re-entry — asking customers to re-enter their card details, which always results in some percentage abandoning the process
Parallel processing — running both old and new providers simultaneously during a transition period, doubling your compliance and operational overhead
None of these are clean. All of them carry real risk of lost customers and revenue.
Innovation Stalls
Lock-in doesn't just affect your costs — it limits your options. Want to add local payment methods in a new market? Your provider might not support them. Want to optimise routing for lower decline rates? You're limited to your provider's acquiring relationships. Want to offer merchants a choice of processors? Your architecture doesn't allow it.
Every feature decision is constrained by what your single provider can do.
How to Avoid Lock-In
Build PSP-Neutral From the Start
The most effective prevention is architectural. Instead of integrating directly with a single payment provider, build (or adopt) an abstraction layer that sits between your platform and the providers.
A PSP-neutral architecture means:
One integration to a payment layer, which connects to multiple providers behind the scenes
Provider-agnostic tokens that work across any gateway
Routing flexibility — send transactions to different providers based on cost, geography, success rates, or merchant preference
Swap providers without code changes — adding or removing a PSP is a configuration change, not an engineering project
This is the approach that enterprise platforms use by default. They've learned — often the hard way — that single-provider dependency is an unacceptable business risk.
Insist on Portable Tokens
If you're evaluating payment providers, ask explicitly:
"Can I export my stored payment tokens if I leave?"
"Do my tokens work with other processors?"
"Do you support network tokenisation?"
If the answer is no, you're building lock-in from day one. Portable tokens — where the token is managed independently of any single provider — are the single most important technical feature for avoiding lock-in.
Negotiate Data Portability Upfront
Before signing with any provider, negotiate data portability terms into your agreement:
Transaction history export — full history in a standard format (CSV, API access)
Customer payment data — the ability to migrate stored payment methods
No exit fees — explicit terms that you can leave without penalty
Reasonable notice periods — 30 days, not 6 months
These terms are much easier to negotiate before you sign than after you've been processing for two years.
Maintain Multi-PSP Capability
Even if you primarily use one provider, maintain the ability to route through others:
Keep at least one backup PSP configured and tested
Run a small percentage of transactions through the backup to keep the integration live
Monitor both providers' performance so you have data to support switching decisions
This isn't over-engineering — it's the payment equivalent of having a disaster recovery plan.
How to Escape Existing Lock-In
If you're already locked in, migration is possible — it just requires planning.
Phase 1: Assess Your Exposure
Map out exactly what's locked:
How many stored payment tokens do you have?
What percentage of revenue comes from returning customers using stored cards?
How deeply integrated are your systems with provider-specific APIs?
What contractual terms apply to leaving?
Phase 2: Run Parallel Providers
Don't attempt a hard cutover. Run your new provider alongside your existing one:
Route new customers to the new provider
Continue serving existing customers through the old provider
Gradually migrate stored cards using network tokenisation or customer re-entry during natural touchpoints (subscription renewals, account updates)
Phase 3: Migrate Deliberately
Set a timeline — typically 6-12 months — to complete migration. Track:
Percentage of transactions on new vs old provider
Token migration success rate
Customer churn attributable to the migration
Cost savings realised
How Shuttle Eliminates Lock-In
Shuttle's payment infrastructure is built specifically to prevent the lock-in problem:
40+ PSPs connected through a single integration — add or remove providers without changing your code
Provider-agnostic tokens — your stored payment data works across any gateway in Shuttle's network, so you never lose customer cards when changing providers
No contracts — month-to-month, usage-based pricing with no volume commitments or exit fees
Swap providers instantly — routing changes are configuration, not code. Move from Stripe to Adyen to Worldpay without touching your integration
PCI DSS Level 1 — Shuttle handles the compliance burden regardless of which providers you use
The result: you get the best rates, the best features, and the best support from every provider — because every provider knows you can leave at any time.
That's not just a technical advantage. It's negotiating leverage.
Key Takeaways
Lock-in is a design choice, not an inevitability. Platforms that build PSP-neutral architecture from the start avoid the cost, risk, and frustration of single-provider dependency. Those already locked in can escape with careful planning and parallel migration.
The fundamental question is simple: does your payment architecture give you options, or does it give your provider power over you?
Related reading: