Switching payment gateway without losing your history

Changing gateway is usually driven by cost, and the cost comparison is straightforward arithmetic. What is not straightforward is the transition, and the part almost nobody plans for is the history.

A gateway account that has been closed is a portal you can no longer log into, holding the only detailed record of several years of your own transactions.

What you are actually leaving behind

Your accounting system holds your orders and your revenue. It does not hold the gateway's version of events, and that version matters more often than you would expect.

Transaction-level fee detail for prior periods. Needed to answer any question about historical margin by payment method.

Chargeback records and their outcomes. These have long tails. A dispute raised near your switch date can still be running months later, and the evidence lives in the old provider's system.

Settlement reports for closed periods, which are the supporting documents behind your bank reconciliation. An auditor asking how a specific deposit was made up needs these.

Reserve and hold history. A rolling reserve does not release when you leave. It releases on its own schedule, from an account you may have stopped monitoring — see payment gateway holds and reserves.

Stored payment credentials, if you take recurring payments. These generally do not move between providers, which is a much larger problem than it first appears.

Pull the history before you cancel

This is the whole message of this article, and it is a single afternoon of work done at the right moment or an impossible task done at the wrong one.

Export everything while the account is live. Every settlement report, every transaction export, every dispute record, for the full period you are required to keep records. Not a sample. All of it.

Take it in the most detailed format available. A per-transaction export, not a monthly summary. You cannot re-derive detail from a total, and the questions you will be asked later are always detail questions.

Store it where your accounting records are stored, not in somebody's downloads folder. It is supporting documentation for your books, and it should be filed as such.

Check that you can read it. Open the export. Confirm the fields you need are actually present, particularly the reference that joins to your orders — see the gateway reference that joins everything. Discovering that a file is useless is recoverable while the account is open and not afterwards.

Ask the outgoing provider how long the portal stays accessible after closure. The answer is sometimes a short window and sometimes nothing, and it is not a question to be asked retrospectively.

The overlap period is the hard part

You will run both gateways at once. There is no clean cutover, because in-flight transactions do not respect your migration date.

For several weeks you have two providers settling, two report formats, two fee structures and two reference schemes, all paying into your bank. That is the reconciliation problem described in reconciling two gateways into one bank account, with the extra difficulty that one of the two is winding down and nobody is paying attention to it.

Three things go wrong specifically during overlap.

The tail is longer than the switch. New payments move to the new provider on day one. Refunds, chargebacks and reserve releases on old transactions keep arriving through the old one for months. The old account cannot be closed when the last new payment goes through it.

Refunds must go back the way they came. A refund on a payment taken through the old gateway generally has to be processed through that gateway. If the account is closed or emptied, the refund has to be made by another route, and it no longer reconciles against anything.

Attention drops. The old provider's settlements stop being reviewed because the team has moved on, and unallocated credits accumulate quietly in exactly the period nobody is looking at.

The migration order that keeps the books intact

Export the full history first, before anything else changes.

Set up and test the new gateway in parallel, with a distinct clearing account in your ledger from day one so the two streams are never mixed.

Move new payments across. Keep the old gateway enabled for refunds only.

Reconcile both streams every cycle, including the dwindling one, until the old provider's clearing balance is zero and stays zero.

Confirm the reserve has fully released and any final holdback has been paid before you close anything.

Then close the account, and only then, having re-verified that your exported history is complete and readable.

If you take recurring payments, add a step at the front: establish whether stored credentials can be migrated at all, because if they cannot, every subscriber has to re-enter a card and a meaningful share of them will not — see managing recurring billing.

Questions to settle with the outgoing provider

Ask in writing, and before you give notice.

How long does portal access continue after closure, and in what form. When does the rolling reserve release, and to which account. How are refunds handled once the account is closed. How long are disputes accepted against historical transactions. Is there a final settlement or holdback, and on what timetable.

None of these are unreasonable questions and all of them have answers. Their value is that they turn a vague tail risk into a set of dates you can put in a calendar — see how to evaluate AI accounting software for the same discipline applied to software generally.

Common questions

What should you export before closing a payment gateway account?

Every settlement report, transaction-level export, dispute record and reserve statement for the full period you are required to retain records, taken in the most detailed format the provider offers. Once the account closes, portal access often ends within a short window or immediately, and per-transaction detail cannot be reconstructed from summaries you kept instead.

How long do you need to keep the old gateway running?

Longer than the payment switch itself. Refunds, chargebacks and reserve releases on transactions taken through the old provider keep arriving for months after new payments have moved across, so the account has to stay open until its clearing balance is zero, the reserve has released and no disputes remain open.

Can refunds be processed through a different gateway?

Generally not against the original transaction, which is why the outgoing account has to remain able to refund. Making the payment by another route is possible but it no longer reconciles against the original sale, so the refund and the sale sit in different streams and the matching has to be done by hand.

Do stored cards move to a new gateway?

Usually not. Stored payment credentials are typically held by the provider and do not transfer, so a store taking recurring payments has to get subscribers to re-enter their details, and some proportion will not. That makes the credential question the first thing to settle when subscriptions are involved, not a detail to handle later.

Related: running more than one payment gateway · gateway API or settlement file · payment gateway holds and reserves