Tokenization

Tokenization is the process of replacing sensitive payment data, such as a card number, with a non-sensitive substitute called a token that has no usable value if it is stolen. The real card data is held in a secure store, often called a vault, kept by the tokenization provider, and the merchant stores and uses only the token to charge the card for future or recurring payments. Because the merchant no longer holds the actual card number, tokenization reduces its exposure if systems are breached and narrows the scope of what has to be secured for card data compliance, while still allowing repeat billing. Storing cards this way is often called card vaulting.

A token is a stand-in. It looks like a reference value rather than a card number, and it means nothing outside the system that issued it, so a token taken from a merchant's database cannot be used to make purchases elsewhere. The sensitive card data lives in the provider's vault, and the token is simply a pointer back to it. When a merchant needs to charge the card, it sends the token, and the provider maps it back to the real card to process the payment. This is what makes tokenization so useful for subscriptions: the business can bill a customer month after month without ever storing the raw card number itself. It is different from encryption, which scrambles data that can be unscrambled with a key; a token has no mathematical relationship to the original card number.

Why tokenization matters for subscription businesses

Storing raw card numbers is a serious liability. It makes a merchant a richer target for attackers and pulls more of its systems into the scope of card data security requirements such as PCI DSS. Tokenization removes the card number from the merchant's environment, which shrinks that exposure and can reduce compliance scope, while still letting the business run recurring charges. For subscription operators in particular, tokenization is close to essential, because charging a customer repeatedly requires keeping a way to bill the card, and a token is a far safer thing to keep than the card itself.

How to use tokenization

Put tokenization to work as the foundation of secure recurring billing:

• Capture card details through a provider flow that sends the data straight to the vault, so raw card numbers avoid your own servers where possible.

• Store only the returned token in your systems, never the card number.

• Use the token for renewals, retries, and one-off charges to the saved card.

• Confirm how tokens map across your gateways and providers, since a token is usually meaningful only within the system that created it.

How tokenization works

Tokenization follows a sequence from capture to reuse:

1. The customer enters their card details at checkout.

2. The card data is sent to the tokenization provider or vault, ideally without passing through the merchant's own servers.

3. The provider stores the real card data securely in the vault and returns a token.

4. The merchant stores the token in place of the card number.

5. For future or recurring charges, the merchant sends the token, and the provider maps it back to the real card to process the payment.

Benefits and examples

Tokenization lowers risk and compliance burden without disrupting recurring billing. As an example, when a customer saves a card at sign-up, the business receives a token and stores that instead of the card number. Every future renewal charges the card by sending the token, so the customer never re-enters their details and the business never holds the sensitive data. If the merchant's database were ever exposed, the stored tokens would be useless to an attacker, because they cannot be turned back into card numbers without the vault.

A subscription management platform makes tokenization the default path for recurring billing rather than a feature a team has to assemble. When cards are vaulted as tokens and every renewal, retry, and one-off charge runs against the token, the business gets secure repeat billing without holding raw card data, and can keep charging saved cards reliably across billing cycles. For the business, that means lower data risk and reduced compliance scope while recurring revenue keeps collecting. Recurly.js tokenizes card details directly in the customer's browser, so raw card numbers never reach the merchant's own servers, which can help a merchant qualify for a reduced PCI scope such as SAQ-A rather than the higher SAQ-C or SAQ-D that applies when card data passes through the merchant's own servers. Beyond the one-time token used at checkout, Recurly also supports gateway tokens, which reference a stored payment method at a specific gateway and aren't portable to another one, and network tokens issued directly by the card networks, which can be used across multiple gateways and support failover or migrating a subscription to a new gateway without re-collecting card details.

Frequently asked questions

What is tokenization? It is replacing sensitive card data with a token, a substitute value that is useless if stolen. The real card is kept in a secure vault by the provider, and the merchant stores and uses only the token to charge the card.

How is tokenization different from encryption? Encryption scrambles data so it can be unscrambled later with a key, meaning the original is still recoverable. A token has no mathematical link to the original card number and can only be resolved by the vault that issued it, so a stolen token cannot be reversed into card data.

Why do subscription businesses use tokenization? It lets them charge a saved card repeatedly without storing the card number, which supports recurring billing while reducing both the risk of holding sensitive data and the scope of card data compliance.

What is card vaulting? Card vaulting is storing customers' card data securely in a provider's vault and using tokens to reference it. It is the mechanism that lets a business bill saved cards on an ongoing basis without keeping the raw numbers itself.

Does tokenization make a business PCI compliant? It does not make a business compliant on its own, but by keeping raw card numbers out of the merchant's environment it can reduce how much of that environment falls under card data compliance requirements. Treat it as one important control, not a complete solution.