Has Tokenization Come of Age?

When I first heard about credit card number tokenization, I couldn't believe I missed such a simple solution. I was so focused on complex encryption that I didn't "think out of the box." Since then I know of several retailers that selected that solution, and several others that have chosen to stay with encryption.

So what exactly is tokenization? I came across an interesting article in which Shift4's Randy Carr uses a princess analogy to explain the concept:

"Say you have a castle with a princess, and all these bad guys keep riding up trying to kidnap her. The way the industry has approached security is to put a moat around the castle, bar the doors and windows and put archers on the roof. Why don't we just remove her from the castle?'"

credit%20card.jpgOnce an authorization is received, a token is generated that replaces the actual credit card number. The token follows the constructs of credit card numbers, so it meets validation requirements in existing applications. From an application's point-of-view, the token looks just like a credit card number.

For all subsequent interactions with the acquirer, the "token middleman" converts tokens to credit card numbers. This allows the retailer to claim no credit card numbers are stored in its databases, yet still be able to process charge-backs and returns. The security onus is back on the gateway, off the retailer's premises.

Companies such as BluePay, EPX and MerchantLink are using this approach to help retailers meet PCI compliance.

But how is this different than encrypting the credit card number? Couldn't a token simply be a secure hash of a credit card number? Yes it could, but the elegance of the token is that it mimics the format of credit card numbers so that existing applications work as is.

Of course when a card is swiped, the credit card number needs to be protected until it can be tokenized, so some encryption is still necessary. But that's transient encryption, so keys are temporary and require very little management.

As Shift4 says, "They can't steal what you don't have."


I understand the application of this method in the PCI arena. The data is in flight and needs to be protected. However many organizations have large amounts of sensitive customer information that is at rest on storage devices. Government regulations require this data be protected. The dominant approach is to encrypt this data. Or could the token approach be adopted? What are the tradeoffs for data in flight versus data at rest? Encryption vs Tokenization?

Posted by John on July 22, 2009 at 09:40 AM PDT #

John, good point. I often tell retailers that they should look at security at the enterprise level, not just focus on POS. In that case, it makes sense to have a single keystore (like a HSM) that can be used for encryption across many different systems. Encryption is certainly more versatile, but also more disruptive. I think when a retailer just wants to solve their immediate PCI needs, then tokenization is a great approach. If they are looking to secure lots of different types of data, like PII, then general purpose encryption should be considered.

Posted by David on July 22, 2009 at 10:18 PM PDT #

Okay, we have removed the princess from the castle. At this point, the castle is worth nothing to the bad guys. The guys are still after the princess though. Move your princess to a hovel in the woods. She'll be an extremely easy target to the bad guys, in this scenario.

I beleive that 'the princess analogy' has to be re-phrased. It should state something, like 'kill your princess yourselves, before the bad guys reach her'.

Posted by Anonymous on February 18, 2013 at 08:29 AM PST #

Credit card transactions will match into one amongst 3 totally different categories: Level one, Level two or Level three process.

Posted by Reddy Mudiam on September 04, 2014 at 02:38 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed

News and ideas about the retail industry with a focus on customers, innovation, trends and emerging technologies.

Oracle Industry Connect 2016

Stay Connect with Oracle Retail


« May 2016