20th October 2014
It’s been a long time coming, but today is finally the day we can say NFC mobile payments has arrived.
Android handset manufacturers have of course supported NFC for a long time, but the secure element based payment solutions seen to date, struggled to make it beyond the Pilot/Test phase. That changed last year when Google announced the inclusion of Host Card Emulation (HCE) in the Android KitKat OS. This singular move transformed the mobile payments landscape, bringing new opportunities to service providers to deploy mobile NFC payment solutions on a commercial scale, obviating the need for the hitherto complex secure element ecosystem which required commercial co-operation between SPs, Mobile Network Operators, SIM vendors and Trusted Service Managers.
HCE has its challenges and still has to prove itself, but it is certainly less complex with an easier route to commercial stardom than the previous secure element approaches. But even so, even with the relative clear blue water ahead now that HCE is endorsed by the card schemes, doubts remained in many people’s minds about the future of NFC payments, people who would echo the oft repeated mantra “Ah but what about Apple?”.
It’s all well and good deploying a solution on Android, they would say, but what about those banking customers who use iPhone? And with many of the key decision makers in the banking boardrooms being iPhone users and Apple fans themselves, this question wasn’t going away.
Until now that is, because today we are witnessing the debut of Apple’s own NFC mobile payments solution, Apple Pay, which is being launched in the US with over 500 banks and the full backing of both Visa and MasterCard. In just over 12 months, NFC has gone from a dirty word to once again being the key enabling technology for future mobile proximity payments.
Nevertheless, despite the hype surrounding the Apple Pay launch, service providers are still left scratching their heads, as many questions still need addressing.
Apple Pay (US version) involves card scheme tokenisation and an embedded Secure Element. MasterCard have recently unveiled MasterCard Digital Enablement Service (MDES), their own in-house tokenisation platform, whilst Visa have announced their Visa Tokenisation Specification (VTS), and these token platforms form the rails over which Apple Pay will operate. MDES and VTS replace the plastic card 16 digit PAN number with a token. MDES and VTS validate the token transactions and map the token back to the PAN before forwarding to the issuer for authorisation. As these tokens can be dynamic (e.g, can be locked to a specific channel or device) it provides an additional layer of security whilst ensuring the user’s true 16 digit PAN number remains hidden, and in the event of a security breach, the link between the token and the card PAN can be decoupled and a new token reissued, protecting the true identity of the end customer at all times.
Apple Pay (US version) uses an embedded secure element as the place to store these tokens, but tokenisation doesn’t necessarily require a secure element, and there is no reason why tokenisation services could not be applied to Host Card Emulation (HCE) architectures as well.
This raises some interesting questions for service providers:
We don’t know how Apple Pay will look or even when it will appear outside the US yet, and so it will still be some time before we see how banks can bring payments to the iPhone platform in Europe and beyond. In the meantime however, HCE is available on Android, and it is endorsed by Visa and MasterCard, which means there’s nothing stopping banks deploying HCE based mobile payments services right away, and with an 84.7% Android market share globally, that sounds like a pretty shrewd place to start (in Q2 2014 Android had 84.7% global market share and iOS had 11.7% – source: IDC, 2014 Q2).
Andy Ramsden – Director of Payments