With all the excitement about ApplePay, big systemic problems are starting to surface on the retailer side. Here they are:
a) Point to Point encryption confusion – Some vendors who certified their payment card applications for point to point encryption left out certification of the contactless payments since there was very little volume in the past and they just didn’t get around to it.
What this means is that any contactless payment presented to their NFC readers is ignored by the point to point encryption process and the transactions go into their own ‘suspense’ bucket. Retailers need to be aware of this and work with service providers to implement a compensating payment process flow accordingly.
b) Token collision – ApplePay uses a tokenization scheme supported by Visa and MasterCard which have not released the numbering scheme they use. (Essentially their tokens are pseudo card numbers with pseudo BINs (bank issuing numbers) at the front so they know which card issuer process to route the data to when it comes into their network).
But this system collides with the merchant or acquirer based tokenization systems the merchants have spent so much money on over the past years in order to secure card data and limit the scope of their PCI audits.
Here’s why the tokenization systems collide: An ApplePay token will be presented to a merchant tokenization system. The merchant tokenization system will simply tokenize the Apple Token and store that tokenized token in their system for future use since there is no way for the system to distinguish it’s an Apple token and not a credit/debit card.
What are the consequences?
a) Merchants could end up with two tokens for one card number
b) But more importantly, merchants now have an ApplePay token and no process to get back to the card number. They have no interfaces with the ApplePay token/detokenization system. The whole reason merchants tokenize card data is because they need to get back to the card number at some future point, usually for chargeback and dispute purposes or for recurring billing.
What’s the solution? Big token mapping tables in the sky? Seriously. And Messy. Someone– likely the acquiring processor or even the card brands — is going to have to provide merchants with a table that maps their token numbers to the card issuers’ token numbers (first brought to market by ApplePay). This doesn’t bode well for on premise solutions unless they can be tied directly somehow into these monstrous mapping tables.
More Security Problems: One other piece of interesting information I came across with regards to ApplePay is that the one time code numbers that are part of the security scheme are not being accepted or read by terminals and their payment acceptance protocols. At least not yet and not universally. This means that if an ApplePay token is stolen from a merchant, it can be used at another merchant accepting ApplePay, assuming the consumer doesn’t have to use their TouchID biometric to confirm the payment instruction and a hacker somehow steals the consumer’s password. ApplePay token numbers are the same across merchants since they are issuer based.
Retailer Vs. Card Networks – Interests Continue to Collide: What all this says to me is that retailer interests and card issuer interests continue to collide. It would have been nice if all this had been thought through at the beginning of PCI planning and rollouts and if tokenization standards were developed and implemented years ago so that we didn’t have to face this collision going forward. It’s only going to get more confusing and messy in the years to come before it straightens out.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.