GS Logo
The Green Sheet, Inc

Please Log in

A Thing
View Archives

View PDF of this issue

Care to Share?

Table of Contents

Lead Story

Integrated systems create a new POS paradigm


Industry Update

Intuit's IMS ends agent program

Indictment halts the action for poker sites, processors

PayPal, Discover launch Money Messenger

Does certification without licensing make sense?

Selling Prepaid

Prepaid in brief

China's prepaid market a different world

Prepaid's unique way in India


Text message marketing, the other mobile

Pal Flagg
Street Savings

Meet The Expert: John Arato

Technology in the hospitality world

Press release power


Facts and figures from the feet on the street

Jeffrey Shavitz
Charge Card Systems Inc.


Street SmartsSM:
Let's reform our industry's education and training

Bill Pirtle
MPCT Publishing Co.

What tokenization is and isn't

Tim Cranny
Panoptic Security Inc.

Ask, don't sell

Jeff Fortney
Clearent LLC

How to use direct mail to build your business

Peggy Bekavac Olson
Strategic Marketing

Global opportunities mean global strategies

Caroline Hometh
RocketPay LLC

New Products

Tapping the government and education markets

Electronic Merchant Systems


Learn to make use of conflict


10 Years ago in
The Green Sheet


Resource Guide



2011 Calendar of events

A Bigger Thing

The Green Sheet Online Edition

May 09, 2011  •  Issue 11:05:01

previous next

What tokenization is and isn't

By Tim Cranny

Tokenization is a heavily promoted technology in the Payment Card Industry (PCI) Data Security Standard (DSS) space. Vendor claims range from stating that tokenization helps reduce the scope of PCI to insisting that it makes PCI compliance problems go away. The first claim is fairly accurate; the second is false.

When a solution is caught in a wave of hype and fashion it can be hard to separate fact from fiction. Hopefully, this article will clarify what tokenization can do.

What does tokenization do?

First, tokenization is not snake oil. It is an example of good security principles put into practice. People go wrong when they exaggerate its effect until it becomes likened to a "magic pill."

The principle behind tokenization is simple. The best way to handle security concerns, such as the theft of stored data, is to avoid the problem altogether. By far the best way to protect cardholder data that you store is to stop storing it. No one can steal what you don't store.

That's fine in principle, but for many merchants there's a downside to not storing cardholder data like primary account numbers (PANs): their businesses need that information on hand so they can do things like recurrent billing.

Tokenization gives merchants the benefits of storing data, without the security costs. The benefit of storing PANs and other sensitive information is that merchants can then reuse the cardholder data for subsequent transactions by passing it back up to the gateway or processor.

But since we're talking about subsequent transactions, the gateway or processor has already handled the same cardholder data before. If the gateway or processor stores the details, what it needs from the merchant isn't the sensitive information itself, but rather a suitable reminder so it can pull the information out of its database.

In effect, instead of the merchant storing and then resending sensitive information like the cardholder's name, card number and expiration date, the merchant can just identify the customer, provide the amount of the new transaction and ask the processor to look up the account details.

How does it work?

In practice, the processor and the merchant agree to label a particular customer with a unique "token" (typically a 16-digit number), and all the merchant needs to store is the token, not the PAN and other identifying information.

The merchant then reuses the token every time he or she would otherwise have reused the sensitive information. The processor knows that when the merchant sends up that token, it needs to go look up and load that particular customer's details.

A few things to note:

It is critical to note that tokenization does not eliminate PCI responsibilities for merchants. Merchants are still accepting payment cards and must continue to comply with the PCI DSS. This becomes obvious when you think about it, because tokenization doesn't replace the need to get the cardholder data into the system in the first place.

How will merchants benefit?

There are very real benefits from tokenization, though, for most merchants. These include:

This last point should make it clear that tokenization doesn't do much for merchants if, for different reasons, they continue to store PANs in systems other than those set up for payments.

The payoff from tokenization is being able to stop storing sensitive cardholder data. There is only a tiny benefit in storing the data in one place instead of two; 99 percent of the payoff comes from going from one storage place to none.

I recommend that merchants (or the ISOs, merchant level salespeople and banks acting on their behalf) keep the following points in mind when evaluating companies that provide tokenization:

With these simple guidelines in place, merchants, ISOs and others have an opportunity to use tokenization to simplify and secure an important part of their businesses.

Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. ( He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at or 801-599 3454.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.

previous next

Spotlight Innovators:

North American Bancard | Simpay | USAePay | Impact Paysystems | Board Studios