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:
Card data export: many providers will export stored card data to another PCI-compliant provider on request, but it takes planning, some charge for it, and both sides have to support the transfer
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 choice: put each merchant, or each payment method, on the provider that suits it
Swap providers without code changes: adding or removing a PSP is a configuration change, not an engineering project, though saved cards stay with the provider that stored them
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.
Plan for Card Data Portability
If you're evaluating payment providers, ask explicitly:
"Will you export my stored card data to another provider if I leave?"
"Do my tokens work with other processors?"
"Do you support network tokenisation?"
If the answer to the first question is no, you are building lock-in from day one. Being able to move stored card data to a new provider is one of the most important terms to agree before you sign.
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
Keep one payment method or one merchant on the backup so the connection stays tested
Monitor both providers' performance so you have data to support switching decisions
This isn't over-engineering: it is the payment equivalent of a disaster recovery plan. Plan for one limit: saved cards stay with the provider that stored them, so a backup can take new payments but cannot charge cards saved with your main provider.
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 through a card data export between providers, or customer re-entry during natural touchpoints (subscription renewals, account updates)
Phase 3: Migrate Deliberately
Set a timeline 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 Reduces Lock-In
Shuttle's payment infrastructure is built to remove the integration side of lock-in:
40+ PSPs connected through a single integration: add or remove providers without changing your code
Change providers without re-integrating: moving a payment type from Stripe to Adyen or Worldpay is a configuration change, not code. Saved cards stay with the provider that stored them, so those customers re-enter their card or stay on the original provider
PCI DSS Level 1: card data is captured in Shuttle's certified environment, which limits your PCI scope whichever providers you use
The result: your integration no longer ties you to one provider, which strengthens your position on rates, features and support. Stored cards are the part that still needs planning, and the steps above cover them.
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 reduce 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: