Why Platforms Switch Payment Providers
Nobody switches payment provider for fun. It is one of the highest-risk infrastructure changes a platform can make. The fact that you are reading this means something has already gone wrong with your current setup.
The triggers are well documented. They tend to follow a pattern:
Account issues. Your PSP freezes funds, applies rolling reserves without warning, or terminates merchants with little explanation. For platforms processing on behalf of sub-merchants, a single compliance flag can cascade across your entire portfolio.
Fee pressure. What started at 2.9% + 30p per transaction now includes platform fees, payout fees, dispute fees, and monthly minimums. At scale, the blended rate is materially higher than what competitors quote — and your margin is being squeezed from underneath.
Lock-in. Your payment tokens are proprietary. Your merchant data sits behind an API you do not control. Switching means re-collecting card details from every customer, which means friction, drop-off, and lost revenue.
**Missing features.** You need voice payments, pay-by-bank, multi-currency settlement, or white-label merchant portals. Your current provider does not offer them — or offers them only through their own branded experience.
**International expansion.** Your platform is growing into markets where your current PSP either has no licence, poor acquiring rates, or limited local payment method coverage. A single-PSP architecture cannot solve this without bolting on separate integrations per region.
Any one of these is manageable. Two or three together, and the cost of staying exceeds the cost of switching.
The Migration Challenge
Switching payment providers is not the same as switching any other SaaS tool. Payments touch revenue directly. A botched migration does not cause inconvenience — it causes lost sales, failed renewals, and customer churn.
Here is what makes it difficult:
Token Portability
Most PSPs issue proprietary tokens when a customer saves a card. Those tokens only work with the PSP that issued them. If you switch from Stripe to Adyen, every Stripe token becomes useless. Your customers must re-enter their card details.
For a platform with 10,000 stored cards, that means 10,000 potential points of failure. Industry data suggests 20-40% of customers will not complete re-entry. That is not a migration risk — it is a revenue event.
Some PSPs support network tokens (issued by Visa/Mastercard rather than the gateway), which are portable across providers. But adoption is inconsistent, and not all card types or regions support them yet.
API Differences
No two PSPs have the same API. Field names differ. Webhook structures differ. Error codes differ. Settlement reporting differs. A migration is not a find-and-replace — it is a re-integration.
If your platform has built business logic around your current PSP's API quirks (and it has), that logic needs auditing and rewriting.
Customer Impact
The worst migrations are the ones customers notice. Failed subscription renewals, broken checkout flows, payment confirmation emails that stop arriving. Each of these erodes trust that took years to build.
Downtime Risk
Payment systems do not have maintenance windows. Your merchants expect to process transactions 24/7. Any gap — even minutes — means lost revenue and support tickets.
Step-by-Step Migration Plan
Step 1: Audit Your Current Setup
Before writing a single line of migration code, document what you actually use today:
Transaction types — one-off payments, subscriptions, pre-authorisations, refunds, partial captures
Stored credentials — how many customers have saved cards, and what token format they use
Webhooks — every webhook you consume and what business logic it triggers
Settlement — how funds flow, what reporting you depend on, and how reconciliation works
**Compliance** — your PCI scope, who handles cardholder data, and what SAQ level you hold
Multi-currency — which currencies you process, settlement currencies, and FX handling
Disputes — your chargeback workflow, evidence submission process, and win rates
This audit reveals your actual integration surface. Most teams underestimate it by 40-60%.
Step 2: Choose a PSP-Neutral Architecture
This is the single most important decision in your migration. You have two options:
**Option A: Migrate from one PSP to another PSP.** You solve today's problem but create the same lock-in with a different provider. In 18-24 months, when your new PSP raises prices or your merchants demand a different gateway, you will be back here reading this guide again.
Option B: Migrate to a PSP-neutral architecture. You integrate once with an abstraction layer that connects to multiple PSPs. Adding or removing a gateway becomes a configuration change, not a re-integration.
Option B costs more upfront but eliminates future migration risk entirely. For platforms processing above £1M/year, the economics favour Option B within 12 months.
A PSP-neutral approach means your platform can:
Route transactions to different PSPs based on region, cost, or merchant preference
Honour enterprise PSP mandates without custom integrations
Fail over to a backup PSP if your primary goes down
Negotiate rates with multiple providers simultaneously
Step 3: Run Parallel Processing
Never do a hard cutover. Instead, run your old and new payment paths simultaneously:
New transactions go through the new provider (or abstraction layer)
Existing subscriptions continue on the old provider temporarily
Refunds and disputes for old transactions still route through the old provider
This dual-run period typically lasts 30-90 days, depending on your subscription billing cycles. The goal is to drain the old provider of active obligations naturally rather than forcing a switchover.
During parallel processing, monitor:
Authorisation rates (compare old vs new — a drop signals configuration issues)
Settlement timing (ensure funds arrive on schedule)
Webhook reliability (confirm all events fire and are processed)
Error rates by card type, region, and currency
Step 4: Migrate Tokens and Stored Cards
This is the hardest part. Your options depend on your current and target providers:
Network tokenisation. If both providers support Visa/Mastercard network tokens, you can migrate stored credentials without customer re-entry. The network token is provider-agnostic. This is the cleanest path but requires both sides to support it.
Account updater services. Card networks run account updater programmes that can refresh card details when a merchant switches acquirers. Coverage varies by card brand and region.
Gradual re-collection. For cards that cannot be migrated programmatically, trigger re-entry at the next natural interaction point — a subscription renewal, a checkout session, or a payment settings update. Frame it as a security upgrade, not a system change.
Bulk re-entry campaigns. As a last resort, email customers asking them to update their payment method. Expect 30-50% completion rates. Follow up with SMS or in-app prompts for non-responders.
The key principle: migrate as many cards as possible silently (network tokens, account updater), and handle the remainder through natural touchpoints before resorting to bulk campaigns.
Step 5: Cut Over
Once parallel processing has run for a full billing cycle and your monitoring confirms parity:
Stop sending new transactions to the old provider
Process final settlements and reconcile
Migrate any remaining active subscriptions
Update webhook endpoints
Decommission the old integration (but keep it in your codebase for 90 days — you will need it for late refunds and disputes)
Step 6: Monitor Post-Migration
The first 30 days after cutover are critical. Watch for:
Authorisation rate changes — even a 1% drop at scale means significant lost revenue
Failed recurring payments — subscriptions that silently stopped processing
Reconciliation gaps — transactions that processed but did not settle correctly
Customer complaints — support ticket volume related to payment failures
Set up automated alerts for any of these metrics moving outside normal ranges.
How to Do It Without Customer Impact
The ideal migration is one your customers never notice. Here is how to achieve that:
Use a dual-run period. As described above, run old and new providers in parallel. Customers continue transacting normally while you migrate the infrastructure underneath.
Prioritise portable tokens. If you are choosing a new provider (or abstraction layer), make token portability a non-negotiable requirement. Proprietary tokens created today become migration debt tomorrow.
Never force card re-entry during checkout. If a customer arrives at checkout and their stored card does not work because of your migration, you have failed. Migrate tokens before they are needed, not when they are needed.
Maintain webhook continuity. Your post-payment workflows — confirmation emails, fulfilment triggers, accounting updates — must continue firing without interruption. Test this in staging with production-like data before going live.
Communicate proactively with merchants, not end customers. Your merchants (if you are a platform) need to know the migration is happening. Their customers should not.
Why PSP-Neutral Architecture Prevents Future Migrations
The reason most platforms end up in a painful migration is architectural: they integrated directly with a single PSP, and now they are coupled to it.
A PSP-neutral approach breaks that coupling. Your platform integrates with an abstraction layer — a single API, a single webhook format, a single settlement report — and the abstraction layer handles the PSP-specific translation underneath.
When you need to add Adyen for European merchants, you configure it. When an enterprise customer mandates Worldpay, you enable it. When Stripe raises prices, you route volume elsewhere. None of these require a migration. None of them touch your codebase.
Shuttle connects to 40+ PSPs through a single integration. Tokens are portable across providers. Adding or removing a gateway is a configuration change, not a project. Platforms that use Shuttle never need to do a full payment migration again — they just adjust routing.
If your platform is about to outgrow Stripe Connect or any other single-PSP setup, the question is not "which PSP should we migrate to?" It is "how do we make sure we never have to migrate again?"
Migration Checklist
Use this as a reference when planning your migration:
[ ] Complete integration audit (transaction types, tokens, webhooks, settlement, compliance)
[ ] Decide: migrate to a new single PSP or adopt PSP-neutral architecture
[ ] Set up parallel processing environment
[ ] Establish monitoring dashboards (auth rates, settlement, errors)
[ ] Migrate network tokens and portable credentials
[ ] Run account updater for remaining stored cards
[ ] Execute dual-run period (minimum one full billing cycle)
[ ] Migrate active subscriptions
[ ] Cut over new transactions to new provider
[ ] Run gradual re-collection for unmigrated cards
[ ] Monitor post-migration for 30 days
[ ] Decommission old integration after 90 days