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:
- Firstly, how will ApplePay work outside the US? The commercial challenges Apple faces in Europe are very different to North America, where (it is claimed) Apple will take 15 basis points from each transaction. In Europe, the interchange rates are significantly lower, and with little/no margin to play with, it’s still unclear how, and from where, Apple could derive similar revenue. A different commercial model may force a different technical solution outside the US, which may or may not include an embedded SE.
- Secondly, will Android handset manufacturers, notably Samsung who have a hugely dominant market share, try to adopt a solution and architecture similar to Apple – embedded SE with card scheme tokenization, or will they choose to leverage Android’s HCE features to further increase reach (many NFC Android devices don’t have embedded secure elements).
- Service Providers, such as banks, obviously want to deploy mobile solutions to ALL their client base, irrespective of the client’s smartphone type, and whilst it’s great news that Apple have joined the party making this now theoretically possible, it may well mean banks have to adopt different solutions – one for their iPhone customers and another one for Android.
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
The post Mobile Payments – Why wait for Apple? appeared first on Proxama.