Omni-Commerce Is Heating Up the Merchant Token Revolution

However, with multiple merchant functions requiring access to sensitive data, including card numbers, how can tokens stand in for the real deal?

Defining the token

Many of us remember receiving tokens from our parents at an arcade or amusement park to pay for games and rides or are familiar with chips used in the likes of casinos. These tokens are a representation of money or value only in their respective environments — hence my nephew’s utter disappointment when the Disney coins he had saved up were not accepted at Universal’s parks.

In the context of payments, a “token” typically implies a representation of an actual payment instrument within a defined environment. The PCI Security Standards Council defines tokenization as “a process by which the primary account number (PAN) is replaced with a surrogate value called a token. The security of an individual token relies predominantly on the infeasibility of determining the original PAN knowing only the surrogate value.”

It is critical to note from the PCI council’s definition that a secure token is not an encrypted card number, and it should be impossible to derive, mathematically or otherwise, the actual card number. 

Are all tokens equal?

In short, no. When it comes to payments, several distinct types of tokens exist, and it is important to understand the differences:

Acquirer tokens are generated by acquirers when they process cardholder transaction requests on behalf of merchants and they return the token in the transaction response. The downside is that acquirer tokens tend to require an unhealthy dependency on acquirers.

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, which provides the merchant with a strong degree of comfort in their independence.

Issuer tokens are generated by card issuers and schemes for specific use cases, including card-based applications like Apple Pay, Google Pay and Samsung Pay. These tokens are usually provided to a cardholder’s mobile app, card chip or wallet. An issuer token has significantly broader scope and can be used to initiate payment at multiple merchants during its life span.

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. The tokens are requested on behalf of merchants and cardholders based on specific use cases. Payment tokens are designed to enable end-to-end payments from merchant to issuer, without the need to translate the token to a card number. With payment tokens, the same token can also be used at multiple merchants.

How do merchants retain control and flexibility?

Merchant and acquirer tokens are the more pragmatic tokens for merchants looking to bridge the gap left by the elimination of card numbers from their retail environments. Merchant tokens are the logical choice for merchants seeking to seamlessly handle all their internal functions, as they can define the formats and the usage of their tokens, as well as migrate their tokens to another provider. This token independence fosters innovation and seamless integration of internal and external systems in the merchant environment. For example, merchants using tokens that preserve card number format will not need to alter existing internal or external interfaces because such tokens can be used as seamless replacements for card numbers.

The emergence of an omni-token approach

When utilizing merchant tokens, merchants are best served by engaging a payment platform that can provide the merchant with omni-tokens. When their payment provider is responsible for creating tokens, the merchant will receive tokens for internal use, while the provider will translate the same tokens to card numbers for external payment-related processes like authorization, fraud checks and settlement.

These omni-token can be used across the merchant’s entire payments ecosystem. This is particularly useful for merchants that interact with cardholders across different channels, including eCommerce, mobile apps, in-store lane, in-store kiosk, call centers, remote pop-up locations, etc.

For example, if a fashion retailer received an omni-token for a consumer’s card number when she paid for shoes at the merchant’s eCommerce site, that same token will be used to identify her when she makes another purchase in-store. The store clerk can be alerted to the eCommerce purchase, opening up new opportunities for customer engagement. Likewise, that same omni-token can be sent to the merchant’s loyalty provider and used to compute this consumer’s rewards points, so that a coupon for a free scarf could be sent to her mobile phone app. And, when she calls about returning the shoes, her payment can be easily and smoothly refunded. The accounting department can continue to reconcile and report on all payments in the same manner as it did when card numbers were used. This sort of secure, seamless integration is only possible when merchants partner with suitable payment providers for the provision of their merchant-owned omni-tokens.
The token revolution heats up, so merchants must stay well informed about the different types of tokens available. Selecting the right tokenization solution that aligns with their use cases will not only be critical to making the right token investment but building a customer-centric payments experience.

Make sure to sign up for our new video series that busts payment myths, with the third episode on tokenization released September 12.