Moving payment providers without dropping transactions

Imagine a platform that takes card payments for a few thousand merchants and has decided to move from one payment service provider to another. The new contract is signed and the integration is built. What remains is three or four months with both providers live, money settling from two places, and two possible sources for every problem.

A migration is easier to run when it is planned as a period of overlap with a start date and an end date. The operational work sits inside that period: moving card data between vaults, moving traffic in stages, reconciling two sets of settlement files, and keeping a way back open in case the new provider underperforms.

Start with the card data

If you store cards for repeat or subscription payments, the tokens you hold today point into the old provider's vault and mean nothing to the new one. To keep charging those customers without asking them to enter their card details again, the underlying card data has to move from one vault to the other.

PCI DSS sets the limits on how that happens. Card numbers can only pass between compliant parties, which in practice means the old provider sends an encrypted file directly to the new one and your own systems never see a card number. If you are out of scope for storing card data today, keep it that way: nothing in the plan should bring card numbers into your environment, even for a day. What comes back to you is a mapping file linking each old token to a new one, and your systems have to swap them without losing the link to the customer and their subscription.

Start this early. The export depends on the old provider, which is losing your business and has little reason to hurry. Check what your contract says about data portability and timelines, and raise the request as soon as the new contract is signed. Plan for at least one delta export to catch cards added or changed after the main file was produced. Cards that expire or get replaced during the overlap, and customers who save a new card, both leave gaps that need a rule.

Moving traffic in stages

Routing a share of transactions to the new provider lets you compare the two on real traffic before you depend on the new one. If your routing layer can split by percentage, card brand, currency or merchant, use it to move in steps.

1. A small slice of one payment type

   Start with a few percent of one card brand in one currency, for merchants who have agreed to go first. Compare authorization rates and decline codes with the old provider for the same mix.

2. A wider mix

   Add currencies and card brands once the first slice has run cleanly through several settlement cycles, including a weekend and, if the timeline allows, a month end.

3. Most traffic, old provider still live

   Move the majority across while the old provider stays available as a fallback route.

4. Full cutover

   Stop sending new payments to the old provider, and keep the account open for refunds and disputes for as long as they keep arriving.

Two providers, two settlement files

During the overlap your reconciliation has twice the sources and more than twice the ways to go wrong. The providers will send settlement files in different formats and on different schedules. Say one pays out daily at T+1 with fees invoiced monthly, and the other pays at T+2 with fees netted from each payout. Your ledger needs a provider field on every transaction, set at authorization, so each settlement line can be matched to the right provider and the right file. A Friday payment routed to the new provider shows up as missing from the old provider's file without that field, and someone spends Monday looking for it.

Keep the unmatched items from both providers in one queue with one owner. Splitting them by provider is how items age without anyone noticing. Reconciliation is an operations problem at the best of times, and a migration is not the best of times.

Settlement timing also moves cash. If the new provider settles a day later than the old one, the week you move most of your volume will show a dip in cash received that is purely timing. Tell treasury before it happens, and if you pay merchants out of settled funds, check that the dip does not land on a payout run.

Refunds and disputes stay with whichever provider processed the original payment. Support and disputes teams need to see which provider handled any given transaction, and the refund flow has to route by that field. Chargebacks on old transactions will keep arriving at the old provider for months after cutover, so someone must keep watching that portal and its evidence deadlines.

A rollback you would actually use

Every migration plan has a rollback section. Fewer of them say who decides, on what evidence, and what a rollback cannot undo.

Set the triggers in numbers before the first transaction moves. For example, with figures that are only illustrative: an authorization rate on the new provider more than two points below the old one for the same card mix over 24 hours, a settlement file more than a day late, or API errors above an agreed level for an hour. Name the person who can make the call, and check that moving traffic back is a routing change someone can make in minutes, without a deployment or a change approval.

Then look at what a rollback leaves behind. Customers who saved a card during the overlap have a token only at the new provider. Refunds on payments the new provider processed still have to go through it. Moving the routing back is easy, while moving the data back needs a reverse token export, which you probably have not asked for. Decide beforehand whether you would request one, or accept that those customers will be asked for their card details again.

What merchants will notice

Merchants and their customers see a migration in small ways that generate calls. The descriptor on cardholder statements may change, and some cardholders who do not recognize a new name will raise a dispute. Payout timing may move by a day. Settlement reports change format, which breaks any merchant whose finance team built a reconciliation around the old one. Send merchants the dates, a sample of the new report and the new descriptor before their first payment moves. Brief your support team a week before that, so the first calls do not catch them out.

Discuss your operations