Switching payment provider is usually motivated by rates, reliability or a feature the incumbent lacks, and it is scoped as an integration project. The integration is the straightforward part. What makes these migrations difficult is everything that already exists at the old provider — tokenised cards, active recurring mandates, in-flight disputes and settlement history — none of which transfers automatically.
Tokens are the first hard constraint. Under Indian tokenisation rules a token is specific to the combination of card, token requestor and device, which means the tokens held through your old gateway are not usable through the new one. Customers with saved cards must re-authorise, and each re-authorisation is a step at which some of them abandon. Any plan that treats saved cards as portable data is wrong, and the migration needs a customer communication strategy rather than only a technical one.
Recurring mandates are worse because the customer relationship depends on them continuing. A subscription business with e-mandates registered through the old provider cannot simply point them elsewhere; mandates need re-registering with fresh authentication, and every customer who does not complete that becomes an involuntary churn. This is the single largest risk in the whole exercise and it argues for a long overlap rather than a cutover — new customers on the new gateway, existing mandates left running on the old one until they lapse naturally.
Run both in parallel for longer than feels necessary. Route a small share of new traffic to the new provider and compare success rates on your own customers, because a provider's published figures tell you nothing about your particular mix of methods, banks and card types. Watch the failure reasons rather than the aggregate, since a provider can look worse overall while being better on the instrument that matters most to you.
Keep the old provider's data before you close the account. Settlement history, dispute records, transaction references and any documentation you may need for a chargeback or a tax query. Once the relationship ends, retrieving this becomes a support request to a company with no commercial reason to prioritise you, and reconciliation of an old dispute without it is not possible. Export it, verify the export is complete, and store it where your finance team can find it in two years.
The migration should end with a decision rather than a completion. After the parallel period, compare the two on the numbers you actually care about — success rate by method, cost per transaction all-in including hidden fees, settlement timing, and how the support relationship felt during a real problem. Occasionally the honest answer is that the incumbent was better and the move should be reversed, and having run it in parallel is what makes that reversal possible rather than embarrassing.
