A Primer on Tokens, Tokenization, Payment Tokens and Merchant Tokens

Merchants around the world are navigating the world of tokens and tokenization, payment tokens and merchant tokens.

When used properly, tokenization for retail merchants serves a dual use; it can be used to protect sensitive card data, and it can serve as an enabler for omni-commerce. But before deploying tokens, it is important to understand what they are and how they work.

Here, we will delve into the world of tokens for retail merchants. We’ll look at what makes them so secure, the major types of payment tokens and the various token formats that merchant need to know.

Tokens representing value

If you’ve ever been to a casino or an arcade, you’re already familiar with the concept of tokens being used to represent value. In a casino, chips are tokens with different chips representing different dollar amounts. In an arcade, quarters are converted into tokens that can then be used to play games. In each instance, these tokens only hold value at a specific establishment, meaning you could not walk down the street to a different casino or arcade and use these tokens.

Arcade merchants used tokens for several reasons: they centralized the cash exchange, reduced theft and locked the customer into their establishment.

For retail merchants, payment tokens also represent something of value, such as sensitive card data or account numbers. This is the information that is used to authorize payments; an invaluable piece of the revenue puzzle.

But unlike traditional tokens, such as arcade tokens or casino chips, these payment tokens are all unique. Plus, if payment tokens are lost or stolen, you do not lose the value they represent. On the other hand, good luck trying to recover that $100 chip you lost between blackjack tables.

How are tokens created

Now that we understand the basics of what a token is, it’s important to understand how tokens are created. Tokenization is described as the process by which sensitive personal information is replaced with a surrogate value, i.e., a token. That replaced value is stored in a PCI-compliant token vault owned by the token creator, which can be an entity such as an acquirer or issuer.

In order to discover the value of a token, you need to present the token to the creator, and they will look up the original value. When using payment tokens, this value is not returned to the merchant but used to authorize a payment. This way, the merchant keeps sensitive data out of their systems so that hackers can never gain access to it.

Token formats

Tokens can be non-format preserving or format preserving. 

Non-format preserving: The token format is not the same as the sensitive information it is replacing. For instance, if the information happens to be a social security number, any set of values could be used to represent the tokenized value, such as “[email protected]%3N5.” Since this does not maintain the format of a social security number, it is a non-format preserving token.

Format preserving: Here, the token maintains the same format as the original bit of sensitive information, but the values are randomly changed. For instance, a credit card number of “1234 5678 9012 3456” could have a token value of “9687 4595 3211 7312.”

Partial replacement:

Additionally, we can have format preserved tokens where we leave values unchanged. This is common practice for payment tokens and is called selective masking. For example, we could have the same BIN (bank identification number) and last 4 digits of the card number as the original card number, so “1234 5678 9012 3456” could be “1234 5698 3211 3456.” Mixing numeric, alpha and symbols can be done as well.

There are many reasons for leaving part of a token unchanged. The top reasons are for understanding the BIN and verification. Some verification examples are when you call into a merchant and they verify the cardholder by asking for the last four digits of your social security number or when they print the last four digits of your card number on your receipt.  Basically, leaving part of a token unchanged makes the tokens both secure and useful.

Single-use and multi-use tokens

Simply put, single-use tokens are used for a single transaction and expire after the transaction is complete. Multi-use tokens can be used for years to represent the same account across multiple transactions. See, very simple!

What makes a token safe?

According to PCI, the security of an individual token relies predominantly on the infeasibility of determining the original sensitive personal information, while knowing only the surrogate value (token). It is impossible to mathematically derive the original value from a token. You cannot decrypt it simply because it was never encrypted; it was replaced with another value that is stored in a PCI-compliant token vault.

In the event of a data breach, the bad actors will only have access to tokens, which are useless to them. Even if they knew where the token vault was, they would have to figure out how to access it and that is not just a passcode or secret handshake.

So, how safe are tokens then? Well, point-to-point encryption (P2PE) and tokenization are specifically called out by the Payments Card Industry Security Standards Council (PCI DSS) as requirements for protecting payments data in transit and at rest. 

Does using encryption and tokenization together make it safer?

Actually, no. If you use an encryption method to replace the sensitive information, essentially you have only encrypted it, and thus it could be deciphered. Encryption also brings the token back into PCI DSS scope, eliminating a major benefit for merchants. The following is quoted directly from the Information Supplement: PCI DSS Tokenization Guidelines:

“Note that where token generation is based on a reversible encryption method (where the token is mathematically derived from the original PAN through the use of an encryption algorithm and cryptographic key), the resultant token is an encrypted PAN, and may be subject to PCI DSS considerations in addition to those included in this document. The PCI SSC is further evaluating how these considerations may impact PCI DSS scope for reversible, encryption-based tokens.”

As such, tokenization enables merchants to securely provide their customers with the desired payment journeys without exposing customers’ sensitive data. This has the net effect of reducing the PCI compliance burden on merchants.

It should be noted that while tokens can facilitate many things inside a merchant’s environment, including disparate environments or databases, they cannot be used to authorize a payment. This is because a token only represents the current cardholder’s PAN and requires the actual PAN be searched by their third-party provider in the token vault before submitting for payment. For example, if I replaced your Visa card number with the token “cookie,” what would an acquirer do if I requested a $100 payment from the cookie? The acquirer would not even know it’s a Visa card, let alone your PAN.

Current types of payment tokens

There are several distinct types of tokens in payments, and it is important to understand the differences.

Acquirer tokens are generated by acquirers when they process cardholder transaction requests on behalf of merchants. These tokens are typically returned in the transaction response to merchants by the acquirer. Acquirer tokens are typically owned by the acquirer that generated them and can only be used with that acquirer.

Issuer tokens are generated by card issuers for specific use cases, including card-based applications such as Apple Pay, Google Pay and Samsung Pay. These tokens are usually provided to a cardholder’s mobile app, card chip or wallet applications. Issuer tokens do not belong to the merchant, and they may not be as useful within a merchant’s environment to facilitate customer journeys.

Network or scheme tokens are generated by the Visa, Mastercard, American Express, Discover, JCB and China UnionPay credit card networks. Each card network operates its own scheme token service, and thus, the token is similar to the issuer token and is generated by the card network versus the issuing bank.

Payment tokens are a relatively new variant of issuer tokens, generated on behalf of at least one card issuer in a framework known as a token program. These tokens are requested on behalf of merchants and cardholders based on specific use cases. Device specific tokens issued to mobile applications are examples of payment tokens requested on behalf of a cardholder. Payment tokens can be used to initiate payments at multiple merchant locations.

Merchant tokens are generated specifically for a merchant by a provider of its choice. They are generated after a cardholder tenders their card for transaction processing but are owned by the merchant. Since the merchant owns their tokens, they can incorporate these tokens into their customer journeys and business processes within their environments, as well as use them in conjunction with other tokens. For example, a merchant token can be linked to multiple acquirer and issuer tokens, allowing the merchant to support multiple acquirers, as well as issuer tokens. Merchant tokens are primarily multi-use tokens. They are also predominantly format preserving, which implies that they have the same format as the sensitive data the tokens are replacing.

More to come in this tokenization series

We have only scratched the surface of tokenization. Keep an eye out for future discussions on this topic, including:

1. What does PCI-DSS suggest for protecting stored credentials?
2. Can you share sensitive data without worrying about PCI compliance?
3. Meet the true enabler of omni-commerce.
4. How do merchant omni-tokens differ from other payment tokens?
5. Is 2022 the year of the token?
6. One token to rule them all!

For more information on tokenization,  watch this three minute video on merchant omni-tokens, read our executive’s guide to tokenization or explore ACI’s tokenization capabilities.