Tokenization & Ticketing: 5 takeaways

Written by: David Bakker

May 9, 2016 - The connection between EMV in transit and tokenization

In 2015, UL published a whitepaper on tokenization (please see here if you did not read it!). Basically, tokenization means that the real PAN of a (mobile) payment card is replaced by a surrogate, called the token. The token can be mapped back to the real PAN by a Token Service Provider (TSP), but the TSP will only do so if the token is used in the expected environment. That is, a token meant to be used from a cloud-based payments application on a mobile phone will not be usable in a card-not-present transaction.

Tokenization is quite hot at the moment, because it offers a possibility to fight fraud not by keeping the PAN secret, as PCI does, but by not storing the real PAN on a card in the first place. That’s why Apple Pay uses it, and many mobile payments initiatives are expected to follow soon.

At the same time, finally ‘EMV in Transit‘ is getting traction. EMV in Transit is about using your debit or credit card directly for paying your trip in public transport. After all, why should public transport operators (PTOs) use a dedicated closed-loop payment system, if the large majority of their customers already have a contactless payment card in their pockets? This idea was first implemented on a large scale in London, and is now being seriously considered by PTOs all over the world.

So what’s the connection between these two developments? Five things to keep in mind about tokenization when you’re planning to accept EMV at your transit terminals:

  1. Tokenization is coming and you don’t have a say in it. You will not be able to distinguish between cards carrying a real PAN and cards carrying a token. And because of your very special transaction flow compared to ‘normal’ merchants, you may actually experience some problems from it; see #3 below. You should design your ‘EMV in Transit’ system in such a way that you can deal with tokenization.
  2. You are going to store some identifier for your customer’s card on a blacklist, in case an authorization request for that card is declined by the bank. After all, a non-paying customer is not a customer, and should not be let in. You also need such an identifier for doing journey reconstruction, customer care and other useful stuff. You may be tempted to use the PAN or the token (= the PAN surrogate) of your customer’s card for this. Don’t do that! The point of a token is that is not the real PAN of the customer, and it may actually change. So it’s not a good identifier. Moreover, using the PAN means that your terminals (and at least all locations where you store that blacklist) come into scope of PCI. Be aware and afraid of that. Instead, you should use a non-reversible token derived from the PAN as the card identifier on your blacklist and other transit-specific systems. A non-reversible token is different from a reversible ‘EMV-type’ token, in that it is impossible to get the original PAN back if you only the token. Hence, they are a lot less interesting for the bad guys, and thus also for PCI.
    Using a cryptographic hash of the PAN is a good starting point for a non-reversible token. PCI has some specific requirements for non-reversible tokens though [1], and an important one is that it must not be possible to create a ‘PAN oracle’ by simply hashing all possible PANs and make a lookup table. This may be tricky, since the standard solution for that –salting the hash– is not usable in the transit context since it results in a different identifier each time. Whereas you want the identifier for the check-in and check-out transaction to be the same, such that you can do a proper journey reconstruction.
    Another option is to avoid using the PAN at all, even in hashed form. This this the purpose of EMVCo’s newest idea: the Payment Account Reference. See #5 below.
  3. Be aware that a customer may use multiple tokens, all pointing to the same payment account. For example, a customer may enroll his credit card (with the real PAN) into Samsung Pay, Google Wallet and PayPal Pay, and get a different token in each case. From the customer’s perspective however, each device contains the same card. Therefore, they will be tempted to use them interchangeably. But when a customer checks in with one device and checks out with another, journey reconstruction is impossible and the customer will be charged for the full fare twice. Customer propositions such as daily capping face similar issues. At the same time, it also means that if you as a PTO block one of these tokens, the customer will still be able to use one of his other virtual cards. Presently, I’m afraid there’s not much we can do about that, but a solution might be just around the corner though (see #5 below). For the time being, perhaps you could entice your customers to register all of their tokens with you, for example in exchange for some fancy bonus program. If so, you can block all of these tokens in case you discover that the associated account is empty.
  4. Pay attention to tokenization when doing debt recovery. Debt recovery will be necessary in case the bank declines your initial authorization request. After all, you didn’t have the time to wait for the authorization response before you let the customer in. So that customer is happily travelling on your system, but you don’t have your money yet. Therefore, you will have to initiate a ‘deferred authorization’ transaction once you know how much the customer travelled for. And for that, you need the PAN or token you read from the card. Some attention points:
    a. You will need to store the PAN or token in some central system. Use a PCI-compliant system for that. Using a PCI-certified Point-to-Point (P2P) Encryption system might be a good idea. In such a system, the PAN is only known in your (PCI-certified) terminals, and the terminals encrypt all sensitive data before sending it to your back office systems. You don’t have the key to decrypt them. In fact, you just pass the encrypted authorization request on to some PCI-certified payment service provider. They will decrypt the request, change the transaction amount as instructed by you, and forward to the issuing bank.
    b. Be aware that tokens may change. Technically it is completely possible for a bank to provide a new token to a mobile payment application at any given moment, and to discard the old token. That means that the token you have stored in your central system may not be valid anymore if you wait too long with sending in your deferred authorization request. To be sure, none of the payment schemes today have specified that tokens should be changed during the lifetime of the mobile card, so the chance that this happens is very low for now. But that may change.
  5. EMVCo has recognized a number of these issues (primarily #2 and #3) and has introduced the concept of the ‘Personal Account Reference’ (PAR) [2, 3]. The PAR is a new data element in an EMV application, intended as a unique and static account identifier. It will be the same on every card and payment token associated to an account. However, the PAR by itself cannot be used to make any payment and therefore does not require a high level of security. Which means PCI will not come along and haunt you if you use it for your blacklist, journey reconstruction and customer care. (Problem #2 above solved!) Moreover, the PAR will allow you to link different payment tokens from the same account and enable your customers to use whichever EMV product they want interchangeably, whether it is a card, mobile or other smart device. (Problem #3 solved!) We expect that all payment applications will soon be required to be personalized with a PAR. In fact, MasterCard has already announced their support for PAR [4]. If you are in position to specify requirement for your next-generation transit terminals, be sure that they can handle the PAR. It will save you a lot of headaches when introducing EMV in Transit.

 

Sources:

[1] https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf 

[2] EMV specification Bulletin No.167, First edition January 2016

[3] EMV specification Bulletin No.178, First edition March 2016

[4] MasterCard Announces Support of the Payment Account Reference Specification, Global Operations Bulletin No. 3, 1 March 2016

Disclaimer

These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.