Payment tokenization: how tokens run saved cards and subscriptions

A token's working day

Most small merchants never see a tokenization system. They see its output: a string in the customer record that lets them charge the card again. Follow one customer through a year of payments and the token turns up at every step, while the card number stays in the processor's vault.

Look at where the token repeats. After the “save my card” moment, every later charge rides on the same token, which is why the token behind a saved card is the valuable one. The after-sale work matters too. The Council's advice is to pick a setup where, once a token is issued, “all further transactions or processing (for example, refunds, chargeback, loyalty tracking, etc.) can be performed without the need for the merchant to retrieve or access the PAN.”

Single-use and multi-use tokens

The Council sorts payment tokens by how long they live. Which kind you get decides whether you can charge the customer again without asking for the card.

A multi-use token “always maps a particular PAN value to the same token value within the tokenization system.” That is what makes subscriptions, saved cards and one-click reorders work, and it is also what makes the token worth guarding. A single-use token stands for one sale and nothing after it. Which mix you need, the guidelines say, “will depend on the merchant’s specific business need for retaining tokens.”

The last format keeps the first six and last four digits so receipts and customer screens still show something familiar. The catch is in the guidelines' section on telling tokens apart: “some tokens are designed to mimic the type and format of the original PANs, and it may not be possible for a human reviewer to distinguish between the two types of data.” If you cannot tell a token from a card number, you cannot tell whether a spreadsheet or an export is in scope. The guidelines say the provider's method for telling them apart “should be shared with the merchants using that solution.”

Card on file and recurring: what the card brands add

A token keeps the card number off your systems. It does not take you out of the card brands' rules for saved cards. Visa defines a stored credential as information “(including, but not limited to, an account number or payment token)” stored to process future purchases, so a saved token counts the same as a saved card. Visa draws one line that helps small shops: a credential kept “to complete a single transaction or a single purchase” is not a stored credential. Its example is a hotel. A card held for one reservation is not stored; a card kept on a member profile for future stays is.

The split that matters day to day is who starts the charge. A cardholder-initiated charge has the customer taking part, at a terminal, at checkout or with a card already on file. A merchant-initiated charge happens without them: the monthly renewal, the instalment, the mini-bar charge after checkout. Visa says these rules apply to transactions “Performed with primary account numbers (PANs) or payment tokens,” so the token changes nothing here.

Processors pass the same duty to you in their own docs. Stripe's guide to saving a card tells its users they are “responsible for your compliance with all applicable laws, regulations, and network rules when saving a customer’s payment details for future use,” and lists what to do first, including “Collect explicit consent from the customer for this specific use” and “Keep a record of your customer’s written agreement to your terms.” The token is the processor's; the agreement is yours.

Processor tokens and network tokens

The tokens in the table above are processor tokens: your gateway issues them, keeps the card in its vault, and only it can turn one back into a card number. The card brands run a second layer. Visa describes its own service plainly: “Visa Token Service is a security technology that replaces 16-digit Visa account numbers with a token that only Visa can unlock, protecting the underlying account information.”

The line a subscription business cares about is the last one. Visa says tokenization can update “expired or compromised payment credentials without any manual updates being made by the customer in the event that their Visa card is lost, stolen or expired.” A renewal that would have failed on a reissued card can go through.

You rarely choose between the two. A processor can request network tokens behind the token it gives you; Stripe, for one, lists “card account updater (CAU), network tokens, and Adaptive Acceptance” among its features for migrated cards (the Stripe PCI guide covers how it splits the rest of the work with you). Your records hold the processor's token either way. This page describes Visa's network tokens from Visa's own pages; for the other card brands, ask your processor which token services it uses.

What tokens do to your PCI scope

Tokens can shrink PCI scope, but “Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance.” A system holding only tokens is out of scope only if the PAN cannot be recovered from those tokens and the system cannot affect cardholder data security. The Council's tests for that live in our tokenization vs encryption guide. What follows is the part a merchant on a processor's tokens tends to miss: the work that stays on your side.

The incident line is more concrete than it sounds. The guidelines name the moves a plan should consider if something goes wrong, such as “rejecting de-tokenization requests from potentially compromised systems, reissuing tokens, and re-encrypting PANs in the data vault with new cryptographic keys.” Most of those are the processor's to perform; your plan should say who calls the processor and what you ask for.

Changing processors: the tokens stay, the cards move

A processor token only means something inside the system that issued it. When you move to a new processor, your saved tokens do not come with you; the card numbers behind them have to travel from one vault to the other, and you get new tokens at the far end. Stripe's migration docs show what that looks like from both sides; other processors' steps may differ, so ask yours.

The transfer runs between processors, not through you. Stripe's export page says it can “only transfer your card data to another PCI DSS Level 1-compliant payment processor” and asks for the receiving processor's Attestation of Compliance or Visa registry listing. It also says it “doesn’t export your account’s payment history, subscriptions, or other objects.” Plan for both: the cards move, the billing schedules you rebuild.

Questions to send your processor

Everything above comes down to answers only your processor can give. These are the questions, each tied to the rule or document it comes from. Send them as one email, keep the replies with your SAQ papers, and ask again when you change plans or add a sales channel.

Quick reference: payment tokens