How Do You Switch Payment Providers?
Plan three to six months end to end, and follow six steps: audit your current integration, decide whether to move to another single PSP or to a PSP-neutral layer, request a PCI-compliant vault-to-vault transfer of your stored cards, run both providers in parallel for at least one full billing cycle, cut over, then monitor for 30 days.
A silent card transfer is often available and easy to miss. Major processors can export your stored card data directly to another PCI DSS Level 1 provider. Ask whether yours will, before you plan any customer re-entry campaign.
Two things cause most of the damage. Stored cards that cannot be moved, and webhooks that silently stop firing. Plan for both before you write any migration code.
The safest migrations never have a cutover date at all. You run old and new side by side and let the old provider drain naturally.
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 as a single headline rate 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. If you are still deciding how many providers to run rather than which one to move to, see single global PSP vs multiple local acquirers.
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. A meaningful share of customers never complete re-entry, and every card that does not come across is a subscription that quietly stops billing. Treat this as a revenue event, not a migration task.
Some PSPs support network tokens, issued by Visa or Mastercard rather than the gateway. These can survive a provider change, but only when the Token Requestor ID they sit under belongs to you rather than to your PSP. Most PSPs register that ID themselves, which quietly keeps the tokens on their side. Adoption is also 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. Teams routinely find it is far larger than expected, because payment logic spreads well beyond the checkout code into billing, reporting, and support tooling.
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. Sooner or later your new PSP raises prices or your merchants demand a different gateway, and 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 turns the next provider change from a project into a configuration change. The more volume you process, and the more gateways your merchants ask for, the faster that upfront cost pays back.
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
Plan for 30 to 90 days of dual running, driven by 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, since 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, and it is easy to start in the wrong place. Work through these options in order:
PCI-compliant vault-to-vault migration. This is the standard route, and the one teams most often overlook. Major processors can export your stored card data directly to another PCI DSS Level 1 provider, encrypted, with no customer involvement at all. Stripe documents both importing from and exporting to another processor. Adyen documents an equivalent export process, which requires the receiving provider to supply an attestation of compliance and a publicly listed PGP key. Expect to sign a data transfer agreement, evidence your new provider's PCI DSS Level 1 status, and exchange encryption keys. The gating factor is usually whether your current provider will co-operate and how quickly, so ask at the start of the project rather than the end.
Network tokenisation. Where a card is provisioned as a Visa or Mastercard network token, that token can survive a provider change, but only if the Token Requestor ID it sits under belongs to you rather than to your PSP. Most PSPs register the TRID themselves, which leaves the tokens inside that provider's umbrella. Find out who owns yours before assuming portability.
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. Completion rates on these campaigns are low. Follow up with SMS or in-app prompts for non-responders, and expect to carry a tail of customers who never update at all.
The key principle: exhaust the silent options first, because bulk re-entry campaigns cost you customers.
Be precise about what a card export actually covers. It moves stored card credentials. It does not move PayPal billing agreements, wallet or device tokens from Apple Pay and Google Pay, SEPA or Bacs direct debit mandates, or network token provisioning. If your subscriptions sit on those rails, each one needs its own migration path, so inventory them during the audit rather than discovering them at cutover.
One clarification, because this trips teams up. Account updater services (Visa Account Updater, Mastercard Automatic Billing Updater) are not a migration tool. They refresh credentials a provider already holds when a card is reissued or expires, so the new provider must already have the card on file for them to return anything. Enable them on the new provider once migration is complete, as ongoing credential hygiene.
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 available for at least 120 days, since chargebacks routinely arrive that late, and considerably longer if you sell future-dated goods or services)
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.
Make token portability a concrete requirement. If you are choosing a new provider or abstraction layer, do not accept "we support network tokens" as an answer. Ask who the Token Requestor ID is registered to, and get it in writing. Tokens registered under your provider's TRID are migration debt dressed up as portability.
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, including confirmation emails, fulfilment triggers, and 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 with a single API, a single webhook format, and a single settlement report, and that 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 is a migration in the sense this guide describes. You are configuring and testing a new provider rather than re-integrating your platform.
Shuttle connects to a wide range of gateways and payment services through a single integration, listed in the payment providers directory. It tokenises with the gateway rather than holding card data itself, so card portability still depends on network tokenisation and on what your providers support. Shuttle does not make a first migration free.
What it changes is the cost of every migration after that. Adding or removing a gateway becomes a configuration change in Shuttle instead of a re-integration in your codebase. There is still work involved: credentials, onboarding, testing, and checking payment method coverage in each market. But it is configuration and testing rather than a rebuild.
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 the next one is a configuration change?"
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)
[ ] Request a PCI-compliant vault-to-vault card transfer from your current provider (start early, it gates everything else)
[ ] Establish who your Token Requestor ID is registered to, then migrate any portable network tokens
[ ] Map the credentials a card export will not cover (wallet tokens, device tokens, direct debit mandates)
[ ] 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
[ ] Enable account updater on the new provider (credential hygiene after migration, not a migration step)
[ ] Monitor post-migration for 30 days
[ ] Decommission old integration only after the dispute window closes (120 days minimum, longer for future-dated goods)
Switching Payment Providers FAQ
How do I switch card payment provider without losing my existing setup?
Run both providers in parallel rather than cutting over. Send new transactions to the new provider while existing subscriptions, refunds, and disputes continue on the old one. Your existing setup stays intact throughout. Stop sending it new traffic once the new path has run clean for a full billing cycle, then keep it available until the dispute window closes before you decommission anything.
How do I switch payment provider without disrupting customers?
Migrate stored cards before they are needed, never at the moment of checkout. Ask your current processor for a PCI-compliant vault-to-vault export, which moves saved cards to the new provider without customers touching anything, then collect any remainder at natural touchpoints such as a renewal or a settings update. Customers should never see a re-entry prompt caused by your migration.
What is a safe migration plan to avoid downtime and protect saved cards and subscriptions?
The safe plan has no cutover moment. Audit your integration surface first, stand up the new provider alongside the old, and let subscriptions drain naturally across their billing cycles rather than forcing them across. Monitor authorisation rates, settlement timing, and webhook delivery on both paths in parallel, and only decommission the old integration once the dispute window has closed. Chargebacks commonly arrive up to 120 days after a transaction, and considerably later on future-dated goods and services.
Will I lose my saved cards when I switch payment providers?
Often not, though it depends on your current provider. Stripe and Adyen both document a PCI-compliant vault-to-vault transfer that exports saved cards directly to a new provider with no customer involvement, and many other processors have an equivalent process, though it is not universal. Whether yours will co-operate, and how quickly, is the thing to establish first. Network tokens can also survive a move, but only where the Token Requestor ID belongs to you rather than to your PSP. Confirm both routes with your current provider before you commit to a migration date.
Can I run two payment providers at the same time?
Yes, and for a migration you should. Plan a dual-run period of 30 to 90 days, because that overlap is what removes downtime risk. Running two providers permanently is also viable, and is how platforms honour enterprise gateway mandates or route by region and cost.
How long does it take to switch payment providers?
Plan three to six months end to end. The parallel-running window is 30 to 90 days, driven by your longest subscription billing cycle rather than by engineering time, and the integration work itself is usually shorter than that drain period. Add time at the front for the audit and for negotiating a card export with your current provider, and keep the old integration available for at least 120 days after cutover to handle late refunds and chargebacks.
How do I switch payment providers without disrupting client billing?
Let each client's billing cycle complete on the old provider before moving them. Migrate in cohorts rather than all at once, so a configuration problem affects a handful of clients instead of your whole book. Tell your clients the migration is happening. Their own customers should not need to know.
What is a realistic plan for replacing in-store terminals across many sites?
Stage it by location, not by date. Install and certify the new terminals at one site, run both old and new for a full trading week, then roll out in waves once the reconciliation matches. Terminal estates add hardware logistics and staff retraining on top of the software migration, so treat those as their own workstream.
How do I switch merchant account providers?
The mechanics mirror a gateway migration, with two additions. Underwriting on the new merchant account takes time, so start the application before you plan any technical work. Watch settlement carefully in the first month, because payout timing and reserve terms often differ from your previous agreement even when the processing rate looks similar.
How do I avoid going through this again?
Integrate with a PSP-neutral layer rather than directly with one provider. When your platform talks to a single API that handles the provider-specific translation underneath, changing gateway becomes a matter of configuration and testing rather than a re-integration. That does not remove the first migration, and there is still real work in credentials, onboarding and verifying payment method coverage. But the next change is configuration rather than a rebuild.