The payment industry’s responses to ongoing payment security concerns are many. We have procedural approaches and technical ones. For example, we are requiring merchants to attest to their compliance with PCI security standards that themselves include procedural requirements.
Technical solutions are also called out by PCI and are, of course, being applied across the ecosystem. Encryption of payment data in flight is one approach. In the physical POS world, semi-integrated POS terminals connect directly to the acquirer’s front end instead of passing card transaction data back through the merchant’s workstation and enterprise system.
An important technique, and the topic of this discussion, is tokenization.
Tokenization is an ancient security technique. In the broadest sense, a token is just a dummy representation of something of higher value.
In cards, that means the replacement of a PAN with a number or even an alphanumeric value that represents the underlying PAN. The mapping between the two is stored in a vault with the owner restricting access to that vault. If a hacker gets ahold of a token value, it’s useless. It’s a value that, to the payments ecosystem, is gibberish.
Tokenization is used in pull payment systems where payment credentials are given to the payee by the payer so that the payee has the information necessary to go get the money. Think card numbers or the routing and account numbers on a check.
In card payments, there are two forms of tokenization: merchant and issuer tokenization. Merchant tokenization has been around for more than a decade. A response to PCI, merchants generally outsource that token vault to a third party so they no longer store PANs themselves. When the merchant needs to do a lookup or initiate another payment, the merchant sends the token to the upstream service provider who then looks up the PAN and sends it off for authorization by the acquirer.
That’s been around for awhile.
The newer innovation is what we call issuer tokens – token values that are at the heart of Apple Pay, Google Pay, Samsung Pay and more. These token values are real card numbers, issued by your bank, but unlike a PAN that can be used to initiate a payment everywhere, issuer tokens are expected to come, for example, from specific devices or merchants.
Every card in your Apple Pay wallet is represented by an issuer token and whenever that token is presented for authorization, data about where it’s coming from is sent along too. If the token is sent from another device, for example the one the hacker has, authorization will fail.
This approach is totally compatible with the current card payment system. No changes are needed at the merchant or the acquirer and minimal ones at the issuer.
Glenbrook will be conducting an Insight Webinar on December 13 called Tokenization Fundamentals. Russ Jones will conduct that webinar.
In this Payments on Fire podcast, George talks with Russ about issuer tokenization, its role in the Pays (Apple Pay, Google Pay, Samsung Pay), in eCommerce, and the need for new entities in the payments ecosystem to support tokenization. This gets complicated. There’s now the need for token gateways.
Take a listen to the podcast and then sign-up for the webinar. Use the code POF80 to take 10% off the registration price.
