Written by Contactless Card Acceptance
Solutions to enable Android phones to be used to accept EMV contactless card payments without requiring additional hardware have been around for a while. We’ve been advising and helping our clients architect, secure, build and certify SoftPOS solutions for the last 5 years. However, this has not been possible on iOS devices, until now. Speculation that Apple was looking to add contactless payment card acceptance support to iPhone grew when they bought Mobeewave for $100MM in 2020. Based on the technology acquired in this purchase, Apple has recently added contactless card acceptance capability by implementing their Proximity Reader framework to iOS 15.4, for what Apple calls Tap to Pay.
A Very Appley Implementation
A quick look at the developer guide for this framework suggests that Apple has added this feature in a very Appley way. They prohibit managing communications with payment card applications using the Core NFC framework at the individual EMV command level (ISO7816). This means that developers cannot manage EMV sessions themselves, and cannot implement their own choice of contactless EMV Level 2 kernel.
Instead, Apple requires developers to use the Proximity Reader framework, whereby iOS manages the EMV interactions with the card. It appears that Apple have implemented some EMV Level 2 kernels in the iPhone’s SE (Secure Element). Furthermore, it looks like the payment data resulting from the card transaction is encrypted in the SE with the PSP’s (Payment Service Provider’s) key creating a secure channel from the SE to the PSP, meaning that the REE (Rich Execution Environment), the place on an iPhone where apps run, and the POS app itself, can never see the EMV payment data.
“All transactions made using Tap to Pay on iPhone are encrypted and processed using the Secure Element” from Apple’s initial press release.
This potentially means that creating a POS (Point of Sale) application on iPhone is simpler than on Android where all of the EMV processing is generally done within the app, with developers having to implement advanced security techniques such as White Box encryption, or using the Trusted Execution Environments (TEEs) that are built into many mobile phone processors. Furthermore, Apple’s approach is likely to make PCI compliance for the app developers relatively straightforward.
The downside to this approach is that only payment card types that Apple has decided to support, by way of implementing their EMV Level 2 kernels, can be used with Tap to Pay. At this point it is unclear which of these will be available.
Apple’s implementation of Tap to Pay follows the PCI CPoC standards according to their developer documentation. Also, the initial implementation seems to be US only. Consequently, we do not believe that the solution will support PIN entry, and so as it stands would not be suitable for use in Europe where PSD2/SCA may require payments with contactless cards to require PIN entry.
Given that the solution is presented as a set of APIs that can be called, rather than as a complete payment application, it is likely that any developer that leverages the Proximity Reader framework will have to go through a certification with the network before deployment, albeit to a cut down set of requirements as the framework provided is likely to cover many of the requirements itself.
The final Appley thing about the implementation is that only PSPs that have been permitted by Apple to support Tap to Pay can be used by anyone wishing to implement a Tap to Pay solution. As of writing this is limited to only two PSPs, Stripe and Adyen , and they only have “sign-up for information” pages currently live. However, we expect more PSPs to implement Apple Tap to Pay over time after a relatively low-key initial implementation period.
Conclusions
Overall, Apples first implementation of EMV contactless card acceptance on iPhone is probably what we should have expected. It’s more limited in flexibility than what can be achieved on Android, and abstracted from the developer, but this enables them to ensure a focus on security and privacy exhibited through the use of the SE and the secure channel to the PSP.
Apple tends to enter markets for the long haul and mostly only implements significant new features as part of a strategy that it sticks with and iterates. They also have a tendency to implement payment features that integrate with third parties with only a small number of initial partners, expanding this over time, as we have seen with ApplePay. We expect to see a relatively slow rollout of POS apps supporting Tap to Pay initially. However, we expect more partner PSPs to be added over time. We also expect Apple to iterate their solution to eventually enable support for PIN to enable deployment in Europe, but this may be a couple of years out and dependant on learning from the initial US implementations.
Finally, there is plenty of speculation to be had about what Apple’s long-term intention may be here, given that they already offers their own cards (Apple Card and Apple Cash) in the US. One might speculate that at some point Apple intends to join up both sides of its card processing solution to create something akin to a payment network… but that’s a blog post for another day.
