Reconciliation
Part of Changing a checkout or payment provider
Keeping a rollback option during a payment migration
Keep future checkout routing reversible while preserving ownership of submitted payments and unresolved attempts.
Keep a verified way to send future eligible checkouts through a working previous route until the new one meets its release conditions. Payments already submitted remain with the provider that received them. Changing a routing setting cannot undo a charge, resolve a pending attempt or transfer its refund to another provider.
Define what can be reversed
A rollback may restore the old checkout page, the old payment connection or only the rule assigning new orders. Record which components remain available, who can activate them and which order types they support. Confirm that credentials, account access, payment methods and the old integration still work before relying on that route.
Keep the assigned provider, order ID, payment reference and attempt state with each checkout. A buyer refreshing during a change must not silently start payment with another provider. Investigate an unknown first outcome before offering a second charge route.
Set the trigger and response
Choose observable triggers before rollout: an incorrect payable amount, repeatable inability to submit payment, paid orders failing to reach their required state, or unresolved attempts above the store’s agreed tolerance. Name the person who can activate the response and set thresholds for the actual store.
- Pause expansion and stop assigning new eligible checkouts to the faulty route.
- Save the routing version, affected order list and provider references.
- Resolve or hold attempts already submitted; keep them with the provider that received them.
- Send only new eligible checkouts to the confirmed working path.
- Check a permitted purchase and its order outcome on the restored path, then review live exceptions.
If the old route cannot accept the relevant orders, hold new payment attempts until a safe route is available. Tell buyers the known status of an interrupted order. An unknown outcome is not a confirmed failure or permission to retry automatically.
Key Metrics for Monitoring During Migration
- Repeatable failure rate in payment submission
- Track if failures exceed acceptable levels
- Paid orders not reaching required state
- Flag orders that fail to confirm status
Operate both providers during recovery
The old provider may still handle refunds and records for older sales; the new provider handles payments it received before rollback. Keep staff access and exception ownership for each. Saved-payment and recurring arrangements also need a provider record.
Adyen’s migration example: new tokenisations and older recurring charges temporarily run at different providers; other migrations may differ.
Payment events can arrive after routing changes. Stripe webhooks deliver event data, including asynchronous payment updates.
Keep events tied to their original provider and payment reference, and apply order changes only when they fit the current payment and order state. Review unresolved attempts after rollback so a delayed success does not become an unfulfilled paid order or prompt a second payment.
Retire the previous route only when the new route meets its acceptance conditions and remaining older work has a supported process.
Old vs New Payment Provider Handling During Rollback
- Old ProviderHandles refunds and records for older sales; may manage recurring charges and saved payments.
- New ProviderManages payments received during the migration period; must be kept active for event processing.
