Setting the Record Straight: Payment Tokenization vs. Data Security Tokenization

26 Nov

by Jacob Burcham

EMVCo Payment Tokenization

EMVCo is a consortium of major credit card brands dedicated to ensuring the interoperability and acceptance of secure payment card transactions. Europay, MasterCard, Visa, JCB, American Express, UnionPay and Discover work together to form standards and frameworks for the systems that support payment card transactions. The EMV payment tokenization specification (currently v2.0) establishes a technical framework for securing payment card transactions via payment tokenization. The major card brands, acquirers, merchants, issuers and cardholders benefit from this framework in the form of interoperable systems and increased security.

How Payment Tokenization Works

Payment tokenization replaces the primary account number (PAN) in the account data environment with a non-cryptographically reversible token, which reduces PCI-compliance scope when implemented correctly. The typical payment tokenization process works like this: a transaction is initiated between a cardholder and a merchant. The merchant passes along the PAN and tokenization request to the payment network where the card brand works behind the scenes to route the tokenization request to the issuing bank. There, with the approval of the issuer, the card brand can replace the PAN with a payment token. That token is then sent back to the merchant. Here is an example of a payment tokenization workflow:

1. A customer inputs their PAN online or in-store to a merchant, or more generally, a token requestor.

2. The token requestor sends the PAN and tokenization request to the payment network’s tokenization service.

3. The payment network routes that request to the issuer.

4. With the issuer’s approval, the payment network replaces the PAN with a token.

5. The token is sent back to the token requestor.

There may be instances where several payment tokens have been issued to represent that same underlying PAN. In this case, a linkage mechanism called a payment account reference (PAR) is used to indicate the PAN that a token is associated with. A PAR is essentially a token value that is mapped to a single PAN value. However, several payment tokens may be mapped to a single PAR value. The reason for using a PAR instead of the PAN itself is to protect the PAN via a layer of abstraction and reduce the pain points generally associated with sending and receiving PANs.

Security of Payment Tokens

A payment token is valuable because it can initiate a transaction just like the original PAN. The security of a payment token derives from the restriction of how a particular payment token may be used. These usage controls are a product of the EMV specification for payment tokenization and are referred to as token domain restriction controls (TDRCs). For example, a payment token can be restricted to a particular merchant, a particular device, a payment channel, subsequent merchant-initiated transactions, etc. An important characteristic of payment tokenization is the inverse correlation between functionality and security. As the token becomes more restricted, its functionality decreases while the security increases.

Payment Tokenization vs. Data Security Tokenization

Tokenization solutions can be divided into two categories: payment tokenization and data security tokenization. The EMV payment tokenization specification refers to its framework as payment tokenization, or the use of payment tokens, and they refer to all other tokenization solutions as “nonpayment tokens.” This is misleading because data security tokenization can handle cardholder data and payments, too. In this article, I will refer to EMV payment tokenization as “payment tokenization,” and I will refer to the other type of tokenization as “data security tokenization.” Across the industry, the terminology is a bit unclear, so here is a list of terms that are more or less interchangeable for the two subcategories of tokenization:

Payment Tokenization:

• Network tokens (as in payment card network)

• Open-loop tokens

• Payment tokens

Data Security Tokenization:

• Data security tokens

• Closed-loop tokens

• Nonpayment tokens

Let’s imagine that we maximized the security of a payment token by totally restricting its use. Essentially, the token would have zero functionality. The token would be a random, useless value that only aesthetically resembles a PAN. This maximum-security type of token is referred to as a data security token. If compromised, it cannot be used anywhere for anything. It is simply a random surrogate value that a data security tokenization vendor has created and irreversibly mapped to the original, sensitive data.

Both payment tokenization and data security tokenization implementations can issue tokens to be card-based (a 1:1 mapping between the PAN and a token). This feature enables convenient card-on-file features such as recurring payments and one-click checkouts.

Data security tokenization solutions handle more than just cardholder data. These solutions may be able to handle personally identifiable information (PII), protected health information (PHI) or other forms of sensitive data that may be regulated by data security and/or data privacy regulations such as GDPR, CaCPA and HIPAA. In comparison, payment tokenization is designed solely to protect payment cardholder data.

From a PCI-compliance perspective, a subtle difference between payment tokenization and data security tokenization is the potential shift in fraud liability involved with implementations of payment tokenization. For example, if the merchant uses EMV payment tokenization technology but has failed to use an EMV chip reader at their POS system, the liability of payment card fraud shifts from the card issuer to the merchant.


Payment tokenization is a better way for cardholders to make digital payments. In general, payment tokenization gives consumers a more secure way to pay from their apps, smart watch, mobile phones or web browser. Payment tokenization is designed to improve the security of the digital transaction ecosystem and reassure consumers about inherently less secure payment channels.

Data security tokenization is the most effective way to protect sensitive data. Merchants, data analytic operations, enterprises, third-party service providers and any entity that stores, transmits or uses sensitive data should be aware of the differences between payment tokenization and data security tokenization. Data security tokenization is designed to eliminate the risk of a data breach and maintain operational functionality while reducing compliance scope.

TokenEx specializes in crafting data security tokenization solutions that completely protect sensitive data and secure the business process, regardless of data type or destination. Our flexible cloud-based platform features transparent integration, allowing our solution to work seamlessly alongside your system without resulting in any loss of functionality. Contact us today to learn more about why TokenEx should be your solution for data security.


Plastic card chip macro close up