When a store moves to a new platform, payments do not come with it. Each payment provider is a separate connection to the old system, and every one you want to keep has to be rebuilt against the new one. So the first real question in a replatform is which ones to keep, and it is a money question wearing technical clothes.
This store had four providers installed, and a fifth that looked switched off. Rebuilding four was not in anybody’s budget.
How the question was being answered
The way it usually is. Around a table, from memory.
One person was confident about the newest provider, because it was the one recent work had gone into and the one they had touched most recently. Somebody else named a different one. Both answers were reasonable. Neither person had looked, and there was no bad faith anywhere in the room — this is simply what happens when the question sounds like a matter of general knowledge rather than a matter of record.
The record
Three years of orders were sitting in the store’s own database. More than 160,000 of them.
The query is not clever: group the completed orders by payment method, count them, add up the totals, then do the same for the subscriptions that are still active. The only genuinely fiddly part was working out which of the store’s several order tables was the authoritative one, because a store that has been running for years accumulates more than one.
It took an afternoon. The result was not close.
One provider carried 94% of all revenue and 98% of active subscriptions. The newest one — the one with the recent work in it, the one people named first — carried about two per cent.
Had the rebuild been scoped from memory, the business would have launched a new store through which 94% of its money could not move.
There was a second finding nobody expected: several thousand orders had no payment method recorded at all, with an average value of a few cents. Test transactions, abandoned attempts, and a plugin that had briefly written the wrong field, all mixed into the same table. Not a crisis, but exactly the kind of thing that quietly corrupts a report, and worth knowing before anyone builds a dashboard on top of it.
The expensive part the arithmetic surfaced
The rebuild order was the obvious consequence. The costly one came second.
That dominant provider did not only process payments. It held the stored card details for every recurring customer. When a subscription renews, the store does not have the card — it holds a reference issued by the provider that stands in for the card on file.
Those references belong to the old connection. Rebuild the payment integration without carrying them across and every recurring customer’s next renewal fails. There is no recovery except to email a thousand-odd people and ask each of them to enter their card again, on a subscription product, which is the most reliable method ever devised for turning a renewal into a cancellation.
So the migration had to treat those references as first-class data to be moved and verified, not as a detail to be handled later. That requirement did not exist in anybody’s plan the week before. It came out of a query that took an afternoon.
What was built
The payment connection was written as a self-contained piece against the new platform’s own payment interface, so the rest of the system neither knows nor cares which provider sits behind it. The migration reads each customer’s stored references from the old database and writes them alongside the customer record in the new one, so a renewal after the move uses the same reference it would have used before.
The second provider was kept as well, as a smaller piece of work, because two per cent of revenue is still revenue and keeping it cost days rather than weeks. The other two were dropped. That is a decision the numbers made easy and that would otherwise have been an argument with no way to settle it.
All of it was built and validated against a full copy of the store in an isolated environment, where it works and where the counts reconcile.
What we would do differently
We ran the query in the third week. It should have been the first day.
The reason it was not is ordinary: the first week goes into understanding the code, because the code is the thing that feels frightening. But the code was not what decided the plan. The order history was. Two hours of arithmetic at the start would have shaped the estimate, the scope and the schedule, and the stored-card requirement — the single largest surprise in the project — would have been in the plan instead of bolted onto it.
The other lesson is about the word “installed”. We took the list of installed providers as the inventory. The real inventory is which providers are used, and a payment plugin can sit installed and enabled for years without processing a single order. Those are different questions and only one of them can be answered from the filesystem.
If you are about to replatform
Ask for one number before anything else: the share of revenue by payment method over the last two years. Whoever runs your store can produce it, and if the answer comes back as a guess, that is your first finding.
Then ask the follow-up most people miss: do we hold stored cards or subscriptions with that provider, and what happens to them when we move? If the answer is unclear, your migration has a hard requirement that nobody has costed yet.