Solidgate logo in black and white.

Tokenization

What is tokenization?

Tokenization is a data security method that replaces a payment card number with a randomly generated substitute value, called a token, that carries no exploitable meaning on its own. The token keeps the format and length of the original card number, so it moves through existing payment systems without changes to their code.
The value most often tokenized is the cardholder's Primary Account Number (PAN), the 16-digit number printed on the card. Once the PAN is swapped for a token, the merchant stores and transmits only the token, while the real number sits in a hardened token vault operated by a card scheme, a gateway, or another token service provider. That separation is what makes a stolen token useless: without access to the vault holding the mapping, it can't be resolved back into a card number.

Key facts

  • Also known as: payment tokenization, credit card tokenization
  • What gets tokenized: the PAN, and in some implementations the expiry date and cardholder name
  • Main variants: network tokens issued by the card schemes through services such as and , and provider tokens issued by the gateway or processor that stores the credential
  • Format: the token preserves the length and format of the card number it replaces
  • Applies to: , card-on-file and subscription charges, and wallet payments
  • Not the same as encryption: transforms the card number with a reversible key, so the original is recoverable by anyone holding that key. A token has no mathematical relationship to the PAN and only resolves through a lookup in the vault.

How it works

  1. Capture. The cardholder enters card details at checkout, or the merchant submits a credential it already holds.
  2. Token request. The requesting system identifies itself to the token service, which is what a exists to record.
  3. Generation. The token service creates a random value, writes the token-to-PAN mapping into its vault, and returns the token.
  4. Storage. The merchant stores the token instead of the card number, so the PAN never lands in its environment.
  5. Use. For each payment the merchant submits the token. The token service resolves it to the real PAN and passes it to the issuer for .

Why it matters

  • Systems that only ever handle tokens fall largely outside scope, which shrinks the audit surface a merchant has to certify.
  • A breach of merchant systems yields tokens rather than card numbers, so the stolen data can't be replayed at another merchant.
  • Network tokens are updated by the scheme when a card is reissued, lost, or expires, so stored credentials for keep working without asking the cardholder to re-enter them.
  • A network token can be restricted to one merchant, channel, or device, so a token lifted from one context is declined in another.

Common issues

  • Portability. Provider-issued tokens are valid only inside that provider's vault, so switching processors requires a token migration coordinated between the old and new provider.
  • Uneven network token coverage. Support varies by scheme, market, and provider, so a merchant can end up running network tokens on some traffic and provider tokens on the rest.
  • Session-level attacks remain. Tokenization protects data at rest and in transit; an attacker who compromises a merchant's own systems can still trigger charges against the tokens held there. and screening cover that gap.

Related terms