What Payment Tokenization Means to a Merchant

Payment tokenization is the process of replacing sensitive data during a transaction with a unique, but completely different identifier. The sensitive data is securely stored in a vault, and the token is presented and identified whenever it is needed to authenticate a transaction.

Merchants have three options for payment tokenization:

1. Use Card Network-supplied systems.
2. Use the services of a full-service payment service provider (PSP).
3. Tap into a Third-Party Tokenization Platform

An example of how payment tokenization works can be found with Passes, a creator platform enabling fans to access exclusive content and experiences. Because of the perceived high-risk nature of the platform, many PSPs that specialized in high-risk transactions were slow, difficult to work with, and could shut them down without warning.

The company wanted a cascading payment strategy, where they could select the right PSP for each transaction, based on a range of relevant factors. Passes chose to work with Basis Theory for payment tokenization, then used sophisticated routing rules to access the tokens and direct transactions to the appropriate PSP depending on those factors.

Payment Tokenization vs Encryption 

Both encryption and tokenization are used to protect sensitive payment data, and they're often confused. The distinction between encryption and tokenization matters when evaluating your payment security strategy.

• Encryption scrambles data using an algorithm and a key. The original data still exists, it just travels in a protected form. The problem is if an attacker steals the key, or applies enough computing power, the data can be exposed. Encryption is reversible, by design, which is both its utility and its vulnerability.
• Tokenization takes a fundamentally different approach: it replaces the sensitive data entirely. When a customer enters their card details, Basis Theory securely stores the Primary Account Number (PAN) in a token vault and returns a randomly generated token to the merchant. That token has no mathematical relationship to the original card number, so there’s nothing to crack.

Practically speaking, encryption protects data in motion, and tokenization protects data in motion and at rest.

A useful way to think about it: encryption is like a lock on a safe that still contains your data. Tokenization is like a claim ticket that points to a safe you don't own or control. Even if someone steals the ticket, they can't open the safe.

Return to Top

How does payment tokenization work? 

Payment tokenization replaces sensitive data with a token before it reaches your systems. It happens in three steps:

• Data Collection: Merchant embeds a form to deliver payment details directly to the tokenization provider. The provider responds to the merchant with a confirmation code and a token that can be used to complete the transaction.
• Data Storage: Raw data remains with the tokenization provider in a token vault.
• Transmitting the Tokenized Data: Using the token (as well as going through identification and authorization processes), the merchant tells the tokenization provider to transmit the payment data to the PSP of their choice. The provider executes the transaction without ever revealing cardholder data.
• Updating Stored Payment Details: The customer can enter their details into a hosted form, the vault is updated, and the raw data stays with the provider while the token held by the merchant will now use the updated information.

Return to Top

Types of Payment Tokens 

Payment tokenization architecture enables flexibility, along with security. A key element in that is the use of different token types, because not all tokens are created equal. The type of token used in a payment, and offered by a PSP, can affect how it works within an existing system.

• Format-Preserving Tokens: These tokens are structured to look like the data they are replacing. A format-preserving token for a credit card number will still look like a 16-digit card number, making it easier to drop into legacy systems that expect a specific data format, without requiring changes to any existing infrastructure. The tradeoff is that they can be slightly more predictable in structure, though they still have no mathematical relationship to the original PAN.
• Random Tokens: These are completely random strings with no resemblance to the original data. They offer the highest level of security because there's no structural pattern that could give an attacker any useful information. Basis Theory calls these Universal Tokens and issues one when your customer's card details enter the vault. What comes back to you is an opaque, randomly-generated identifier that means nothing outside of the system.
• Single-Use Tokens: Generated for one transaction and immediately invalidated afterward. These are ideal for guest checkouts or one-time purchases where there's no reason to store a payment method for future use. Basis Theory labels this token type a Token Intent.
• Multi-Use Tokens: These can be used repeatedly, making them the foundation of recurring billing, subscriptions, and saved payment methods. Following Basis Theory’s approach, the token belongs to you, not your PSP.

PSP-agnostic tokens are often provided by third-party tokenization providers on behalf of their customers and can be integrated into a merchant’s systems. Sophisticated payment stacks will choose the best token type for each transaction.

Return to Top

Payment Tokenization and PCI Compliance 

Payment tokenization benefits merchants by reducing their PCI-DSS responsibilities.

PCI-DSS (Payment Card Industry Data Security Standard) governs how cardholder data must be stored, transmitted, and protected. The requirements are extensive, and the audit process is expensive, particularly for merchants classified at higher compliance levels.

PCI-DSS scope is determined by whether cardholder data touches your systems. If it does, you're in scope for the full range of requirements. If it doesn't, your scope shrinks dramatically. With a payment tokenization approach, cardholder data enters the vault directly and never passes through your servers.

What lives in your systems is only a token that has no value to an auditor or an attacker. This means:

• Your systems are largely out of PCI scope because they never handle real cardholder data.
• The tokenization provider maintains PCI-DSS Level One compliance on your behalf, the highest certification available.
• Your compliance burden shifts from managing cardholder data security yourself to ensuring your integration with the tokenization provider is properly implemented.
• The token remains in the control of the merchant, and can be transmitted to the PSP, or PSPs, with whom they are currently contracted, and any others that may be added to the system as the merchant builds valuable relationships that optimize processing costs.

This is a meaningful distinction from PSP-issued tokenization: when the PSP handles compliance, your token only works within that PSP's ecosystem.

Return to Top

Choosing a Payment Tokenization Approach 

Many (PSPs) deliver an extensive set of services to cover all aspects of payment transactions, from card data collection and storage to merchant bank settlement. One service particularly popular from full-service PSPs (aggregators) is tokenized payments.

The PSP stores the cardholder information, meaning the merchant can access it when working with that PSP, as their token is valid only for that provider. But if the merchant wants to extend their processing system to encompass more than one PSP (say, to improve their performance in another geography, or to take advantage of competitive processing rates) or even to replace their current partner with another, they risk needing to re-gather payment information from all their existing customers. This is a significant resource drain for the merchant and negatively impacts customer satisfaction.

Third-party tokenization service providers like Basis Theory deliver the same secure collection, storage, and access benefits PSPs offer, alongside the flexibility to automate and optimize payment systems by adding and removing PSPs at any time. The third-party tokenization partner collects each credit card exclusively on behalf of the merchant, provides them with the token they need to access the information, and enables them to select which downstream partner (generally a PSP) they wish to share it with to complete transactions.

Merchants find that this approach offers a shorter implementation time and lower maintenance load than network tokenization; substantially greater flexibility than PSP-offered tokenization; and the ability to build a network of processing partners that can more reliably process transactions, at a lower overall processing cost. All this, while delivering the benefits offered by each.

Now that you understand how payment tokenization works and why it matters, the natural next question is how to actually implement it for credit card data specifically. Our guide to credit card tokenization walks through how card data is captured across web, mobile, and call center environments, how tokenization interacts with your PCI DSS compliance scope, and what to look for when choosing a tokenization provider.

If you're moving from understanding the concept to planning an implementation, this is the logical next step.

Return to Top