Payments that move with you

The question that decides whether a replatform hurts

Most of the pain people expect when they rebuild a shop comes from one fear: that moving to a new storefront means moving everyone's saved cards, and that some customers will have to type their card in again. That fear is real when the payment account belongs to the platform. It mostly disappears when the payment account belongs to you.

So before I write a line of code, I ask one question. Whose name is on the merchant account that holds the card vault? If the answer is the client, a replatform is usually a quiet weekend. If the answer is the platform, leaving the platform is a vault to vault migration, which is the hard case I describe near the end.

This article is the payoff of owning your payment stack. I build the custom Solidus shop and wire it to a payment processor the client already owns. Because the vault sits at the processor and not inside the shop, the saved cards, the stored customers and the recurring agreements do not care which storefront points at them. Change the storefront, the framework or the whole platform, and the payment data stays exactly where it was.

Changing storefront and changing processor are two different jobs

The single most useful thing I can give you is the distinction between two moves that sound the same and are not.

The first move is changing your storefront or platform while keeping the same processor account. You rebuild the website, the checkout, the admin, the framework. The processor account underneath stays the same account, with the same saved cards and the same customer records. Nothing in the vault moves, because you point the new shop at the account that already holds it.

The second move is changing the processor itself. Here the card numbers genuinely have to travel from one company's vault to another's, encrypted, under strict rules. Stripe, for example, will only receive card data from another processor that holds a current PCI DSS Attestation of Compliance and an RSA key of at least 4,096 bits, and the export from your old processor can take anywhere from a few days to several months.¹ That is the job covered in migrating payment tokens and saved cards, and it is real work.

Owning your account is what lets you spend your replatforms in the first category and almost never the second. The storefront is the easy thing to change. The processor account is the thing you protect.

Why a storefront swap moves no card data

When a customer saves a card, your shop never stores the card number. The processor stores it and hands your shop a token, a reference that only that processor can turn back into a real card. The token lives against a customer record inside the processor account. If you want the mechanics, I lay them out in how card tokenisation works.

The consequence is the whole point of this series. Your storefront holds references, not cards. So when you replace the storefront, you are replacing the thing that holds references, while the thing that holds the actual cards never moves. The new shop reads the same customer identifiers, presents the same saved tokens at checkout, and charges them through the same account. No export, no import, no letter to customers, no card collected again.

This is why I keep the processor account owned by the client from day one, even on the first build. It is not a convenience for later. It is the architectural decision that makes every future rebuild a storefront swap instead of a processor migration.

Stripe's own account model reflects this. A Stripe account is tied to one legal entity, and that same account can sit behind multiple projects and websites run by that entity.² The website is not the account. The account is the account.

Worked example: Calderwell Cycles replatforms and nobody notices

Throughout I use one invented business. Calderwell Cycles sells bikes and parts from Leeds at calderwellcycles.example. Priya runs it. Nobody real, and every figure is made up so I can show each step.

Priya's shop sits on a hosted platform she has outgrown. She has 3,100 customers with a saved card, and 900 of them pay £14 a month for a service club that covers two workshop visits a year. Her Stripe account is in the name of her limited company. That last fact is the one that matters.

She asks me to rebuild on Solidus. Here is what moves in the card vault during that rebuild: nothing. I build the new shop, connect it to her existing Stripe account with her existing keys, and import her customer list by the Stripe customer identifiers she already has. On launch night, a returning customer logs in, sees the same card ending in the same four digits, and checks out. The service club renews on its normal date, from the same account, with the same token. Not one of the 3,100 cards is collected again, because not one of them went anywhere.

What I do move is ordinary shop data: products, prices, orders, customer names and addresses, the mapping between each customer and their Stripe customer identifier. That is a database job, not a payments job. The payments simply keep pointing at the account that already holds them.

Network tokens and the account updater keep saved cards alive

There is a second reason an owned account ages well, and it has nothing to do with replatforming. Cards expire, get lost and get reissued all the time. On a well run account, most of those saved cards keep working without anyone touching them.

Two mechanisms do this. The first is the card account updater: the processor works with the card networks to refresh a saved card's details when the issuing bank replaces the physical card. Stripe describes saved payment details that "can continue to work even if the issuing bank replaces the physical card", and sends a payment_method.automatically_updated event when a card is refreshed this way. It is honest about the limits: updates depend on issuers participating, coverage varies by country, and "it isn't possible to identify cards that support automatic updates".³

The second is network tokens. Instead of storing a reference that only one processor understands, the networks issue a token that they themselves keep valid as the underlying card changes. This is not a Stripe idea and not a reason to pick one processor. Adyen describes the same thing in its own words: "card networks maintain network tokens to ensure tokens remain valid when the card details change", and when the processor manages the tokens for you, "the card details are automatically updated, and the token remains unchanged".⁴

For an owned account, the effect compounds. The vault stays put across a replatform, and its contents quietly stay current between replatforms. The saved cards are not a frozen export that decays. They are a living part of an account you control.

The contrast: platform managed payments bind the account to the platform

Now the other side, because the honest case for owning an account is clearest against the case where you do not.

Platform managed payments bundle the storefront, the gateway and the merchant account into one product. Shopify Payments is the archetype. Shopify presents it, in its own words, as the option that removes the hassle of setting up a payment provider or merchant account of your own, switched on automatically when you create the store.⁵ That convenience is exactly the trap. If there is no separate merchant account of your own, there is nothing of yours to point a new storefront at. The account is part of the platform.

So when you leave that kind of platform, leaving is changing the processor. You are forced into the hard vault to vault case, or worse, into collecting cards again. That is precisely what makes migrating away from Shopify and migrating away from Square Online harder than they should be: the payments were never yours to carry across. The same storefront swap that costs Priya nothing becomes a processor migration for a shop on platform managed payments, with everything that implies.

This is the real lock in. Not the theme, not the apps, not the data export you can usually get. The payment account you cannot take with you.

What a clean cutover looks like when you own the account

When the account is yours, a replatform cutover is mostly about keeping identifiers stable, not about moving money. My checklist is short.

Keep the customer identifiers stable. Every customer in the new shop must carry the same processor customer identifier as before, so the saved tokens resolve to the right person. I treat that mapping as the one thing that must be perfect before launch.

Keep the webhooks pointed at one place. The processor sends messages when a payment succeeds, a card updates or a dispute opens. On cutover I move the webhook endpoint to the new shop and confirm it is receiving, so nothing goes silently unheard. Because the account is the same, there is no second processor to reconcile, only a new address for the same stream of events.

Keep charges idempotent. Where my code charges a saved card, it sends an idempotency key, so a retry during the switch cannot charge a customer twice for one order. This matters most in the hours around cutover, when a nervous operator is tempted to click again.

The shop software helps here too. In Solidus, the open source Rails shop framework I build on, the shop talks to a payment method object, not directly to a gateway, and a refund is always processed through the original payment's method.⁶ A payment method also carries separate switches for being active, available to customers and available to the admin.⁷ That lets the new processor go live for shoppers at checkout while the old one, if there is one in play during a processor change, stays available to the admin for refunds on old orders, without customers ever seeing it.

That is the entire payments side of an owned account replatform. Point the new shop at the same account, carry the identifiers across intact, move the webhook, keep charges idempotent. The vault never opens.

Worked example: Priya's cutover night

Priya's cutover is an evening, not a season. I load the customer mapping so every record carries its existing Stripe customer identifier. I switch the webhook endpoint to the Solidus shop and watch two test events arrive. I put the old storefront into maintenance, point the domain at the new shop, and run one real £1 charge against a saved test card to confirm the token resolves. The service club's next renewal batch runs two days later on its usual date, through the same account, and the dashboard shows the same number of active members as the week before. Her accountant notices nothing unusual, because the money kept arriving in the same account on the same schedule.

The hard case: when you genuinely change processor

Owning your account does not abolish the hard case. It just makes it rare and deliberate, something you choose for a reason rather than something a replatform forces on you. Sometimes you do change processor: a better rate at your volume, a local method the old one cannot offer, a processor leaving your market. When that day comes, here is what it actually costs.

The card numbers move processor to processor, encrypted, and you never see them. The sending processor must hold a current PCI DSS Attestation of Compliance and provide an RSA key of at least 4,096 bits.¹ You request the export from the old processor first, because it is the slow step and the one you do not control: Stripe warns it can take from a few days to several months, while the import itself usually completes within about ten business days of good data arriving.¹ The security code never travels, because PCI DSS does not allow anyone to keep it after a payment is authorised, and you do not need it to charge a saved card.¹

When the import finishes you get a mapping file: each old customer and card identifier next to its new one, which your shop must apply before the first charge on the new processor.¹ Then the new account behaves like a stranger to the banks at first. It has a new merchant identifier the card issuers have not seen charge these cards, so some decline early. Stripe recommends ramping up rather than switching everything at once, sending your strongest traffic first, one off and customer initiated payments before recurring ones, domestic before international.¹ The full shape of this job, and the subscription side of it, lives in migrating payment tokens and saved cards and in the hidden dangers of switching payment gateways.

The point is not that a processor change is easy. It is that owning your account turns it into a decision rather than a tax on every rebuild. And a processor to processor move, run between two accounts you control, is still a cleaner job than a platform to platform move where the account was never yours.

Worked example: Calderwell changes processor two years later

Two years on, Priya is offered a materially better rate at her new volume and decides to move from Stripe to another processor. This time the vault really does have to move. She asks Stripe for the export in early September; the file is ready in late October, seven weeks later, because the export timeline is the slow part.¹ The new processor imports the cards within its stated window, returns a mapping file, and Priya's shop updates every customer record to the new references.¹

She then ramps. New checkouts and one off orders go to the new processor first, domestic cards before international, and only once declines settle does she move the 900 service club renewals in batches.¹ Some renewals trigger an authentication prompt on the new account, for reasons I cover next. The whole thing takes about two months of care, against the single evening her storefront swap took. That gap, two months versus one evening, is the entire argument for owning the account. One of these jobs she chose. The other she avoided by owning the right thing from the start.

The honest limits

I would be selling something if I pretended owning your account removes every cost. It does not, and the brand here is honesty about tradeoffs.

You carry the merchant relationship. Owning the account means you own the disputes, the payouts, the reserves and your share of PCI compliance. That share is usually the lightest self assessment, SAQ A, precisely because a tokenised checkout keeps card numbers off your servers, but it is still yours to attest, as I explain in PCI DSS explained. A platform that hides all of that is selling convenience for the price of control.

Processor fees are a real cost. Every processor takes a cut of each payment. I am not a reseller for any of them, I take no kickback, and I will not tell you one is simply best. The right processor depends on your mix of cards, countries and methods, and the fee is a genuine line in your budget, not a detail.

A single processor is a single point you plan around. If your whole business runs through one account and that account has a bad day, so do you. Owning the account is what gives you the option to add or move processors on your terms, but the discipline of monitoring and a fallback plan is still on you.

Strong Customer Authentication can trigger again on changed arrangements. Under PSD2, most customer initiated online card payments in Europe and the UK need Strong Customer Authentication, two of three factors: something the customer knows, has or is.⁸ Recurring charges you initiate can be exempt as merchant initiated transactions, but only against a mandate the customer agreed, and the exemption is never guaranteed. Stripe states plainly that "exemptions aren't guaranteed, and off session payments might still require authentication by the bank".⁹ A storefront swap on the same account does not disturb those agreements. A processor change can, because the proof of prior authentication sits with the old processor and may not carry perfectly, which is one more reason the processor change is the case to avoid when you can.

Local methods are not always one to one. Card tokens are portable in the ways described here. Some local payment methods and bank mandates have their own rules and timelines, and a given method on one processor is not guaranteed identical on another. Owning your account helps, but it does not flatten every scheme's own process.

What I ask before I build anything

Because the owned account is what makes the rest easy, I settle it at the start, in writing, before the first line of code:

Is the merchant account in the client's legal name, with the client as the account owner, not mine and not a platform's?
Do the saved cards and customers live in that account, reachable by stable customer identifiers I can carry into any future storefront?
Does the processor publish an export process to another PCI DSS compliant processor, so the client could leave it too? Stripe documents exactly this, exporting to any PCI compliant processor that provides a valid attestation and RSA key.¹
Are network tokens and the account updater switched on, so saved cards stay current between rebuilds?³⁴

A processor you could leave is worth more than a slightly lower rate, because a processor you cannot leave can set the rate later. The owned account is the quiet thing that keeps the master promise true: your data and your customers stay yours to act on, through every rebuild.

The replatform is not the dangerous part. Not owning the account underneath it is.