Changing a checkout or payment provider

Change providers in stages. Identify what the old provider must continue to handle, prepare the new route for new orders, release it to a limited group, and retire the old route only when its remaining work has an owner. Taking a new payment does not close out older refunds, disputes, recurring charges or reports.

Define the change

A checkout change may replace the page buyers see, the payment provider, or both. Record which system will create payment attempts, report outcomes, update orders, issue refunds, handle disputes and supply financial records after the change. Check those responsibilities against the store’s platform, account and contract; a documented provider feature may not be available in the proposed arrangement.

For each purchase route, note its payment methods, charge currency, order reference and the outcome required before fulfilment. Include failed, cancelled and pending attempts. Keep the provider and its payment reference with every attempt, including retries.

Treat provider availability as an arrangement-specific dependency, not a promise that every account can use a documented migration feature. Stripe advises contacting the previous processor about its migration process and identifying which customer records and payment methods are in scope before the migration plan is finalised.

Separate new sales from older payments

Find a payment by the provider that processed it, even if the customer contacts the store after cutover. Keep the access and records needed to resolve older refunds and disputes, subject to the old provider’s account and contract terms. Confirm when support and report access end before closing that account.

Saved payment details need a separate plan. A token from one provider should not be assumed to work at another. Stripe describes a coordinated transfer of customer and associated payment data, starting its migration plan with new customers.

Adyen describes moving new tokenisations first while older recurring charges continue at the previous provider. Whether a particular method can move depends on both providers and the merchant’s arrangement. If it cannot, customers may need to update their payment details.

Pros and Cons of Coordinated vs. Direct Payment Data Transfer

Sequence the dependencies

Build the timetable around work that depends on the previous processor, not just the date the new checkout is ready. Stripe says to consider the previous processor, customer count and upcoming deadlines when scoping a migration timeline; its migration process also involves coordination between the merchant, Stripe and the previous processor.

Adyen says payment-data migration usually takes 10 days or more because of technical and compliance complexity, and that it does not charge for the migration. Treat this as a planning consideration rather than a guaranteed duration, and confirm the current processor’s process before setting a cutover date.

Include any period when tokenisation and recurring charges must operate across both providers; Adyen lists this as a migration requirement.

Key Milestones in Payment Provider Migration

Migration Timeframes and Support Requirements

Prepare the handoff

Before changing live routing, make the store order ID, provider account, payment reference, amount, currency and outcome available to staff. Map each provider’s actual statuses to the store’s order states; similar labels need not mean the same event.

Export the old transaction and financial records while access is available, and arrange later exports for adjustments to older sales. Keep field definitions with the files so an order can be found again.

Pre-Launch Migration Readiness Checklist

Assign migration owners

Name an internal owner to coordinate the processor contacts, track requested information and resolve issues raised during the transfer. Stripe’s process asks the merchant to provide details including the previous processor, Stripe account number, number of records and payment methods planned for import, then follow communications between Stripe and the previous processor and respond to identified issues.

Assign an owner for the store’s customer and subscription records as well. Stripe says the migration can provide a JSON mapping file that the merchant parses and uses to update its database. The plan should also cover remapping subscriptions where applicable and a process for customers to update card information. Keep these responsibilities with the people who can maintain the store’s customer-to-order links.

For a migration involving Adyen, establish the internal shopper reference before the transfer and check with the current processor that it can use that reference; if not, Adyen says to choose one of the processor’s IDs to link to it. Also confirm which team will keep tokenisation and recurring charging workable across both providers during the transition.

Release and recover

Use the provider’s permitted test setup to check a purchase, failure or cancellation, retry, and delayed outcome where the chosen method supports one. Compare the buyer’s payable amount with the payment request and order. A return to a success page alone may not establish payment success; follow the dependable outcome supplied by the integration.

The change is ready to close when new orders use the intended route, older cases remain serviceable, both sets of records can be retrieved, and staff know who owns each exception.