Planning a PSP migration: subscriptions and obligations left behind

The new payment button works. Marketing announces that migration is complete. The next day, a customer requests a refund for last month’s order while finance waits for the old PSP’s final payout. The move was ready only for new sales. Historical obligations remained at the old address.

A provider migration contains several transitions: new acceptance, servicing old transactions, transferring eligible data, managing subscriptions and closing settlement. Track them as separate workstreams with their own completion criteria. A single checkout-switch date cannot close all five.

Map what will remain behind

Before changing traffic, prepare an authorised register of open obligations: unresolved transactions, possible refunds, disputes, reserves, expected payouts and subscriptions. Use only necessary fields and protected storage. Give each category an owner, status source and closure condition. A dashboard balance without a breakdown does not explain which duties survive the contract.

The proposed routing principle is straightforward: an action belongs with the process that can legitimately service it. A refund of an old payment cannot automatically be sent to the new PSP with the old identifier. Confirm the supported path with both parties and preserve the access required for agreed operations. If the old contract is ending, agree how subsequent servicing works and which restrictions apply.

Support should search by order number and then see the provider of the particular payment. Customers should not need to remember your technical migration date. If support can see only the new system, employees may create a parallel spreadsheet of old orders and introduce another source of mistakes.

Payment-data migration is not subscription migration

A payment token, card details, customer profile and billing schedule are different objects. A field named token in an export does not prove that the new provider can use it. Stripe describes dedicated payment-data migration processes involving its migration team. See its migration overview. Availability and conditions need verification for the particular methods and parties.

After importing recurring-payment details, Adyen supplies a migration-results file. See the Adyen import procedure. The operating implication is to maintain a verifiable mapping between old and new identifiers, including records that did not migrate successfully. A process that finished without a visible error is not proof that every customer transferred.

Transmit sensitive card data only through the providers’ agreed secure process and with the necessary authority. A shared spreadsheet or email to an account manager does not become an acceptable transfer method because the project is urgent. Prepare a clear supported update journey for customers whose payment details cannot be migrated.

One invoice needs one collection owner

Imagine a EUR 30 subscription renewing on the fifteenth. During migration, the old scheduler remains active while the new system already has the customer and renewal date. Both can correctly follow their instructions and create two charges. Idempotency within each PSP does not resolve this collision between independent systems.

Before activating the new schedule, record which system owns each billing period. Reconcile the last paid period, next invoice, trial, discounts and pending changes. Verify that the previous system can no longer initiate collection for that same period. The switching sequence depends on the products and should be rehearsed with synthetic data.

Include a cancellation that arrives between the export and cutover. Monday’s snapshot does not reflect Tuesday’s customer decision. A migration needs change capture or a bounded freeze appropriate to the product. Freezing internal configuration must not remove the customer’s required way to cancel the service.

Keep the support view aligned with the collection owner. An agent should be able to tell whether a cancelled invoice is historical, pending migration or already replaced. Otherwise a well-intentioned manual retry can defeat the careful scheduler handover.

Verify the move in cohorts

Begin with an agreed limited segment and expansion criteria: correct amounts, expected states, workable support and reconciled records. Assess new and previously paying customers separately: their failure reasons and required actions can differ. Choose your sequence around the actual business model rather than the convenience of one test card.

Retain the starting membership of each cohort. Missing customers then become visible, and conversion comparisons do not silently mix different populations. Rollback also needs explicit rules: which new operations can return to the old route, and which must complete where they started? Reverting the website version does not undo financial transactions.

The migration ends when new sales work, historical obligations have an agreed servicing process, all balances are explained and unnecessary access is revoked after its dependencies close. Complete that final step against a verified list. Saving the cost of the old account too early can remove the ability to handle the next legitimate refund.