Tokenization – a panacea for credit card number security?

3 03 2012

by Pragati Mathur

The concept of tokenization has been around for a few years. However, acceptance in security realm has not been that good. Lately though, with major security incidents occurring at companies such as Sony PlayStation, this concept has taken prominence. Moreover, a lot of new vendors have come into the market with offerings in this space. Payment Card Industry (PCI) Security Standards Council has finally come up with guidelines on how to implement tokenization.

They recently (August 2011) published a document PCI DSS Tokenization Guidelines Information Supplement. The guide outlines how to stay PCI compliant while using a tokenization system in a cardholder data environment (CDE).

What is Tokenization?

Tokenization is a process by which the primary account number (PAN) is replaced with a surrogate value called a – token [1]. Instead of storing sensitive cardholder data (CD), we store tokens. Tokens are random strings and are not sensitive or easy to decipher.

Rather than use encryption to secure the card data, replacement of PAN with tokens will eliminate the threat of a data breach. This will enable merchants who accept credit cards not to have sophisticated security mechanisms in place to do business transactions with credit cards. Merchants do not need to store PANs in their CDE or processing systems. Tokens will now be stored and tokens will be used to complete transactions with the payment processing service providers.

By implementing tokenization, PCI DSS requirements will get potentially reduced. PCI was clear in its guidelines with respect to tokenization. The key principles are [1]:

  • Tokenization solution does not eliminate the need to maintain and validate PCI DSS compliance.
  • Regular verification of the effectiveness of a tokenization implementation is necessary.
  • Tokenization systems and processes must be protected with strong security controls and monitoring.
  • Thorough evaluation and risk analysis to identify and document the unique characteristics of particular implementation, including all interactions with payment card data and the particular tokenization systems and processes should be done prior to implementing Tokenization solution.

How does tokenization work?

There are several ways of implementing tokenization. PCI DSS Tokenization Guidelines Information Supplement describes the tokenization and de-tokenization process as follows:

Tokenization Process (Source: PCI DSS Tokenization Guidelines Information Supplement)

  1. A requesting application passes a PAN along with authentication information to tokenization system.
  2. The tokenization system verifies the authentication information. If verification succeeds, it progresses to next step, else tokenization process stops and information is logged.
  3. The tokenization system generates a token associated to the PAN and both the token and the PAN are recorded in the card data vault.
  4. Generated token is returned to the requesting application.

De-tokenization is basically a reverse process.

De-Tokenization Process (Source: PCI DSS Tokenization Guidelines Information Supplement)

  1. The requesting application passes a token and authentication information to tokenization system.
  2. The tokenization system verifies the authentication information. If verification succeeds, it progresses to next step else the de-tokenization process fails, and information is logged.
  3. The tokenization system queries the card data vault for a record associated with the token and retrieves the PAN.
  4. PAN value retrieved from the card data vault is returned to the requesting application.

Card data vault has strict PCI DSS requirements. The PAN numbers are encrypted and stored. Some implementations tokenize the PAN number into multiple tokens and store it in distributed vaults. This pretty much makes it impossible to decipher the PAN in the data vault.

Merchant Realm

Once tokenization is implemented by a merchant, the process for the merchant will be:

  • Merchant accepts credit and debit cards in the usual manner.
  • Cardholder data is securely transmitted to PCI DSS compliant storage facility.
  • A token is created by the storage facility and returned to merchant.
  • The token is now stored at the merchant in place of cardholder data.
  • Future payment transactions for the same customer are transmitted by the merchant using the token in place of cardholder data.

Tokenization simplifies merchant systems

The PCI DSS Tokenization Guidelines recommend tokenization to be used in partnership with PCI DSS and not to be viewed as a replacement or alternative. While tokenization limits PCI scope, there are still PCI security requirements, as the council outlines. If the merchants access the PAN even after tokenization, for any reason, full PCI DSS requirements will apply.

Since we do not store PAN/Credit Card Information in merchant systems, PCI DSS restrictions are eliminated. All the strict processes and procedures can now be relaxed. This will reduce system configurations, network restrictions and will reduce overheads. So implementing tokenization would simply merchant systems. PCI compliance becomes much easier to achieve.

Current Technologies and Products

Tokenization technology vendors are very limited as of now. Protegrity, Wirecard AG., Shift4’s 4Go SafeSwipe, EPX’s BuyerWall and Merchant Link’s TransactionVault are the major products. There are several payment processing services who offer software as a service offering of tokenization solution as well.

Why tokenization is not widely adopted

According to Randy Carr, Vice President of Shift4 [2], tokenization will minimize the use of firewalls, intrusion detection systems and encryption. This is causing detraction in the industry. Moreover credit card companies generate revenue via security fees to merchants. By making the credit card info secure via tokenization would put that revenue in jeopardy.


Tokenization reduces the scope of cardholder data environment (CDE) of a merchant by offloading the storage of card number to a payment processing facility. This in turn relaxes PCI DSS restrictions and simplifies merchant systems and to achieve PCI compliance. This also helps new businesses to accept and process credit cards. Tokenization makes the card numbers secure in the payment center facilities as well thus minimizing leaks and hacker proof.

If implemented correctly, tokenization will act as panacea to the business. But before they adopt this technology, they should do a thorough evaluation and risk analysis.


1.  Information Supplement: PCI DSS Tokenization Guidelines – Scoping SIG, Tokenization Taskforce PCI Security Standards Council (
2.  ‘Tokenization’ touted to increase credit card data security – Jay MacDonald (




One response

5 03 2012
Tom Boumil

On the whole, this is a good write-up on tokenization, though I think that your short section on why tokenization is not widely adopted missed the mark.

The idea that by using a tokenization strategy to protect PAN info will minimize the use of firewalls, intrusion detection systems, and encryption is a little silly. All companies have sensitive data beyond PAN info that they want to protect and will maintain most, if not all, of their security infrastructure. Much of the savings for merchants comes from reduced PCI compliance (and fees to third parties supplying PCI consulting services), as well as fees for insurance carried to cover losses in the event of a breach. There is also the incalculable value brought by the peace of mind in knowing that a breach is not going to expose the sensitive info of your customer base. While this may be disruptive to the business model of some third party security providers, it is not disruptive to the industry as a whole or the card associations.

The second point, that credit card companies make money off security fees, is true, but those fees are a drop in the bucket compared to assessment fees of the companies and the interchange fees paid to the issuing banks. While I certainly cannot speak for the card networks, I would think that a reduction of revenue due to lost security fees is small compared to the potential losses associated with business disruptions brought on by a major breach.

In my opinion, the slow adoption (gaining more traction as time goes on) of tokenization is for several reasons. First, I think many merchants were simply waiting for tokenization offerings to mature a bit. Without any clear guidance from a governing body, the solutions offered were wide ranging and in some cases difficult for merchants to implement. No one wanted to make a quick decision and possibly get locked into what ultimately might not be the optimum solution. Second, many merchants have limited IT resources. Depending upon the tokenization solution, the merchant might have to make a sizable investment in changes to internal systems, stretching further, already over-burdened IT departments. For example, a seemingly simple difference, such as the supplied token being longer than a standard credit card number or being alphanumeric, might require extensive database changes as well as modifications to downstream order tracking and fulfillment systems.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: