Own your payment stack

The card vault is not in your shop

Here is the one idea the whole of this series rests on. When a customer saves a card in your shop, your shop does not keep the card number. It keeps a token, a meaningless stand in reference, while the real card number sits in a secured store at your payment processor. The card industry has a name for that store. In the PCI Security Standards Council's own guidance a token replaces the primary account number with a surrogate value, the token can be stored in lieu of the real number, and the real numbers live in what the Council calls a card data vault.¹

Read that twice, because almost every painful payment migration I have seen comes from not understanding it. The money engine, the vault, the saved cards, the subscription schedules: they are at the processor. Your shop holds references to them. So the question that decides whether you are ever trapped is not which shop software you run. It is who owns the processor account that the vault belongs to.

If the account is yours, the vault is reachable through an account you control, and you can point any storefront, framework or platform at it. If a platform owns the account and rents you payments as a bundled feature, the vault is reachable only through that platform, and the day you leave, the references in your shop point at a door you no longer have a key to. This article is the map for staying in the first world. It is the positive mirror of my migration series, which is about rescuing a shop that is already stuck. This one is about never needing rescue.

Who owns the account decides portability

Start from what a processor will actually let you do, because that is the test. Stripe, to take a processor that publishes its process in detail, lets you migrate your customers and their saved cards away from a previous processor and onto Stripe, with the old processor sending the encrypted card data directly to Stripe while you keep charging existing customers on the old account until the new one is ready.² The reverse is the part that matters most for ownership. Stripe states plainly that you can export your data to any PCI compliant processor at a later date, as long as the receiving processor provides a valid PCI attestation and a public encryption key.²

That single sentence is what ownership buys. Because the vault is at the processor and the account is yours, the cards can move processor to processor, directly and encrypted, without you ever touching a card number and without your customers re entering anything. One thing never moves, by rule: the card security code, which PCI DSS forbids anyone to store once a payment is authorised, and which you do not need to charge a saved card anyway.² Everything else that makes a repeat customer a repeat customer can travel.

Now hold that against the alternative. If you do not own the account, none of this is available to you, because the export is a processor to processor transfer and you are not the party that holds either processor relationship. The portability is real, but it belongs to whoever owns the account.

The same engine, without the keys

The sharpest version of this is a product most shop owners think of as the easy default: a platform's own bundled payments. Take Shopify Payments as the archetype, and be precise, because the detail is the whole point. Shopify's own processor list names the processors behind Shopify Payments, and in market after market they are Stripe entities, with the global entry naming an affiliate of Stripe that applies based on your location.³ So underneath, a Shopify Payments merchant is running on the same processing engine that an independent Stripe merchant runs on.

The difference is not the engine. It is the keys. With Shopify Payments the processor relationship is arranged by the platform, on terms the platform sets, and Shopify is explicit that it is not itself a party to those processor terms and is not liable to you under them.⁴ You get the engine without holding the account that the vault answers to. There is no processor to processor export you can initiate, because you are not the processor's direct customer in the way an owned account makes you. When you leave the platform, the saved cards do not come with you as a clean encrypted transfer. That is exactly the trap I describe in the hidden dangers of switching payment gateways, and it is a large part of what makes moving away from Shopify harder than moving the catalogue and the theme. The same engine, without the keys, is worth less than it looks on the day you want to go.

I want to be fair here, because this is an architectural argument and not a complaint about one company. A bundled payments product is genuinely convenient. It is fast to switch on, the reconciliation is tidy, and for a shop that will never change platform it may be the right call. I am simply naming the price, which is paid later and quietly: you are renting the processor relationship, and rented relationships end on the landlord's terms.

The four things that travel when the account is yours

When the account is yours, four different things become portable, and each one has its own spoke in this series because each has its own mechanics worth understanding.

The first is the saved cards themselves, the tokens and the vault behind them. How a token stands in for a card, why it is worthless to a thief, and why that is what lets cards move at all, is the subject of how card tokenisation works.

The second is the act of moving. The encrypted processor to processor transfer, the mapping file that relinks every saved card to its new reference, the ramp that avoids a wall of declines: that is payments that move with you.

The third is the hardest, and the one bundled products hold onto most tightly: the recurring agreements. A subscription is not just a saved card, it is a schedule and a mandate, and whether you own that is the difference between a business you can carry and one you have to rebuild. That is subscriptions you actually own.

The fourth is reach. One owned processor account can sit behind several storefronts at once, so a second brand or a replatform does not mean a second merchant relationship, a second reserve and a second round of underwriting. That is one payment account across many stores.

Read as a set, they describe a payment stack you can reshape freely because the one irreplaceable asset, the vault full of customer relationships, is anchored to an account with your name on it.

The honest tradeoffs, because owning is not free

Owning the account is worth it, and I would be a poor adviser if I pretended it were effortless or costless. Here is the honest ledger.

Processor fees are a real, recurring cost, and they are not hidden. Stripe's published United Kingdom pricing, as it stands, is 1.5% plus 20p for a standard UK card, 2.5% plus 20p for European Economic Area cards and 3.15% plus 20p for the rest, charged per successful transaction.⁵ A bundled platform product charges its own rate, sometimes lower on paper, sometimes higher, and the point is not that one always wins. The point is that with an owned account you can see the rate, negotiate it as you grow, and change processor if a better one appears, because the account is yours to move.

Strong Customer Authentication is the second item. Under PSD2, customer initiated online card payments to European cardholders generally need two factor authentication, in practice 3D Secure, and banks may decline payments that do not follow it.⁶ This applies to you whoever holds the account, bundled or owned, so it is not a reason to prefer renting. It is a reason to build the checkout properly. The useful nuance is that a correctly saved card charged while the customer is away, a merchant initiated transaction, can qualify for an exemption, though Stripe is careful to say exemptions are never guaranteed and the bank can still ask.⁶

Third, owning the account means you hold the merchant relationship, and that includes the parts nobody enjoys. Disputes land on your account, and the processor pulls the disputed amount and a fee straight from your balance while you gather evidence.⁷ You carry a share of PCI compliance too. The good news, and it is genuinely good, is that if you build the checkout so raw card numbers go straight from the customer to the processor and never touch your servers, you sit on the lightest self assessment, SAQ A, which is a modest yearly form rather than an audit. I set out exactly how that works in PCI DSS explained. Owning the account does not drag you into a heavy compliance regime. A careless checkout design does.

Fourth, a single processor is a single point you must plan around. If your one account is suspended, held for review or simply has an outage, your takings stop. The answer is not to avoid owning, it is to design for it: a second processor configured and dormant, a graceful fallback at the checkout, and the knowledge that because your cards are portable you are never hostage to one provider's bad week. A shop that owns its account can add a backup processor. A shop renting bundled payments cannot.

Put plainly: you take on fees, authentication work, disputes, a light compliance duty and the responsibility to plan for failure. In return you keep the one thing that is genuinely hard to replace. I think that trade is right for almost any business that intends to still be trading, and changing, in five years. I say so because it is my honest view, not because I sell a processor. I build the custom shop and wire it to an account the client owns. I take no processor commission and I do not claim any one processor is simply best.

Why this ladders to ownership, and to growth

There is a reason this sits under the same roof as owning your data. You cannot grow a business on evidence if the evidence, and the customers behind it, are not yours to act on. A saved card is not only a convenience. It is a standing relationship, permission to charge again, a signal of loyalty, the raw material of a win back campaign and a lifetime value calculation. When those relationships live in an account someone else controls, your growth is on loan. When they live in an account you own, every one of them is an asset you can measure, keep and build on. That is the same argument I make about your records and your analytics in who actually owns your business data, applied to the most valuable records a shop has: the ones that let it take money.

This is also why I treat the payment choice as a foundational decision rather than a plumbing detail, in the same breath as the platform decision itself, which I lay out in migrating your online shop. The storefront is replaceable. The customer who trusts you enough to leave a card on file is not.

A worked example: a Brighton brand that chose the account over the bundle

Let me make this concrete with an invented business, because concrete is where the argument either holds or falls apart. Marram and Co sells coastal homeware and outdoor kit at marramandco.example, run from a unit in Brighton by a founder called Priya. She is launching properly for the first time, expecting a few thousand orders a month and, importantly, a subscription box that she hopes becomes the core of the business. Every figure below is invented to show the mechanism.

Priya has two roads. Road one is a hosted platform with bundled payments switched on: live in an afternoon, nothing to think about. Road two is the one I build: a custom shop on Solidus, the open source Rails ecommerce framework, wired to a processor account that Priya opens in her own company's name. Road two costs a little more to stand up and asks her to complete a short yearly SAQ A form. She chooses road two, and here is what it buys her over the following two years.

In year one she is glad of the ordinary things. The fee is a line she can read and, once her volume grows, renegotiate. When a customer disputes a charge, it is her account and her evidence, and she answers it in her own dashboard.⁷ She configures a second processor, dormant, so that if her main one has a bad day the checkout fails over instead of failing. None of this would be available to her on the bundle.

Then the useful moments arrive. Eighteen months in, Priya outgrows her first storefront and wants a faster, more custom build. Because her card vault is at her processor and the account is hers, the replatform touches no payment data at all: the new storefront points at the same account, the saved cards and the subscription schedules keep running, and no customer re enters a card. On the bundle this same move would have meant a processor to processor export she could not initiate and a wall of customers asked to pay again, the exact loss I cost out in the hidden dangers of switching payment gateways.

Soon after, she launches a second brand, a gift label, on its own domain. One owned account sits behind both shops, so there is no second underwriting, no second reserve, and her reporting rolls up across the two. Later still, a new processor offers her a materially better rate for her card mix. Because her cards are portable by design, she can run the encrypted export and move, using the mapping file to relink every saved card, ramping the volume so the new account does not look like a stranger to the banks on day one.²

The tradeoffs were real throughout. Priya paid processor fees every month. She built her checkout for 3D Secure so European customers authenticate cleanly.⁶ She answered her own disputes and kept her SAQ A current. And in exchange she replatformed once, launched a second shop and changed processor once, and across all three her customers and their saved cards simply carried on. The bundle would have made her first afternoon easier and every move after it harder.

The questions I ask before wiring a single key

Most of this is decided at the start, in whose name the account is opened and how the checkout is built, long before anyone says the word migration. So these are the questions I put to a processor, and want answered in writing, before I wire anything:

• Is the merchant account in the client's own company name, under the client's direct relationship with the processor, and not a sub arrangement that a platform controls?
• Does the processor publish a card export process to any PCI compliant provider, how long does it take, and is there a fee?
• Does the checkout keep raw card numbers off the client's own servers, so the business sits on SAQ A?
• Does the processor support 3D Secure cleanly, and carry the proof of earlier authentication so saved cards are not challenged again after a move?
• Can one account sit behind more than one storefront, and can a second processor be configured as a backup?

A processor you can leave, on an account you own, is worth more than a slightly lower headline rate on an account you cannot. A provider you cannot leave can set the rate later. Build on the account you own, keep the vault portable, and the storefront, the framework and even the processor become things you can change without ever asking a customer for their card again.

If you are about to choose how your shop takes money, or you suspect your payments are quietly tied to a platform you might one day want to leave, bring it to the free workshop and we will map your payment stack together, owner's name on the account and all. The first two weeks of the work are on me.

Footnotes

1. PCI Security Standards Council, Information Supplement: Tokenization Product Security Guidelines (a token replaces the PAN with a surrogate value and can be stored in lieu of the PAN, and the real card numbers are held in a card data vault), April 2015, https://listings.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf ↩

2. Stripe, Import payment data to Stripe (migrate saved payment details from a previous processor, keep charging existing customers on the old account during the move, the security code cannot be imported, and you can export your data to any PCI compliant processor at a later date), Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-import ↩ ↩² ↩³ ↩⁴

3. Shopify, Payment Processors for Shopify Payments (the processor list naming Stripe entities per country and an affiliate of Stripe for all regions), Shopify Legal, 2026, https://www.shopify.com/legal/processor-list ↩

4. Shopify, Shopify Payments Terms of Service, United States (Shopify is not a party to any of the Payment Processor Terms and is not liable to you in respect thereof), Shopify Legal, 2026, https://www.shopify.com/legal/terms-payments-us ↩

5. Stripe, Pricing (United Kingdom: 1.5% plus 20p for standard UK cards, 2.5% plus 20p for European Economic Area cards, 3.15% plus 20p for international cards, per successful transaction), stripe.com, accessed 14 November 2026, https://stripe.com/gb/pricing ↩

6. Stripe, Strong Customer Authentication readiness (SCA under PSD2 applies to card payments for customers in the European Economic Area and requires 3D Secure, and merchant initiated transactions with a saved card can qualify for an exemption, which is never guaranteed), Stripe documentation, 2026, https://docs.stripe.com/strong-customer-authentication ↩ ↩² ↩³

7. Stripe, How disputes work (when a payment is disputed, the disputed amount and a fee are withdrawn from your account balance while you submit evidence), Stripe documentation, 2026, https://docs.stripe.com/disputes/how-disputes-work ↩ ↩²