Never switch by turning one off first
The mistake that causes lost sales is treating a switch as a hard cutover: cancel the old account, activate the new one, and hope the seam is invisible. It rarely is. The safe approach is to bring the new provider live alongside the old one, verify it thoroughly, and only then shift traffic — keeping the old path available until you are certain.
Running both in parallel briefly is not wasted effort; it is the redundancy that guarantees checkout never goes dark during the transition. It also doubles as a template for permanent redundancy, which every high-risk merchant should have anyway.
Plan the migration before you touch anything
A smooth switch is mostly planning. Map everything the current provider touches so nothing is forgotten when you move.
- Every place a payment is taken: website checkout, invoices, phone, in-person.
- All recurring subscriptions and their billing dates.
- Stored (tokenized) cards that need to move to the new provider.
- Reporting, reconciliation, and any accounting integrations tied to the old provider.
- Your descriptor, so customers see a consistent name across the switch.
Migrating stored cards and subscriptions
The most sensitive part of a switch is moving card-on-file data and active subscriptions without forcing customers to re-enter anything. Tokenized card data can often be migrated between providers through a secure process so subscriptions continue billing uninterrupted. Coordinate this carefully — a botched card migration is the one thing that genuinely does lose subscribers.
Where a direct token migration is not possible, plan a graceful transition: bill existing subscriptions on the old path while new sign-ups go to the new one, and migrate the rest as cards naturally update. Communicate nothing to customers that would alarm them; a good migration is silent.
Test in parallel, then shift traffic gradually
With the new provider live, run real test transactions across every payment path and confirm settlement, refunds, and reporting all behave. Then shift traffic gradually rather than all at once — a portion of transactions first, watching approval rates and settlement, before moving the rest. Gradual cutover means any surprise affects a fraction of sales, not all of them.
Keep the old path as redundancy
Once the new provider is fully live and proven, you do not have to discard the old one immediately. Keeping a second path available is exactly the redundancy that protects a high-risk merchant from ever going dark. Many merchants discover that the migration they feared becomes the moment they finally build the resilience they always needed.
Key takeaways
- Switch in parallel — never cancel the old provider before the new one is proven.
- Map every payment path, subscription, and stored card before you begin.
- Migrate tokenized cards and subscriptions carefully; a botched card move is what loses subscribers.
- Run real test transactions and shift traffic gradually while watching approvals and settlement.
- Keep the old path as permanent redundancy so you never go dark.
Frequently asked questions
Will switching processors cause downtime or lost sales?
Not if you switch in parallel. Bring the new provider live alongside the old one, test thoroughly, and shift traffic gradually so checkout never goes dark and customers never notice.
Can I move my stored cards and subscriptions to a new provider?
Often yes. Tokenized card data can frequently be migrated through a secure process so subscriptions keep billing without customers re-entering anything. Where that isn't possible, a graceful phased transition keeps billing uninterrupted.
Should I cancel my old processor right away?
No. Keeping the old path available after the new one is live gives you redundancy that protects against outages. Only close it once you're fully confident, and consider keeping a second path permanently.