How to Switch PSP Without Losing Revenue: Migration Playbook

Switching payment processors is one of the higher-risk operational changes a merchant can make. Done poorly, it causes checkout downtime, subscription billing failures, and a flurry of customer complaints. Done well, it's a transparent transition that customers never notice.

This playbook covers the key steps, timelines, and risks to manage during a PSP migration.

When to Switch PSPs

A PSP switch is justified when:

• Your current processor's pricing is materially uncompetitive after negotiation attempts
• You're experiencing recurring account stability issues (holds, limit reductions, termination risk)
• Your current PSP's acceptance rates are underperforming alternatives by more than 1–2%
• You're expanding to geographies your current processor doesn't support well
• Your business category is a poor fit for your current processor's risk appetite

For the PSP onboarding timeline to expect when onboarding a new processor, plan 2–6 weeks before your new processor is ready to receive live traffic.

Phase 1: Prepare Your New Processor (Weeks 1–6)

Start the new processor application immediately, before giving any notice to your current processor. You need the new processor live and tested before cutting over.

Key preparation steps:

Complete onboarding. Submit all required documentation (see our PSP onboarding documents checklist) and follow up weekly on review progress.

Complete technical integration. Integrate your checkout, subscription billing, and any other payment flows against the new processor's API in a staging environment. Test every payment scenario including declined cards, 3DS authentication, refunds, and partial captures.

Configure your descriptor. Set up your billing descriptor at the new processor to match what customers expect. Descriptor changes during migration confuse customers and generate unnecessary disputes.

Prepare recurring subscription migration. This is the most complex part of any PSP migration. Existing subscriptions have card tokens stored at your current processor — those tokens don't transfer. You need a plan for migrating recurring customers. Options:

• Network tokens: If both processors support card network tokenization, tokens can be ported via the network token portability process
• Re-consent requests: Email existing recurring customers asking them to update their payment method
• Parallel billing period: Bill customers once more through the old processor on their existing cycle, then migrate them to the new processor for the next cycle

Phase 2: Dual-Running (Weeks 4–8)

Before cutting over completely, run both processors simultaneously for 1–2 weeks. Route a small percentage (10–20%) of new transactions to the new processor and compare:

• Authorization rates on equivalent transaction types
• Checkout success rates (time to complete, error rates)
• 3DS authentication frictionless rates

This validates the new integration under live conditions before full cutover.

Phase 3: Cutover

New subscription enrollments: Switch new recurring billing sign-ups to the new processor first. This prevents building more customers on the old infrastructure while you migrate existing ones.

New one-time purchases: Shift new transaction traffic to the new processor after dual-run validation.

Existing recurring subscriptions: Migrate in batches by billing cycle date. Migrating all customers at once creates a support spike if anything goes wrong. Batch processing by billing date allows controlled rollout.

Complete the cut: Once all new transactions are routing to the new processor and all subscription customers have migrated, the old processor is fully unused.

Phase 4: Post-Migration

Monitor for 30 days:

• Authorization rates vs. pre-migration baseline
• Dispute rates vs. pre-migration baseline
• Customer service contacts related to payment issues

Close the old processor account correctly. Don't close until all disputes in progress are resolved and all reserves have been released. Closing an account with outstanding disputes can forfeit your right to respond. Most processors hold reserves for 90–180 days after account closure.

Update integrations. Verify all payment-related integrations are pointing to the new processor: accounting software, CRM, fraud tools, analytics.

During PSP migration, disputes filed against the old processor need continued management. Chargemate maintains representment workflows across processors simultaneously, ensuring open disputes at the old processor are contested even after migration is complete.

Frequently Asked Questions

How long does a full PSP migration take?

For a simple one-time purchase merchant with no subscriptions: 3–6 weeks from starting new processor application to full cutover. For merchants with large recurring subscription portfolios: 2–4 months for a complete migration.

Do stored card tokens transfer between PSPs?

Generally no — tokens are processor-specific. Network token portability via Visa or Mastercard is available in some cases. Most migrations require some form of customer re-consent.

What happens to open disputes during migration?

Open disputes remain with the original processor. You continue managing them through the original processor's portal even after migration. Don't close the old account until all outstanding disputes are resolved.

Will my chargeback rate increase during migration?

Migration can temporarily elevate dispute rates if customers are confused by descriptor changes or if subscription re-consent emails generate billing questions. Keeping your descriptor consistent and proactively communicating the change minimizes this risk.

Can I migrate subscriptions without asking customers to re-enter their card?

Yes, via network token portability if both processors support it, or if your old processor will cooperate in a data migration. Many processors will not export raw card data (for PCI compliance reasons) but will facilitate network token migration.