How card tokenisation actually works

One sentence, and then the detail

Here is how a saved card works, in one sentence. The real card number never lives in your shop. It lives in a vault at your payment processor, and your shop holds only a token, a meaningless reference that the processor can swap back for the card when you ask it to charge. Everything else in this article is an unpacking of that sentence, because almost every good thing about owning your payment stack falls out of it: your light duty under the card security rules, your freedom to change storefront without migrating card data, and the plain fact that a stolen copy of your database is worth nothing to a thief.

I build custom shops on Solidus, the open source Rails ecommerce framework, and I wire each one to a payment processor the client owns. So I spend a lot of time thinking about where the card number goes and, more importantly, where it does not go. This is the readable explanation of the mechanism, so you can see for yourself why owning the processor account is what gives you portability, and why it keeps your compliance burden small. It is the companion to my piece on how to actually move saved cards between providers in a migration of payment tokens and saved cards; here I stay on how it works and why owning it is the right design, and I leave the move mechanics there. The businesses in the examples are invented. Every outside fact carries a footnote to a primary source.

The card number is the dangerous part

The long number on the front of a card is the primary account number, almost always shortened to PAN. The card industry's security standard, PCI DSS, treats it as the centre of a category it calls account data, alongside the cardholder name, the expiry date and the service code, and separately the more dangerous sensitive authentication data such as the full magnetic stripe content and the three or four digit verification code.¹ The rules on the PAN are strict: you may store it only if you protect it to the standard's satisfaction, and you must never retain the verification code once a payment has been authorised.¹

That is the whole motivation for tokenisation. The PAN is the thing worth stealing, the thing you are obliged to protect, and the thing that drags paperwork, encryption, scanning and audits behind it. So the most useful move available to a shop is simple: arrange never to hold it at all. A field your systems never touch is a field you never have to protect, log, encrypt or prove you protected. Tokenisation is the mechanism that lets a shop charge a returning customer again and again while holding none of the dangerous data.

What a token is, and why it belongs to one vault

When a customer saves a card, your shop does not receive the card number. The processor receives it, stores it in its vault, and hands your shop back a token in its place. In practice what you store is a short, opaque reference plus a little non sensitive detail you are allowed to keep for display, such as the card type, the last four digits and the expiry date, so the customer sees "Visa ending 4242" at the next checkout.² To take a payment later, your shop sends the token to the processor, and the processor, which alone can read its own vault, turns the token back into the card and authorises the charge.

Two things about that token matter for the rest of this article. First, it is deliberately useless on its own. If someone copied every token in your database they would hold a list of references that no one but your processor can redeem, and your processor will only redeem them for your account. There is no card number to lift. Second, a token is specific to the vault that issued it. A token minted by one processor means nothing to another, because only the issuing vault holds the mapping back to the PAN. People sometimes draw a distinction between a shallow gateway token, which is really just a reference to a card the gateway is holding for you, and the deeper vault behind it, but the principle is the same at every depth: the sensitive data sits in the processor's vault, and the token is a claim cheque against it. That is exactly why moving providers is a real operation rather than a copy and paste, and it is the subject of the migration article I linked above. Here the point is the happy one: because the vault is the processor's and the token lives in your account at that processor, the token keeps working for as long as that account is yours.

How the number reaches the vault without touching my server

If the shop never receives the card number, how does the number get from the customer's keyboard into the processor's vault? The answer is the single most important piece of checkout engineering, and it is why a well built shop carries almost none of the PCI burden.

The card fields on the checkout page do not belong to the shop. They are served by the processor, usually as a small embedded frame, sometimes called hosted fields or, in one well known processor's naming, a payment element.³ The customer types the card number into a box that looks like part of your page but is actually a window onto the processor's own domain. The number travels straight from the browser to the processor and is never sent to the shop's server at all. What comes back to the shop is the token. The processor, which runs this flow, puts the point plainly: these integrations let you "securely collect and transmit payment information directly to Stripe without it passing through your servers, reducing your PCI obligations."²

This is what keeps a shop on the lightest self assessment under PCI DSS, the one known as SAQ A, which is available to an online merchant who has fully outsourced the handling of card data to validated third parties so that its own systems never store, process or transmit it.⁴ I explain the whole landscape of levels and questionnaires in PCI DSS explained, but the headline is that this one design decision, taken before a line of checkout code is written, is what separates a shop that fills in the shortest questionnaire from one that pulls hundreds of controls onto itself. There is a modern caveat worth knowing: since 1 April 2025 even a merchant using an embedded provider frame has to confirm that the scripts on its payment page cannot be used to attack the payment, so keeping the checkout page clean and its scripts managed now matters even in the light case.⁵ The direction is unchanged: keep the card away from your own code, and keep the payment page tidy.

Network tokens: the card schemes have their own

So far the token I have described is issued by a processor. There is a second, deeper kind, issued by the card networks themselves. Visa and Mastercard each run a service that replaces the card number with a network token, a scheme level credential that stands in for the PAN and can be stored for a card on file arrangement.⁶⁷ It is worth understanding how these differ from a processor token, because the difference is where real money shows up.

A processor token points into one processor's vault. A network token points into the scheme's own tokenisation service, which sits closer to the card issuer. That proximity buys two things. The first is continuity. When a customer's card is reissued, lost, replaced or simply expires, a plain stored PAN goes stale and the next charge is declined. A network token is kept current by the scheme instead. Visa describes credentials being "automatically refreshed across channels to help maximise revenue from returning customers," and Mastercard describes "issuer life cycle management notifications" flowing through its card on file tokenisation so the stored credential stays valid.⁶⁷ A processor summarises the effect from the merchant's side: network tokens "serve as more secure substitutes for card numbers" and let you "process payments with the most up to date credentials, even if the underlying card data has changed, improving success rates."⁸

The second thing is higher authorisation. Because a network token carries scheme and issuer trust that a raw keyed in number does not, issuers approve more of them. Visa reports an "8% uplift in authorisation rates across Europe when compared to ecommerce PAN transactions," and that network tokenisation can "reduce fraud by an average of 28%," with "payment data never touches your own or your merchants' internal systems."⁶ Mastercard likewise ties its card on file tokenisation to better approval rates.⁷ Those are the schemes' own figures, measured their own way, so treat them as vendor reported and directionally true rather than a promise for your exact shop.

Now the honest part, because this is architecture and not a sales pitch. Network tokens are not free of trade offs. Keeping tokens current through the schemes can carry its own fees, for example a Visa credential updater charge or a Mastercard continuity fee, which a processor will pass through and which eat into the benefit.⁸ The gain also varies by market, card mix and issuer behaviour. Network tokens are a strong default for a card on file shop, but they are a tool with a cost, not magic.

Why owning the account is the whole point

Here is where the mechanism meets the positioning, and it is the reason this series exists. The vault belongs to the processor. The token belongs to the account at that processor. So the question that decides everything is a question of whose account it is.

If the processor account is yours, in your company's name, with your own contract and your own keys, then the tokens are yours. You can rebuild the storefront, move from one framework to another, go headless, put a mobile app in front of the same processor, or replace the shop entirely, and every saved card keeps working, because none of that touches the vault or the account the tokens live in. The card data does not migrate because it never moves: it was always at the processor, and the processor is still yours. That is the mechanical reason a shop built this way is portable, and I follow the point through in payments that move with you and, for the recurring side, in subscriptions you actually own.

If instead the account is the platform's, the tokens are the platform's. A platform managed payment product binds the storefront, the gateway and the vault together under the platform's own merchant relationship, so the saved cards are held in an account you do not control. Leaving the platform then means leaving the vault, which is exactly the migration problem the first half of this series is written to help you avoid, and which I treat concretely in migrating away from a hosted platform. The engine underneath a platform's payments may even be a capable processor, but without the account in your name you get the engine without the ownership, and ownership is the part that makes your customers portable. This is the whole argument of the series in a single mechanism: own the account, and the tokens are an asset you keep; rent it, and they are a hostage.

A word on strong customer authentication

One more piece belongs in an honest account, because it shapes what your European customers see. Under the EU's second Payment Services Directive, most electronic card payments need Strong Customer Authentication, usually shortened to SCA: the shopper proves who they are with two of three independent elements, something they know, something they have and something they are, and for a remote payment the authentication is dynamically linked to that specific amount and payee.⁹¹⁰ In daily life this is the banking app prompt or the one time code during checkout.

Tokenisation and SCA meet at the moment a card is first saved. Setting up a card on file arrangement is a customer facing action, so it generally needs SCA at that point, which is why saving a card for the first time can trigger the app prompt. Afterwards, a payment the customer does not actively trigger, a genuine merchant initiated charge under the agreement they already authorised, falls outside the routine SCA requirement, which is how a later reorder or a renewal can run without the shopper authenticating again.¹⁰ The practical implication for a European shop is small but real: expect the authentication step when the card is captured, design the save so the customer is present and ready for it, and understand that the proof of that authentication is part of what a well built integration carries forward. The newer PSD3 and Payment Services Regulation were still working through the EU legislative process in 2026 and refine rather than overturn this, so the position above is the current one to build against.

A worked example: one card through a Leeds shop

Calder and Finch is an invented homeware and coffee business in Leeds, trading at calderandfinch.example, with a Solidus shop wired to a processor the company owns. Follow one card through it.

A customer, buying a grinder and a bag of beans, reaches the payment step. The card fields she sees are served inside the processor's embedded frame, so when she types her card number it goes from her browser straight to the processor and never reaches Calder and Finch's servers.² Because she ticked "save this card for next time", the processor vaults the card, and, since this is the EU, her bank shows her an app prompt to authenticate the new arrangement.¹⁰ She approves it. The processor returns a token to the shop, and Calder and Finch stores that token against her customer record together with "Visa ending 4242" and the expiry month, the only card detail it is allowed to keep for display.² Nowhere in Calder and Finch's database is there a card number.

Three months later she comes back for more beans and taps reorder. The shop sends the stored token to the processor, the processor redeems it against its vault and charges the card, and because this is a merchant initiated charge under the arrangement she already authorised, she is not asked to authenticate again.¹⁰ One tap, no card fields, no SCA prompt, and still no PAN anywhere in the shop.

In between, her bank reissued her card after a fraud scare and changed the number. Had Calder and Finch been leaning on a plain stored card, that reorder would have declined on a dead number. Because the processor had enrolled the card as a network token, the scheme kept the credential current and the charge went through on the new card details without anyone lifting a finger.⁶⁸ A year on, Calder and Finch rebuilds its storefront on a new front end and later adds a mobile app, both pointing at the same processor account. Every saved card, including this one, keeps working through all of it, because the vault and the account never moved. At no point did a card number touch the shop, and at no point did changing the shop touch a card.

That example is the entire thesis in miniature. The sensitive data went to the vault and stayed there. The shop held a worthless token. The scheme kept the credential fresh. And because the account was the company's own, every change the business made to its software left its customers' saved cards untouched.

The honest position

I will not pretend tokenisation and an owned processor account are free of cost. Running your own account means you carry the merchant relationship, the disputes and your share of PCI DSS, which for a hosted, tokenised shop is the light SAQ A but is still your responsibility rather than a platform's.⁴ A processor charges fees, and those are a real line in your costs. European cards bring SCA, which adds a step your customers sometimes have to complete.⁹ Network tokens can carry their own scheme fees that trim their benefit.⁸ And a single processor is a single point you have to plan around, with a sober answer to the question of what you do if it ever fails you. None of that is hidden, and none of it is a reason not to own your stack. It is the price of owning it, and it is a good deal, because the alternative is to hold none of these responsibilities and none of the control either, and to discover the cost only on the day you try to leave.

What I am not is a reseller of any one processor, and I take no kickback from any of them. The argument here is about where the card number lives and whose account the tokens sit in, not about a brand. Pick the processor that fits your market and your card mix, open the account in your own name, and build the checkout so the number never touches your code. The portability and the light compliance are consequences of that design, not of any logo.

What to do now

Work through these in order. Find out whose name your payment account is actually in today, because if it is the platform's, your saved cards are not portable no matter what else is true. Look at where the card number goes in your current checkout, and if any of it reaches your own servers, that is the first thing to change. If you take repeat payments, ask your processor whether it enrols cards as network tokens, because that is where the continuity and the higher approvals come from. And keep the honest trade offs in view, the fees, the SCA step, the single processor, so the decision is made with open eyes.

If you want to see exactly where the card data in your shop goes, whose account your tokens live in, and whether a small change would make your customers portable, book the free workshop and we will map it together, and the first two weeks of the work are on me.

PCI Security Standards Council, Payment Card Industry Data Security Standard: Requirements and Testing Procedures, version 4.0.1, June 2024, sections on account data, the primary account number and the prohibition on storing sensitive authentication data after authorisation, available from the PCI SSC Document Library, accessed 14 November 2026, https://www.pcisecuritystandards.org/document_library/?category=pcidss ↩ ↩²
Stripe, Integration security guide (low risk integrations collect and transmit payment information directly to Stripe without it passing through your servers, and the non sensitive card details you may store), Stripe documentation, accessed 14 November 2026, https://docs.stripe.com/security/guide ↩ ↩² ↩³ ↩⁴
Stripe, The Payment Element (an embeddable UI component that collects card details in the front end), Stripe documentation, accessed 14 November 2026, https://docs.stripe.com/payments/payment-element ↩
PCI Security Standards Council, Self Assessment Questionnaire Instructions and Guidelines (SAQ A eligibility for merchants who fully outsource card data handling to validated third parties), available from the PCI SSC Document Library, accessed 14 November 2026, https://www.pcisecuritystandards.org/document_library/?category=saqs ↩ ↩²
PCI Security Standards Council, FAQ clarifies new SAQ A eligibility criteria for ecommerce merchants (the script protection criterion and the 1 April 2025 effective date), PCI Perspectives blog, accessed 14 November 2026, https://blog.pcisecuritystandards.org/faq-clarifies-new-saq-a-eligibility-criteria-for-e-commerce-merchants ↩
Visa, Token Management Service (network tokenisation: payment data never touches merchant systems, credentials automatically refreshed, an 8% uplift in authorisation rates across Europe versus ecommerce PAN transactions, and an average 28% reduction in fraud), Visa Acceptance Solutions, accessed 14 November 2026, https://www.visaacceptance.com/en-gb/solutions/payment-services/token-management-service.html ↩ ↩² ↩³ ↩⁴
Mastercard, Card on File Tokenization (replacing account PANs with tokens, issuer life cycle management notifications through card on file, and better approval rates), Mastercard Developers, accessed 14 November 2026, https://developer.mastercard.com/product/card-on-file-tokenization/ ↩ ↩² ↩³
Stripe, Payments optimization (network tokens are more secure substitutes for card numbers that process payments with the most up to date credentials even when the underlying card data has changed, and the scheme fees such as the Visa credential updater and the Mastercard continuity charge that can apply), Stripe documentation, accessed 14 November 2026, https://docs.stripe.com/payments/analytics/authorization-boost ↩ ↩² ↩³ ↩⁴
European Union, Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Article 97 requiring strong customer authentication for electronic payment transactions, EUR-Lex, accessed 14 November 2026, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32015L2366 ↩ ↩²
European Union, Commission Delegated Regulation (EU) 2018/389 supplementing PSD2 with regulatory technical standards for strong customer authentication (two or more elements from knowledge, possession and inherence, the dynamic linking of a remote payment to amount and payee, and the exemptions), EUR-Lex, accessed 14 November 2026, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389 ↩ ↩² ↩³ ↩⁴