Most businesses that change providers assume the hard part is the integration. It rarely is. Development teams complete a new checkout integration in a week or two. What breaks is everything attached to the old provider that nobody inventoried first: saved cards, active mandates, webhook listeners, refund routing, and the reconciliation format the finance team has been reading for three years.
Verify authorisation before anything else
Any provider handling funds in India requires authorisation from the Reserve Bank of India under the payment aggregator framework. That authorisation is published and can be checked directly rather than accepted from a sales deck. Confirm also that settlement runs through a designated escrow account and that merchant funds are not held alongside the provider’s own money.
Data localisation applies as well. Transaction data must sit on servers located in India, and where any processing happens abroad, the data has to return within 24 hours.
Saved cards do not travel with you
This is the failure most migrations underestimate. Under RBI’s tokenisation rules, neither merchants nor aggregators may store actual card numbers. What exists in place of the card is a network token, and that token is scoped to a specific combination of merchant, card and token requestor.
Your outgoing provider is the token requestor. Change providers and the tokens stop resolving.
Card data cannot be exported to a spreadsheet and handed over. Migration requires both providers to agree to a secure exchange, after which the incoming provider generates fresh tokens and your customer database has to be remapped against them. Budget two to four weeks and treat it as a project rather than a task. Skip it and every returning customer with a saved card meets an empty checkout.
Recurring mandates are a separate asset
Card tokens and mandates are not the same thing. A UPI Autopay or eNACH mandate is registered against your entity and the provider that created it. Existing mandates generally keep running on the old provider until they expire, which means a period of dual operation for any business collecting on a schedule.
Decide early whether you are migrating the mandate book or letting it run down. Both are defensible positions. Choosing neither leaves collections split across two dashboards with no single view of failure rates.
Run in parallel, not in sequence
A hard cutover on a fixed date gives you nothing to compare against. Route a small share of live traffic to the new provider first, perhaps five or ten percent, and watch success rates broken out by switching payment aggregator method and by issuing bank. Card success rates in particular vary between providers for reasons that only surface in production.
Increase the share once the numbers hold for a full billing period. Keep the old route configured throughout.
Settlement and reconciliation
Settlement cycles differ between providers, and moving from one cycle to another shifts your working capital position for a few days during changeover. Finance should know that date before it arrives rather than after.
The reconciliation file will also change. Column names, transaction identifiers and status labels are provider-specific, so any spreadsheet or accounting integration built around the old format needs rework. Teams that discover this at month end lose a week to it.
Keep the old integration alive
Refunds for transactions processed on the old provider must be issued through that provider. The same holds for chargebacks, which can arrive months after the original payment. Terminating the old account immediately after cutover leaves you unable to service either one.
Maintain the old integration in a read-and-refund capacity for at least one full chargeback cycle before closing it. Businesses that plan for this generally find switching payment aggregators an unremarkable exercise. Businesses that treat it as a code change tend to find out otherwise during their first month-end close.
