Tokenisation in Payments

ApplePay has introduced the concept of tokenisation, as it applies to card-based transactions, to mainstream audiences. Friends that had never heard of tokenisation prior to ApplePay have the impression that it is yet another genius invention of Apple. Tokenisation is of course nothing new. Cash is a token that most of the world uses on a daily basis. But when we talk about tokenisation within an EFTlab article, we’re certainly not talking about cash. What we’re talking about are Payment Tokens.

Payment Tokens, as used here, are effectively stand-ins for a card number, or PAN. They work much the same as “chips” you might get at a casino. You come to the casino, you give them something of value (your cash), and you get tokens, or chips, in return. The casino desk, where you exchange your cash for tokens, and vice versa, is secure and well guarded. If you try to take chips from one casino to another, unrelated casino, your tokens have no value there. To get the value of your tokens, you need to go back to the casino which issued them, and ask them to exchange the tokens for cash.

That is largely how tokenisation works, or can work, in payments. There are important similarities, but important differences as well. The chips are analogous to tokens. The casino desk is analogous to a token vault. The fact that tokens are worthless at an unrelated casino is critical. The fact that the gaming tables agree to honour the tokens at the casino that issued them is critical. But there are important differences as well. In a casino, the token is not only valuable to the person who initially was issued the token, but it has value for anyone else in the casino as well. For a payment token, we wouldn’t want another person in possession of your token to be able to use that token, or we’ve defeated a primary purpose of tokenisation. Exchanging the chip for currency at the casino desk is akin to detokenisation.

For payment systems, it is important to take a closer look at the statement “The fact that the gaming tables agree to honour the tokens at the casino that issued them is critical.” For payment tokens, the token has to be able to behave enough like the “real thing”, so as to not break the process. Here is where the format of a payment token may be different depending on the system processing with that token; what constitutes “has to be able to behave enough” like the “real thing” can change based on what system is processing the payment at the point the token is being used. We could issue a casino chip as a token for a payment card, but existing payment systems can’t process a casino chip. The token needs to look enough like a card to behave enough like a card, until it can be safely detokenised. Per the EMVCo specifications, this can be done by using distinct BIN ranges to denote tokens, but there are other options as well.

You may be thinking that with other improvements in payment card security, tokenisation doesn’t provide value. You’d be wrong. When securing your home, it doesn’t make sense to put another lock on the door, if you’re leaving a window open. PCI has put more stringent security on systems that utilize card-holder data, and EMV brings more security to card present transactions. Encryption has become more sophisticated, and communications which transport card-holder data have become more secure. But wherever card-holder data is stored, there will be evermore sophisticated agents trying to get at that data. By using tokenisation, you can make that card-holder data someone else’s responsibility.

At EFTlab, we understand tokenisation, and we understand how to deploy tokenisation into your environment in as non-intrusive way as possible. If you’re current switch or processing platform doesn’t support tokenisation, why not utilize a platform that does? Read More >>