Changing Payment Providers: Preserve In-Flight Transactions After Cutover

Header image: conceptual illustration.

A provider cutover does not end the lifecycle of payments created before it. Old transactions can still produce notifications, refunds, disputes, settlement adjustments or unresolved status checks after new checkout traffic has moved elsewhere.

A safe migration separates routing new attempts from servicing existing operations. This guide focuses on those in-flight records, not on transferring raw payment-card data or claiming that credentials and tokens are portable.

Inventory the old-provider tail

List pending attempts, successful payments still awaiting settlement, available refund windows, open disputes, reserve or adjustment records and report dependencies. Identify the owner and required access for each category.

Preserve provider, merchant-account scope and environment on every resource. A resource identifier from provider A cannot be retrieved by provider B merely because both appear in the merchant's payment dashboard.

Use the provider selection guide to assess the new service, but do not confuse commercial selection with completion of the old provider's financial obligations.

Route by attempt creation, not the current default

An order created before cutover can contain an old-provider attempt. Its status checks and notifications should continue using that attempt's recorded provider. A global configuration switch must not redirect all historical lookups to the new provider.

For new attempts, record the chosen route at initiation. If rollback changes the default again, already-created new-provider resources remain associated with that provider. This prevents a rollback from orphaning the transactions that occurred during the pilot.

A failed old attempt may permit a later new-provider attempt under the merchant's authorized workflow, but an uncertain old outcome should not be duplicated across providers. Resolve it first rather than treating provider migration as an exception to payment safety.

Keep the receiving and reporting paths available

Retain old-provider notification verification and routing while outstanding resources can still generate relevant events. Confirm how credentials and endpoints will be maintained, and who can access historical reports and refunds.

Stripe's webhook documentation describes retry and delivery behavior that can continue after an initial event. Its refund documentation describes later refund changes. These illustrate why stopping all old-provider processing at checkout cutover can lose legitimate financial updates.

Do not copy raw card data, wallet credentials or sensitive tokens into a spreadsheet as a migration shortcut. Any payment-data portability must use authorized provider processes and applicable security obligations, outside this operational routing checklist.

Old and new attempts after the routing switch

Invented example: At a chosen cutover point, a merchant sends new attempts to provider B. DEMO-OLD-1 remains processing at provider A. DEMO-OLD-2 succeeded at A but has an unresolved settlement adjustment. DEMO-NEW-1 is created at B.

The recovery job checks DEMO-OLD-1 through A. Finance reconciles DEMO-OLD-2 using A's report. DEMO-NEW-1 uses B for status and fulfillment. If the pilot is stopped, new initiation can return to A while DEMO-NEW-1 remains serviceable through B.

A late success for DEMO-OLD-1 is validated against the expected merchant/order, amount and currency and credited once. The cutover does not move that resource to B or generate a second payment to simplify reporting.

Reconcile both populations independently

Create an explicit cutover record and label reports by provider and account. Verify total collections, adjustments and settlement per currency before combining summary figures. Avoid matching by abbreviated resource identifiers that may collide between providers.

Run a limited authorized pilot and verify the first new-provider transaction through status, notification, ledger and reporting. The integration checklist supplies the broader launch tests; migration needs these plus the historical-tail checks.

Retirement criteria should be evidence-based. Pending counts alone may be insufficient if refund or dispute obligations remain. Confirm contractual access, retention and export requirements before closing the old service.

Migration acceptance checklist

• Every attempt retains provider/account/environment routing.
• New default routing does not alter historical resources.
• Unknown old outcomes cannot trigger duplicate new-provider payments.
• Old notifications, refunds and reports retain authorized access.
• Rollback preserves new-provider resources created during the pilot.
• Financial totals reconcile independently before aggregation.
• Sensitive data portability uses authorized processes, not manual copying.
• Retirement has explicit financial and contractual criteria.

Decisions before retiring the old provider

Can we turn off the old webhook when new checkout uses the new provider?

Not merely because checkout moved. Determine which outstanding operations can still produce relevant updates and keep the required path available.

Does rollback move new transactions back to the old provider?

No. Change routing for future attempts while preserving the actual provider relationship of existing resources.