Switching payment processors without losing payments
To switch payment processors without downtime, map every payment flow on the current processor, migrate stored cards with their original transaction references, test the new integration, webhooks, and settlement files in parallel, move live traffic in stages, and keep the old account open for refunds and chargebacks on its transactions. The result is tested cutover and rollback evidence.
A processor switch with stored cards and a fixed end date
The trigger is a date. A processing contract ends, pricing is renegotiated with a second acquirer, a processor gives notice that it exits a market or a merchant category, or a platform adds local acquiring in the European Union next to its United States processor. The head of payments or the CTO owns the switch, and finance owns the month-end close that depends on it. The companies in this situation are subscription businesses, marketplaces, SaaS platforms with embedded payments, and payment facilitators in the acquiring segment.
The integration types differ on both sides: a gateway in front of a separate acquirer, a full-stack processor with its own card vault, a payment orchestration layer, or an independent token vault. Each move changes where cardholder data lives, which system issues tokens, and which party holds the record of each earlier transaction.
What breaks when the switch is not tested
- Renewals decline after cutover. Stored cards stay in the old processor's vault when the token export is late or partial, or when old tokens are not mapped to new ones. Recurring charges fail on the first billing run, and each failed renewal is revenue that dunning has to recover.
- Merchant-initiated charges lose their link. A Visa US-region document states that a merchant-initiated transaction should provide a link to the cardholder's original interaction (Visa Merchant-Initiated Transaction Service overview, 2022). In the European Economic Area, card payments are initiated by the payer by default. The European Commission's answer in the EBA Q&A tool (Q&A 2018_4031, final answer 1 March 2019) treats them as payee-initiated, and outside strong customer authentication, only when the payer gave a mandate through a particular payment instrument, the mandate is based on an agreement between payer and payee for products or services, and no specific payer action triggers each transaction. Setting up that mandate through a remote channel is subject to strong customer authentication. A migration that drops the original transaction reference sends renewals that the issuer cannot tie to an authenticated mandate, and a customer who is not in session cannot complete an authentication challenge.
- Cancelled subscriptions start billing again. A cancellation recorded only in the old processor's subscription objects is lost in the export. Visa guidelines state that after a cancellation request the merchant is prohibited from billing the Visa account, and under dispute condition 13.2, Cancelled Recurring Transaction, a merchant that has not issued a credit should accept the dispute; for disputes processed on or after 19 October 2024, the merchant can instead provide proof that the cardholder used services after withdrawing permission and before the dispute processing date (Dispute Management Guidelines for Visa Merchants, June 2024).
- Disputes on old transactions go unanswered. The issuer sends a dispute to the acquirer that processed the original transaction. When the old account is closed or its portal access is removed at cutover, nobody receives the dispute, and the same Visa guidelines note that a response outside the specified time may lead to an unfavourable outcome.
- The same order is charged twice. During dual running, a timeout on one processor triggers a retry on the other. Idempotency keys are scoped to one processor, so neither side rejects the duplicate.
- Settlement stops reconciling. The new processor names webhook events differently, groups payouts by another cut-off, and nets fees where the old one charged them gross. Ledger entries stop matching payouts at month-end close.
The migration testing sequence
- Map every flow on the current processor. Cover payment methods, authorisation, capture, refund, 3-D Secure, stored credential types, webhooks, and reports. Output: a payment flow map with every state, transition, and failure path.
- Map the old processor to the new one. Compare status models, decline codes, webhook events, settlement report fields, fee netting, and payout timing. Output: a field and event mapping table with each gap and its owner.
- Test the new integration in its sandbox. Output: a test suite for authorisation, capture, void, refund, partial refund, and reversal, plus an idempotency and duplicate-request test report that covers retries across both processors.
- Rehearse the stored card migration. Run a test import of a synthetic export file and check token map completeness, expiry dates, original transaction references, and excluded cancelled subscriptions. Output: card token and mandate migration checks.
- Reconcile the new settlement files. Match sandbox and pilot payouts to ledger entries, including fees and refunds. Output: settlement file and payout reconciliation checks.
- Run both processors in parallel. Route a small share of new customer-initiated payments to the new processor behind a routing flag and compare results daily. Output: a daily comparison log of declines, webhooks, and settlement breaks.
- Rehearse cutover and rollback. Move recurring billing cohort by cohort, and switch the routing flag back once under test. Output: cutover and rollback rehearsal results.
- Verify the first billing cycle. Compare expected and actual charges per subscription after each cohort moves. Output: a balance and transaction history comparison report.
- Keep the old processor for its tail. Route refunds to the processor of the original sale and test dispute intake on both accounts. Output: a dispute lifecycle test suite per card network that includes old-processor transactions.
- Record every defect with its money impact. Output: a defect log with financial impact per defect and retest status.
Timeline and scope
Durations are typical engineering estimates for one platform moving card processing to one new processor, not company statistics. The new processor's underwriting and the old processor's export time come on top.
| Phase | Duration (estimate) | Roles | Output |
|---|---|---|---|
| Flow map and processor mapping | 1-2 weeks | QA lead, payments engineer | Payment flow map with every state, transition, and failure path; field and event mapping table |
| Integration tests in sandbox | 2-4 weeks | QA engineers, automation engineer | Test suite for authorisation, capture, void, refund, partial refund, and reversal; Idempotency and duplicate-request test report |
| Stored card migration rehearsal | 2-4 weeks, in parallel | QA engineer, both processors' migration teams | Card token and mandate migration checks |
| Parallel run | 2-4 weeks | QA engineer, finance operations | Daily comparison log; Settlement file and payout reconciliation checks |
| Staged cutover and rollback | 1-2 weeks | QA lead, payments engineer, support lead | Cutover and rollback rehearsal results |
| Old-processor tail | Until disputes on its last transactions close | Finance operations, QA engineer | Dispute lifecycle test suite per card network |
Each payment method, currency, and region adds decline codes, report formats, and authentication rules to the scope. A move that also changes the card vault adds a second token map. Payments in the European Economic Area add strong customer authentication checks under PSD2 for every remote flow that sets up a new mandate.
How we help with a processor switch
We test the migration and the new integration; the two processors run the card data export and import, and the platform decides when to cut over. Card numbers move only between the two processors' vaults under their PCI DSS controls, and our tests use synthetic cards and tokens, so production card numbers never enter our test environments.
- Payment flow testing covers steps 1, 3, 5, and 10: the payment flow map with every state, transition, and failure path, the test suite for authorisation, capture, void, refund, partial refund, and reversal, the idempotency and duplicate-request test report, settlement file and payout reconciliation checks, and the defect log with financial impact per defect.
- Data migration testing covers steps 4, 7, and 8: the migration reconciliation test plan, card token and mandate migration checks, the balance and transaction history comparison report, and cutover and rollback rehearsal results.
- Subscription billing testing covers renewals and cancellations for each cohort that moves, with a dunning and retry schedule test report.
- Chargeback and dispute testing covers step 9 with the dispute lifecycle test suite per card network and deadline and reason code rule checks.
- API and webhook testing covers the new event model with webhook signature, ordering, and replay checks.
You also receive the field and event mapping table from step 2 and the daily comparison log from step 6 as part of the engagement.
Related
Services
Guides
- How to test payment idempotency
- How to simulate chargebacks for disputes testing
- How to test dunning: failed payment retries, decline codes, and subscription states
- How to test 3DS2 challenge flows with 3DS test cards
- How to test ledger reconciliation against settlement files and bank statements
- How to use test card numbers in payment testing
Questions
What is token migration?
How long does it take to switch payment processors?
Scope testing for your processor switch
Send the current and target integration types, your stored card and subscription volumes by type, and your target cutover date, and we return a cutover test plan that names the output of every migration step.