MAG Insights

You may have noticed an increase in the number of articles written regarding the use of tokens to protect payment credentials at rest.  If you are new to the industry, you may even be led to believe this is a new revelation that will change the face of fraud for online transactions. The reality is tokens have existed almost as long as the card industry itself.

The first major use of tokens was with the issuance of debit cards. Debit card numbers act as tokens to routing and account numbers. When the financial institution sees the card number, they convert it back to the account number to post the transaction.

The next big push for tokens in the payments industry was at the time the Payment Card Industry (PCI) issued its Data Security Standards (DSS). For those of you not familiar with PCI (to learn more about PCI and other standards bodies that impact payments, check out these MAG Insights articles:  ISO and X9, PCI and W3C, FIDO and EMVCo), it is a collaboration of the major global card brands, which issue rules to create consistency on how card data is used by the merchant community. While PCI issues the standards, individual card networks propagate the specific rules merchants must follow. One of PCI’s first rules focused on how merchants are required to protect stored card information. When these rules went into effect, merchants were left to their own devices to figure out how to comply. This is the point at which many merchants worked internally or with a partner to create security tokens and token vaults.

Essentially, merchants replaced a card number with a security token to be used in their overall infrastructure. The merchant would translate that security token back to a card number only when it was sent to the financial institution for processing. This allowed merchants to de-scope much of their infrastructure from the PCI rules and narrowed the gateway through which fraudsters could exfiltrate stored card information. This system has worked well and has resulted in a more secure online environment for electronic transactions.

This brings us to the most recent push for the use of tokens. Recent news reports and industry discussions are referring to network tokens or network payment tokens. Instead of the token being generated and stored somewhere within a merchant’s payments infrastructure, it is instead created at the network level. These network tokens are intended to protect payment credentials at rest and between the merchant and the network.

Network tokens enter the payments infrastructure in several different ways. The first major entry of network tokens was with the implementation of digital wallets. Instead of storing the actual payment credentials, these wallets (such as Apple Pay and Google Pay) store a representation of the account number in the form of a network token.

The next development in the use of network tokens was in the ability for merchants to request a network token when they planned on storing account numbers. In this case, the merchant would send the card information with the request for a token, and the network would send back the token which the merchant would store and use for future transactions. 

We are now seeing the replacement of account information move further upstream before the information is even presented to a merchant. The networks have announced initiatives with web browsers (such as Google Chrome) to replace the actual card information with either tokens or virtual cards when autofill is used on a merchant checkout page. Today, when card information is auto-filled into a merchant’s checkout page, the native account number is used. Going forward, a virtual card number or a network or issuer token will replace the actual card in the autofill process.  Questions remain on how this process will work by network or issuer and whether all card products will be converted or only credit-based products.

Merchants do have an opportunity to opt out of this autofill process according to Visa and Mastercard, but it is unclear how the process will work. Merchants should talk with their acquirer if they prefer to continue receiving the native account information. In addition, merchants choosing to opt out must opt out fully as an all-or-nothing – meaning they cannot choose to receive virtual cards for some transactions but retain PANs for others. The opt-out remains at the payment checkout page URL only and is not differentiated by card product type.

While there are benefits to using network tokens, such as the ability to avoid the recent 10 bps increase in interchange by Visa for online transactions, there are also other factors merchants should consider. For instance, if a merchant chooses to route their debit transactions to alternative networks, they must first have the token converted back to the original card number by the network which issued the token). In many cases, when this conversion happens all the data used to authenticate the transaction is not returned. This could result in lower approval rates or qualification downgrades by the issuing bank. In other cases, the network does not allow tokenized debit transactions to be routed to an alternative network, meaning a merchant that chooses the security of network tokens must forego their debit routing rights.

Recently, Visa published a bulletin that created a process for merchants to receive fraud liability shift when processing online transactions with its network token. While there are many questions outstanding regarding the qualification requirements, this shift will add more protection to a merchant when choosing to use a Visa network token and potentially higher approval rates.

With all these changes regarding tokens, what is a merchant to do? Let me point out a couple of considerations:

1. Understand how you currently use card information and ensure, no matter which direction you choose, you have a plan to maintain those uses. For example, tracking a customer when they use the same payment device in-store and online.
2. Consider what flexibility you lose based on which token process you choose. When you move to a network token it means the network that issued the token must be involved in the transactions even if they are not the processing network.
3. Examine the effects the token process might have on your cost of processing transactions. This look should include the ability to route debit transactions, the cost of fraud, and the overall customer experience and support process.
4. Think long-term when considering implications as history has proven when you become locked into a third-party process or product you become beholden to any future changes that party makes.
   

As the MAG considers these recent changes, we see a path for further collaboration among the industry to increase security while maintaining the flexibility and competitiveness in debit routing. For instance, we have submitted use cases to EMVco regarding a token flow in which the token providers sit behind the issuer instead of in front of them. This would allow routing of any network token to be sent through different networks where the issuer would then call out to their chosen provider to detokenize the transaction. We are also working with various networks to create an industry solution for all necessary data to be passed when a transaction is detokenized, regardless of where the transaction is ultimately processed.  This will level the playing field and provide greater overall security. Finally, we continue to reach out to all the parties in the ecosystem to create a global process that would include all parties.  

Creating and maintaining a secure and competitive payments system is critically important to merchants, and together we can bring solutions forward to solve industry problems without tilting the balance of the playing field.