How VARs Can Help Merchants Overcome Tokenization Confusion
By J.D. Oder II, CTO and senior vice president of R&D, Shift4 Corporation
Even though tokenization was introduced to the payments industry more than a decade ago and has since become an industry mainstay, there is no agreed-upon protocol about how tokenization should be deployed or even what defines a token. This leads to a great deal of confusion, because people are using the term in ways that can lead merchants to believe their customers’ card data is protected when it’s not.
EMVCo and the PCI SSC have both attempted to standardize tokenization over the past few years, but neither has succeeded. These two organizations can’t even agree on what tokens should look like or how they should function. VARs educated on this topic can help customers choose the solution or group of solutions that will serve them best.
Defining Tokenization
Tokenization takes its name from an arcade token. It exchanges a credit or debit card number, which like a quarter has universal value, for a token that has value only within specific parameters and locations.
Today, though, the word tokenization is being used broadly to describe a variety of payment security methods that perform different security functions. EMVCo tokenization, for instance, can refer to both mobile payment tokenization (like Apple Pay) and card-based tokenization. One recent article even described point-to-point encryption as a tokenization solution. But no — tokenization was specifically designed not to be encrypted data, because encrypted data is potentially decryptable.
How Tokenization And Encryption Differ
Tokenization is a random, globally unique, alphanumeric value that replaces payment card data after bank authorization so the data stored in merchant systems has absolutely zero value outside of their environment. Tokenization works differently than encryption because it is organically random with no mathematical pattern to be unlocked. Tokens were designed to never maintain a one-to-one relationship with a card ensuring tokens aren’t predictable and cannot be reversed or decrypted. Also, because tokenization is alphanumeric, there are enough possible permutations that they will never be repeated within even the largest payment ecosystems.
For true security, a token should be linked to a single card number only for a single transaction — not linked to the card as a constant. This varies from recent industry discussions that reference security features driven by mobile wallets and credit or debit cards, such as EMVCo tokenization. These services actually aren’t tokenization at all. Instead, they are consumer-based token services that seek to protect the cardholder — not the merchant. This is a noble undertaking, but slightly misguided, since having a token that references the same card number has, in essence, done nothing more than create a new card number that is just as vulnerable to attack as the original data; this is not what tokenization was designed to do.
The Purpose Of Tokenization
Tokenization was created to protect merchants from falling prey to a data breach. Some merchants need to store transactional information after the initial payment is processed to allow for returns, incremental authorizations, recurring billing, etc. This meant keeping hundreds — if not thousands — of card numbers on file. However, tokenization proved sensitive, vulnerable card data doesn’t actually need to be stored, even in card-on-file environments.
Using tokenization, merchants can continue their business practices and simplify the customer experience without the looming fear of a data breach. They can rest assured that all of their sensitive card data — not to mention their brand — are safe from malicious cybercriminals.
Working Together
Consumer-based tokens that any retailer can accept have universal value — and therefore universal risk. If one of these consumer-tokenization providers released their full list of tokens tomorrow, you can bet there would be an instant increase of fraud among merchants that accept them.
PayPal, Samsung, Apple, and others have been successfully assigning consumer-based tokens like those for years. They do offer a certain level of protection to cardholders at the point of purchase and have — knock on wood — been relatively effective in preventing mass-scale breaches. However, these technologies simply should not be called tokenization.
The thing is, these two technologies can actually work together to accomplish greater security. Tokenization — according to the original definition — does its job protecting merchants by legitimately tokenizing the consumer-based tokens that are received from a mobile wallet or other payment instrument. This prevents the merchant from having to maintain a database full of sensitive data — even if that data in this case is an encrypted surrogate of cardholder data.
Accepting mobile wallet and other card-based tokenization solutions is good for business. However, merchants need to understand what tokenization truly means so they can properly safeguard themselves and their customers from data theft. VARs willing to learn the sometimes-subtle differences between these data security solutions will become an excellent customer resource by leading merchants to the solutions that will truly protect their business.
J.D. Oder II serves as Shift4’s CTO and SVP – R&D. J.D. is a Certified Network Engineer with more than 15 years of experience. He leads Shift4’s systems operations and development efforts as well as the security and compliance teams. J.D. is the architect of the DOLLARS ON THE NET® payment gateway solution. He is credited with introducing tokenization to the industry in 2005 and was also an early adopter/member of the PCI Security Standards Council.