The security of credit card data has remained an ongoing concern since their popularity grew in the 1970s. Whenever a new security feature is introduced, bad actors immediately start working to circumvent it.
Magstripes followed signature lines on the backs of cards, which gave way to embedded Europay, Mastercard, and Visa (EMV) chips.
The latest security feature is data tokenization, which prevents a merchant's point of sale (POS) terminal from retaining any customer banking information. We'll go over tokenized transaction basics, so you can see the benefits for your small business.
Overview: What is tokenization?
Tokenization is a process that replaces sensitive digital data with a randomly generated number. It's used to protect multiple types of information such as medical records, stock trades, criminal records, and loan applications.
In credit card transactions using tokenization, the token replaces the customer's personal account number (PAN) on the credit card, which is stored in a digital token vault.
The financial institution at the other end of the transaction uses detokenization to access the customer's PAN in the token vault and authorize payment. The PAN is never stored within the merchant's retail POS system.
Tokenized data, in theory, is indecipherable, because each token is randomly generated. No relationship exists between it and a customer's PAN, so token data can't be reverse engineered to reveal the original data.
Vulnerabilities can exist, however, because some random number generators create tokens using "pseudo-random values” that can't ensure each token's uniqueness.
A brief history of credit card security
I'm old enough to remember manual credit card processing: A flatbed card machine imprinted your card number on a paper receipt you signed to create a record of each transaction. (For large purchases, the store might call the credit card company for authorization.)
The weakness was anyone who had access to the customer or business purchase receipts could use the card number.
The magstripe containing account information on the back of credit cards came next, so you could make purchases without having anyone else handle your card or producing a paper receipt with your PAN on it. In response, fraudsters developed to steal magstripe data.
EMV chips embedded in cards subsequently addressed that issue through data encryption. EMV doesn't provide protection, however, for online or other card not present (CNP) purchases.
Tokenization vs. encryption: What's the difference?
The Payment Card Industry Card Data Security Standard (PCI DSS) requires businesses that collect, store, and transmit card data or authentication data to protect that information. POS systems use tokenization, encryption, or a combination of the two with an encrypted token.
Unlike tokenization, where no connection exists between the token and card data, encryption uses a mathematical algorithm and encryption key to convert card data into unreadable ciphertext. The data is, in theory (again!), impossible to decode unless the recipient has the appropriate key.
Encryption's strength depends on its key: the algorithm used to secure the data. No encryption is unbreakable; it’s simply your algorithm's complexity versus the power of bad actors' computers attempting to break it. Compared to tokenization, encryption obscures your data without actually protecting it.
Tokenization and encryption are not mutually exclusive; instead, each method has its own strengths and weaknesses, which is why they are sometimes combined to further secure data.
How data tokenization works
We've taken a high-level view of tokenized transactions, but let's look closer at a tokenization example:
- I use my credit card at a POS terminal card reader.
- The POS system sends my PAN — let's say it's 1234-5678-1234-5678 — to the credit card issuer's tokenization system.
- The tokenization system generates the random 16-character alphanumeric string a8f6@FUgf80u812! to replace my PAN and records the correlation between the two in the token vault.
- The a8f6@FUgf80u812! token is sent to the merchant's POS terminal.
- The merchant's POS system sends the token to the payment processor, who uses the same tokenization technology to detokenize and view my 1234-5678-1234-5678 PAN to authorize payment.
The exact process depends on the transaction type — online versus in-person versus recurring — and whether the token is used once or is authorized for reuse by the merchant.
The token ID enters the merchant's payment system, not the PAN. If the merchant's POS system is hacked, the only data lost are tokens, which are worthless by themselves because no link exists between tokens and their original PANs.
Types of tokens
No unified classification system exists for data tokens. Even the most cursory web search produces a jumble of widely divergent information about cryptocurrency DTA tokens, credit card security, passwords, and startups selling tokens to raise money.
That said, tokens are generally divided into three categories:
- Payment tokens: Provide access to customer financial information to authorize payments
- Utility tokens: Unlock access to a digital product or service
- Asset tokens: Represent participation in physical companies, revenue streams, dividends, and/or interest payments
These different token types can have features including single or multiuse, authenticable or non-authenticable, reversible or irreversible, and cryptographic or non-cryptographic, or have various combinations of these options.
For credit card transactions, the PCI Security Standards Council emphasizes the distinction between high-value tokens (HVTs) and low-value tokens (LVTs).
1. High-value tokens
An HVT operates as a PAN surrogate to complete a payment transaction, and it is formatted like a PAN. Multiple HVTs, such as one for each account a customer has with different merchants, can link back to one PAN or credit card.
An HVT is considered reversible because entities using or producing tokens can use the HVT to obtain its corresponding PAN from the token database or vault.
While PANs can't be limited to certain merchants, HVTs have this capability. HVTs can also be tied to specific devices and locations, so anomalies will flag questionable transactions.
Last year I bought a new laptop, for example, and the first time I made a purchase at Amazon, I had to reconfirm my identity using a code sent to my cell phone.
2. Low-value tokens
An LVT can't complete a payment transaction on its own. Instead, it can confirm that a given PAN was used via a tokenization system. Or, it can be tied to a customer account without providing access to account information. No matter what, an LVT is irreversible because it will never produce the original PAN.
LVTs are also called security tokens because they protect PANs in specific situations. If a bad actor gains access to a payment processor's system disk drive, PANs may be vulnerable.
Using LVTs internally to protect PANs, however, provides an extra layer of encrypted technology security because they are tied to a tokenization system outside the breached disk drive.
Should your payments system use tokenization?
Tokenization works out of sight and requires no extra effort by your customers or employees. The best reason, however, to use tokenization is the range of transactions protected beyond traditional credit card purchases using in-store POS hardware or a mobile point of sale (mPOS) device:
- E-commerce transactions including one-click checkouts
- Virtual terminal purchases
- Contactless, mobile wallet payments
- In-app payments
- Card-on-file subscription billing
The real question is: Are there any good reasons not to use tokenization as one of your POS features?
Data tokenization equals data security
Arthur C. Clarke wrote, “Any sufficiently advanced technology is indistinguishable from magic," and that's analogous to data tokenization from the best POS systems. You don't have to understand its behind-the-scenes machinations to enjoy the benefit: greater credit card data security during multiple transaction types.