Understanding the Difference: Real Tokenization Vs “Faux-Kenization”

By Daniel Montellano, SVP of Strategic Business Development, Shift4 Payments

In the payment security world, tokenization is universally considered to be an industry standard. However, there’s still some confusion about the exact history and purpose of the technology, as well as how to identify and avoid subpar copycats – or “faux-kenization” – solutions. Tokenization 1

The Origin of Tokenization

Shift4 is the inventor of the technology as we know it today. In 2005, they released the first payment data tokenization solution, which they called TrueTokenization. The idea behind this ahead-of-its-time technology was clear-cut: to secure post-authorization card data for the long term. It was created as an answer to the massive threat of data breach facing merchants who stored transactional information for returns, incremental authorizations, monthly billing, and more.

For example, hotels typically store their guests’ card numbers from the time the reservation is made until after the final checkout. This means keeping hundreds – if not thousands – of card numbers on file at a time, which left them with a huge amount of risk should they be breached. Tokenization solved that problem by replacing the stored cardholder data for each individual transaction with a random, alphanumeric value that would have no value in the hands of data thieves. When Shift4 released tokenization, they challenged the norm and proved that sensitive, vulnerable card data doesn’t actually need to be stored, even in card-on-file environments.

Fast-forward 13 years. In a little more than a decade, tokenization has gone from up-and-coming concept to being accepted as a must-have technology for businesses in virtually every industry. In fact, Forrester Research and Forbes recently listed it at #2 on their list of top data security and privacy tools. Not bad for a teenager.

Now that you’ve gotten a crash course in tokenization, here’s what merchants should consider when looking for a truly secure solution:

1. Tokenization is Not Encryption

While both are useful, it’s important to understand the difference between the tokenization and encryption of payment card data during a transaction. Tokenization was never designed to encrypt cardholder data. Instead, it was intended to be a globally unique, alphanumeric value that replaces payment card data after bank authorization, so the data stored in merchant systems has no value outside of their own environment.

Released in 2017, the EMV® Payment Tokenisation Specification Technical Framework refers to both card-based tokenization and mobile payment tokenization, such as Apple Pay, Google Pay, and other mobile wallets. But in essence, these methods are much closer to an encryption or cryptographic hash, and labeling them as tokenization is not only misleading and confusing – it’s actually quite dangerous to merchants.

2. Tokens Should be Randomly Generated

Tokens should never maintain a one-to-one relationship with a single credit or debit card. A trustworthy tokenization solution will assign a token for every single transaction. This ensures that tokens aren’t predictable and cannot be reversed or unencrypted. Also, because true tokenization is alphanumeric, there are enough possible permutations that they will never be repeated within even the largest payments ecosystems.

Again, this varies from the security features of mobile wallets and card-based tokenization solutions. Although they’re referred to as tokenization, these services aren’t actually tokenization at all. Instead, they are consumer-based token services that seek to protect the cardholder – not the merchant.

3. Tokenization Works Well With Others

As I mentioned, there’s a difference between tokenization and encryption, but that doesn’t mean that merchants have to choose one or the other to protect their payments from hackers. The best strategy merchants can employ is to layer multiple payment security solutions together. This will cover more entry points into their payment environment and provide the most thorough security against data breach. 

For example, merchants who accept EMV payments should also have point-to-point encryption (P2PE) and tokenization solutions. That way, they have EMV to prevent counterfeit card fraud, P2PE to encrypt data at the terminal, and tokenization to replace the data stored after the transaction. We call this the Payment Security Trifecta.

Not All Tokenization Solutions Are Created Equal

Since payment data tokenization has become such a widespread technology, there have unfortunately been a large number of substandard versions of the real deal. As the inventors of the technology who set the original high standard and continue to maintain it, Shift4 has the advantage of being able to easily identify which solutions are actually tokenization and which are the watered-down imitations. Unfortunately, it’s not always that easy for everyone.

The bottom line is, if merchants rely too heavily on these “faux-kenization” solutions, thinking they do more than they actually do, it can end up doing more harm than good to their business, image, and pocketbook if hackers decide to come knocking and they aren’t equipped.

 

About Shift4 Payments:

Shift4 Payments is the leader in secure payment processing solutions, powering the top point-of-sale and software providers across numerous verticals, including Food & Beverage, Hospitality, Lodging, Gaming, Retail and e-Commerce. This includes the company’s Harbortouch, Restaurant Manager, POSitouch, and Future POS brands, as well as over 300 additional software integrations in virtually every industry. With eight offices across the U.S. and Europe, 7,000 sales partners and three state-of-the-art data centers, the company securely processes over 1 billion transactions annually for nearly 200,000 businesses, representing over $100 billion in payments each year. For additional information, visit www.shift4.com

 

Image courtesy of Payments Industry Intelligence

POS Solution Finder






Invalid Input


Invalid Input


Invalid Input



Invalid Input


Invalid Input


Invalid Input


Invalid Input
Invalid Input


Invalid Input





Invalid Input

Invalid Input




Invalid Input




Invalid Input









Invalid Input









Invalid Input







Invalid Input







Invalid Input






Invalid Input






Invalid Input






Invalid Input










Invalid Input










Invalid Input




Invalid Input













Invalid Input









Invalid Input





Invalid Input





Invalid Input




Invalid Input



Invalid Input
Invalid Input
Invalid Input
Final Page
Q13: This is the Last Page of Questions:
Invalid Input
Invalid Input
Invalid Input
Invalid Input