In this article
A platform migration fails in the details, not in the architecture: a merchant whose webhook format changed, a token that does not work on the new vault, a report finance cannot reconcile. This checklist is what we go through with every client that moves to Tranzify, in the order that keeps the merchants paying while the move happens.
Before the first merchant
- Providers and terminals. Every acquirer and method provider with its accounts, currencies, operations and limits, entered in the new terminals; sandbox payments through each.
- Routing rules. Rebuilt in the flow builder from the old rules, reviewed with the operations team, with the recovery numbers of the old platform as the baseline.
- Fees and reserves. Per merchant, as in the old ledger; the first settlement is the test.
- Users and roles. Who sees what in the back office; the audit log on from day one.
- Domain and brand. The network under the PSP’s domain, the checkout’s look, the mail sender.
- The inventory of merchants. Every merchant with its integration type, its methods, its stored cards and subscriptions, its webhook endpoint and the person who answers for it; the order of the migration follows this list.
Per merchant
- Integration type. Hosted checkout merchants change a link; API merchants map their flow to the Tranzify API in the sandbox and switch keys when the tests pass.
- Webhooks. The format the merchant parses today; a new integration needs a test of its webhook handling before the switch.
- Tokens. Stored cards are re-tokenised on the first successful payment where the acquirer allows; tell the merchant which subscriptions need a new authentication.
- Reports. The merchant’s finance team reconciles the first week by hand against the old reports.
- Refunds of old payments. Refunds of payments made on the old platform are made there until it is switched off; the merchant’s support team needs to know which platform a payment lives on, by its date.
The order of merchants
| Wave | Who | Why first |
|---|---|---|
| 1 | One hosted-checkout merchant with low volume and a responsive team | Proves the network, the providers and the reports with real money and no integration work |
| 2 | Hosted-checkout merchants, largest last | A link change each; the operations team learns the back office on real traffic |
| 3 | API merchants with their own developers | Sandbox tests, then keys; each switches when its tests pass |
| 4 | Merchants with subscriptions and stored cards | Re-tokenisation on the first payment; the acquirers that allow it go first |
| 5 | The merchant with the custom flow nobody remembers | Last, with time to find out what the custom flow was |
The parallel run
Both platforms run side by side. Merchants move one at a time, starting with the one whose team answers fastest, and the old platform keeps serving the rest. Nothing is switched off until the last merchant has settled a full cycle on the new one. During the run the operations team watches both platforms from the first day: approval rates per terminal on the new one against the old baseline, the callbacks and webhooks of each migrated merchant in the trace, and the settlement of the first cycle against the merchant’s own figures.
The day of a switch
- The merchant’s tests passed in the sandbox the day before; the production keys are issued.
- The merchant switches its link or its keys at a quiet hour; the first payments are watched in the trace by the PSP’s support and the merchant’s developer together.
- The webhooks of the first payments are checked against the merchant’s system; a mismatch is fixed before the next payment, not after a hundred.
- The old platform keeps the merchant’s old payments for refunds; new refunds go through the new one.
- The merchant’s finance team gets the first day’s report and reconciles it against its own records.
What goes wrong, and the fix
- A webhook the merchant did not expect: an event the old platform never sent. The merchant’s handler ignores the events it does not know until it is ready for them.
- A stored card an acquirer will not accept on a token from elsewhere: the payer is asked once, and the vault then holds the card for every acquirer.
- A report with different column names: the finance team maps them once; the export settings keep the mapping.
- A routing rule that behaves differently: the trace shows the branch taken; the rule is corrected in the builder and activated as a new version, with the previous one kept.
- A provider account that works in the sandbox and not in production: credentials and allowed IP addresses are the usual cause; the terminal’s test payment finds it before a merchant does.
History
Payment history is imported for reports and disputes; it does not have to be migrated into the live flow. Journals on Tranzify start with the first migrated payment and are kept five years. The import carries the payments, refunds and chargebacks with their references, amounts, dates and statuses, so the merchants’ cabinets show their history and a dispute about an old payment is answered from the new back office.
After the last merchant
The old platform is switched off after the last settlement from it is closed and the last refund period of its payments has passed; its export is kept as an archive. The routing rules are reviewed once more against a month of numbers on the new platform; the recovery and cost figures become the new baseline. The migration page describes the path from the PSP’s point of view, and the solutions page for PSPs what the platform gives after the move.