Businesses switch payment gateways for good reasons: better pricing, better success rates, a method the old provider doesn't support, poor support, or a provider that's changing its business. The checkout part of a switch is usually the easy part. What makes migrations go wrong is everything that's quietly tied to the old provider: customers' saved cards, active subscriptions, refunds on past orders, QR codes stuck to shop counters, and the reports finance relies on.
This guide is a migration plan for merchants and the teams supporting them. It starts with an inventory, because the size of the job depends almost entirely on what you have attached to the old provider, then sets out a phased plan that keeps payments flowing throughout.
Step 1: inventory what's attached to the old provider
List everything below that you use. Each line is either straightforward, needs customer action, or has to stay with the old provider for a while.
| Item | Can it move? | What to plan for |
|---|---|---|
| One-off checkout payments | Yes | New integration; switch traffic gradually |
| Saved cards | Usually not directly | In India, new card-on-file tokens are created through the new provider with the customer's consent; expect customers to save cards again |
| Recurring mandates (UPI AutoPay, card e-mandates, NACH) | Often not | Confirm with both providers; many mandates need the customer to authorise a new one |
| Refunds on past payments | No | Refunds go through the provider that took the payment; keep the old account open |
| Disputes and chargebacks on past payments | No | Handled where the payment was taken, sometimes months later |
| Payment links and invoices already sent | No | Let them expire or reissue them |
| Printed QR codes and soundboxes | No | Replace physical QR codes linked to the old provider's UPI ID |
| Virtual accounts given to customers | No | Tell payers the new account details; watch for payments to the old ones |
| Payouts | Yes | New beneficiary set-up and funding; test small amounts first |
| Webhooks, reports and settlement files | Yes, with work | New formats into reconciliation; run both in parallel |
The saved-card and mandate lines deserve attention early, because they need customers to act. In India, RBI's card-on-file rules mean merchants and their providers can't store actual card numbers, and a card-on-file token is unique to the combination of card, token requestor and merchant. A token created through one provider generally can't simply be handed to another, so plan for customers to save their cards again, with consent and authentication, through the new provider.
Step 2: contract and onboard before you build
The new provider has to onboard you before you can take live payments, and that runs on their timetable: business documents, KYC, website checks, risk review, and sometimes method-by-method activation. Start it first, and in parallel:
- Confirm every method you need is enabled for your business category, including international cards if you take them.
- Agree pricing, settlement timing, rate limits and any transaction or volume limits on the account.
- Ask how they can help with saved cards and mandates, and get the answer in writing.
- Check the notice period and exit terms on the old contract, and when to give notice. Don't give it until the new provider is live.
Our merchant onboarding checklist lists the documents most providers ask for.
Step 3: build behind a seam
The cleanest migrations put both providers behind one internal interface, so the rest of your systems don't know or care which provider took a payment:
- An adapter for each provider that maps requests, statuses, errors and references into your own model. Our guide to payment orchestration architecture shows this pattern.
- A routing switch, ideally a percentage, that decides which provider new payments go to, changeable without a deploy.
- Payments that record which provider handled them, so refunds, status checks and reconciliation go to the right place.
- Separate webhook endpoints and secrets per provider, both live at the same time.
- Reconciliation that understands both providers' settlement reports.
This seam is also what makes the next migration, or a second provider, much cheaper.
Step 4: test the unhappy paths
Test the new provider in its sandbox for more than successful payments: declines, timeouts, pending payments that resolve late, duplicate and out-of-order webhooks, full and partial refunds. Our payment gateway integration guide has a minimum test plan. Then run a handful of real low-value payments on production with every method before any customer traffic goes there.
Step 5: parallel run, then ramp
Don't switch everything at once. Send a small share of new payments to the new provider, compare, and step up:
- PilotA small share of new one-off payments on the new provider; everything else unchanged. Compare success rate, latency and declines by method.
- RampIncrease the share in steps, holding at each until the numbers are stable and reconciliation is clean for that period.
- DefaultNew payments go to the new provider; the old one remains available as a fallback.
- Recurring and saved cardsCustomers re-save cards and authorise new mandates as they pay; old mandates continue on the old provider until replaced.
- TailThe old account stays open for refunds, disputes and remaining mandates, then closes.
Decide in advance what would make you stop and roll back, such as success rate on a method falling below the old provider's for a sustained period, and make rollback the same switch as the ramp.
Moving recurring customers
Subscriptions are the hardest part of most migrations, because the payment happens without the customer present. Options, from least to most disruptive:
- Leave existing mandates on the old provider and put only new subscriptions on the new one. Simple, but you keep two providers for as long as old mandates live.
- Ask customers to authorise a new mandate at a natural moment, such as a renewal, a plan change or a card expiry, with a clear explanation.
- Run a re-authorisation campaign before a fixed date, with reminders, and a fallback such as a payment link for anyone who doesn't act.
Never cancel an old mandate until its replacement is active, or a customer may miss a payment through no fault of their own. Our guides to UPI AutoPay and NACH vs eNACH explain how each kind of mandate works.
Keep the old account for the tail
Closing the old account too early is the most common and most avoidable migration mistake. Past payments still need it:
- Refunds on orders paid through the old provider must go back through it.
- Chargebacks and disputes can arrive months after the payment, and need a response through the provider that took it.
- Final settlements, and any reserve or holdback in the old agreement, have to be received and reconciled.
- Remaining mandates keep collecting until they're replaced.
Agree with the old provider how long the account stays open for these, and keep someone responsible for it.
Tell people
Customers notice a migration only when something changes for them, so tell them when it does: a new payment page, a request to save a card again, a new mandate to approve, new account details for bank transfers. Tell your support team first, with answers ready. For finance, explain the new settlement reports and timing before the first one arrives.
A migration checklist
Before you start sending real traffic to the new provider:
- Inventory complete, with an owner for saved cards, mandates, QR codes and virtual accounts.
- New provider onboarded, methods enabled, limits and settlement terms confirmed.
- Both providers behind one interface, with a percentage switch and per-provider webhooks.
- Reconciliation handles both providers' reports.
- Unhappy paths tested in sandbox; low-value live payments tested on every method.
- Ramp steps, comparison metrics and rollback triggers agreed.
- Customer and support communication ready.
- Old account kept open for refunds, disputes and mandates, with an owner and an end date.
An orchestration layer turns a migration into a routing change for new payments. LILPE's one integration page describes adding or switching providers without merchant code changes, and its multiple payment providers page describes giving a new provider a small share of traffic to evaluate it.
Frequently asked questions
How long does it take to switch payment gateways?
The integration itself can be quick; onboarding with the new provider, testing, a phased ramp and moving recurring customers take longer, and the old account usually has to stay open for months afterwards for refunds and disputes. Plan the timeline around onboarding and recurring payments, not the code.
Can I move saved cards to a new payment gateway?
Usually not directly. In India, merchants can't store card numbers, and card-on-file tokens are unique to the card, the token requestor and the merchant, so customers generally need to save their cards again through the new provider, with consent and authentication.
What happens to subscriptions when I change payment gateway?
Existing mandates are usually tied to the old provider. You can leave them there and put new subscriptions on the new provider, or ask customers to authorise new mandates at renewal or through a campaign. Don't cancel an old mandate until its replacement is active.
How do I refund a payment taken by my old payment gateway?
Through the old provider, which is why you should keep that account open after switching. Refunds go back through the provider that took the payment, and the same applies to disputes and chargebacks.
Go deeper
Official sources
- RBI — Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services (7 Sep 2021)For CoFT, the token is unique for a combination of card, token requestor and merchant; tokenisation requires explicit customer consent with additional factor of authentication.
- RBI — Restriction on Storage of Actual Card Data [i.e. Card-on-File (CoF)] (24 Jun 2022)
Last reviewed . Examples, amounts and screens marked illustrative are not LILPE figures.
