Switching payment processors?
Start with a working checklist.

Before you set a date, define what is changing

A processor switch can affect more than the checkout button. Your acquiring arrangement, gateway, point-of-sale hardware, billing software and stored payment information may sit with different providers. Moving one does not automatically move the others.

Start with a reason for the change: clearer costs, a different sales channel, a support issue or a business model your current arrangement does not fit. Compare the written offer and the work required to move. Do not cancel the old service simply because you submitted a new application.

This is a planning checklist, not a promise of uninterrupted processing. Approval, migration options, account terms and timing must be confirmed for your business. If cost is the main concern, first read and reconcile your current statement.

Map the current setup

Write down who owns each part of the payment journey. Include every place customers can pay: web checkout, store terminals, payment links, invoices, phone orders and subscriptions. A forgotten renewal system can matter as much as the main storefront.

• Accounts and agreements: processor/acquirer, gateway, software and equipment arrangements; account contacts; cancellation and notice terms.
• Tools and connections: store platform, POS model, plugins, billing app, accounting exports and any custom integration.
• Customer records: where saved payment methods and subscription schedules are held, and who can arrange an approved transfer.
• Open work: authorized but uncaptured orders, unsettled batches, expected refunds, active disputes and reserves.
• People: a business decision-maker, technical owner, finance owner and support contacts at both providers.

Describe the business accurately in the new application, including recurring billing or delayed delivery. Our merchant account application guide explains what to prepare before review.

Get confirmations before committing to a move

Use this matrix in the provider conversation. Record the answer, the person who confirmed it and the relevant agreement or document. An empty row is unfinished work; a verbal expectation is not a substitute for an account term.

A merchant account, payment facilitator and gateway can involve different responsibilities. Review the account-model comparison if the offer changes the arrangement as well as the price.

Treat saved payments and subscription schedules separately

Confirm portability with both providers before promising customers that they will not need to update their payment method. A customer record, a saved payment credential, a subscription schedule and transaction history are different pieces of information.

Stripe provides a useful provider-specific example: its payment-data export is transferred through an approved process to an eligible receiving processor. Its documentation distinguishes that export from subscriptions and payment history, and excludes credentials saved through Link. These conditions are not a statement of every provider’s policy. Stripe’s export documentation ↗

For each subscription, plan how you will reconcile the customer, amount, currency, next billing date, status and applicable trial or discount. Assign one system responsibility for each renewal and pending retry during the transition. Stripe’s import guidance also separates payment-data migration from importing subscriptions. Stripe’s migration documentation ↗

If a payment method cannot move, prepare the provider-approved way for customers to update it. Explain what action is required and confirm any authorization or notice requirements for your setup. For the broader operating questions, see subscription payment processing.

Test the customer journey before routing new business

Agree a test plan with the provider and whoever manages your website or POS. Use the provider’s sandbox and documented test methods for simulated transactions. Test credentials and production credentials serve different purposes; Stripe, for example, tells developers to use its test environment and test payment details rather than real card details for testing. Stripe’s testing guidance ↗

• Successful and unsuccessful checkout: the customer sees the right result, and an unsuccessful attempt does not create a paid order.
• Order handling: the order amount, currency, tax/shipping configuration and fulfillment status match the intended transaction.
• Duplicate prevention: a retry or repeated notification does not create a second payment or renewal.
• Refund and cancellation handling: staff can follow the intended procedure and find the resulting records.
• Customer communication: receipts, contact details and payment instructions show the right business identity.
• Reporting: finance can find the relevant transaction, batch, fee and payout reports.

A successful sandbox result does not establish that a real bank payout will arrive. Follow the provider’s permitted production-launch procedure, then reconcile actual business transactions and their expected deposits. Do not assume a successful checkout confirms every step through funding.

Use a written cutover checklist

Choose a change window with the people and provider support needed to respond. Define what must be true before you proceed, how you will pause if something fails, and which existing systems can remain available under your agreements. Running two providers in parallel is an option to confirm, not a universal requirement.

1. Confirm readiness. The new account is approved for the intended activity, the integration is ready, and the written account conditions are understood.
2. Set the transaction boundary. Record which system handles new sales, existing authorizations, each subscription renewal and refunds for old orders.
3. Record the starting position. Save the relevant order, renewal and funding totals so you have something specific to reconcile after the change.
4. Change only the agreed routes. Follow the approved platform or integration procedure and record who made the change and when.
5. Check real business activity. Monitor completed orders, declines, notifications, renewals and support requests. Investigate unexplained differences before expanding the change.
6. Reconcile the money. Compare expected payouts with actual bank receipts on the account’s agreed schedule; record timing differences and deductions.
7. Document the outcome. Keep unresolved issues assigned to someone, with a provider contact and a next action.

Here is a fictional renewal boundary: the old billing system is assigned a customer’s last scheduled charge on October 1; the new one is assigned the next on November 1. Before switching that customer, confirm the October result, handle any pending retry explicitly, and verify November’s amount and date. The dates are illustrative; the principle is a documented owner for every charge.

If the customer-facing billing name changes, make receipts and support communications explain it accurately. Our statement-descriptor guide covers how to reduce avoidable confusion.

Stopping new sales does not finish the old account work

Before closing or deleting anything, get written instructions for remaining settlements, reserve balances, refunds, disputes, reporting access and any ongoing charges. Export the business records you are entitled to retain through the provider’s approved tools and protect them appropriately.

Ask when each old agreement can end; the processor, gateway, software and equipment arrangements may need separate attention. Do not assume that removing a checkout integration cancels all related billing, or that opening a new account releases money held by the old provider.

Track the transition until the outstanding items are accounted for. The appropriate monitoring period depends on the activity and obligations still open, not an arbitrary two-week deadline.

Common switching questions

How long will a switch take?

There is no single reliable timeline for every business. Underwriting, equipment, software work, data portability and billing schedules can each affect it. Ask both providers for the dependencies and milestones rather than relying on an advertised average.

Can I keep my existing equipment or saved cards?

Possibly, but confirm the exact model, configuration and data arrangement. Do not treat “we support your platform” as confirmation that every terminal, plugin or saved payment method will work unchanged.

Will switching guarantee lower costs or prevent account holds?

No. Compare the full written offer using your actual sales mix and needs. A new provider makes its own underwriting decisions and applies its own agreement. A switch does not remove ongoing obligations under the old arrangement.