New European Commission settlement forces Apple to open iPhones to NFC ‘tap and go’ via alternative wallets.

During the second half of last month, I decided to take a closer look at Apple's 14th August announcement that the IT giant will allow app developers to offer NFC contactless transactions using Secure Elements (SE) from within their own apps.

Starting with iOS 18.1, developers will now be able to access the NFC and SE to offer contactless transactions from within their own apps on iPhone, separate from Apple Pay and Apple Wallet. But the big question remains: 'Will Apple grant SoftPOS players unfiltered NFC access?'. Let's take a closer look at the importance for the SoftPOS market.

EU Commission findings

The Commission was concerned that Apple had too much control over which mobile wallet Apple iPhone users could use because it reserved the use of the Near-Field-Communication (NFC) technology on its iPhones for its own mobile wallet solution Apple Pay. Basically, before this ruling iPhone users, which only use Apple’s operating system iOS, had to use Apple Pay for Apple Tap-to-Pay contactless transactions.?

Apple controlled every aspect of its ecosystem, including access conditions for mobile wallet developers. The EU found, this behaviour prevented developers from bringing new and competing mobile wallets to iPhone users. Such behaviour was ruled to be in breach Article 102 of the Treaty on the Functioning of the European Union (TFEU), which prohibits the abuse of a dominant position.

As we know, mobile wallets allow for payments with a mobile device in shops and online. They also integrate with other services, like loyalty cards, contactless tickets for events, boarding passes and digital identity credentials. In the last four years, mobile wallet usage in shops in Europe has tripled.

In Europe, the most widely available technology for mobile payments in stores is NFC. NFC technology was not developed by Apple. It is a standardised technology which is made available for free. Compared to other technologies, like payments using QR codes, it allows for the safest and most seamless mobile payment experience. To develop viable mobile payment apps, access to NFC technology is therefore essential.

Apple iPhone opened up access to other wallets but has not extended it to SoftPOS yet

As part of its agreement with the EU, Apple made 12 key undertakings. However, it is worth beaming in on #6 of this list which I’ve highlighted in bold below:

1.?????? Give access to NFC functionality to third-party mobile wallets. This access will be free of charge. This access will take place in what is called Host Card Emulation (HCE) mode. This is a software solution that allows rival wallets to make secure NFC payments. Apple Pay, on the other hand, relies on access to the hardware ‘Secure Element’ in the iPhone.

2.?????? Enable access to important functionalities available on iPhones. This includes Double-Click and Face ID. iPhone users will be able to double-click the side button of their iPhones to launch their preferred payment application. Competing wallets will also be able to use Face ID, Touch ID and passcode to verify users’ identities.

3.?????? Enable users to make the wallet of their choice the standard option on their iPhones. This is also known as setting the default option.

4.?????? Allow developers from combining NFC payments with other use cases, for instance transit cards, access control, concert tickets and digital identity credentials. Everything that you could have in a wallet.

5.?????? Cooperate with a fast dispute resolution mechanism, which will also allow for an independent review of Apple’s implementation.

6.?????? Extend the possibility to initiate payments with HCE payment apps at other industry-certified terminals, such as?merchant phones or devices used as terminal?(so called SoftPOS), if this is enabled.

7.?????? Explicitly acknowledge that HCE developers are?not prevented?from combining?the HCE payment function with other NFC functionalities or use cases.

8.?????? Remove?the requirement for developers to have a?licence?as a Payment Service Provider (PSP) or a binding agreement with a PSP to access the NFC input.

9.?????? Allow?NFC access for developers to?pre-build payment apps?for third party mobile wallet providers.

10.?? Update the HCE architecture to?comply?with?evolving industry standards?used by Apple Pay, and to continue to update standards even if they are no longer implemented by Apple Pay, under certain conditions.

11.?? Enable developers to prompt users to easily?set up their default payment app?and?redirect users to the default NFC settings page, enabling defaulting with only a few clicks.

12.?? Comply with the same industry standard-specifications as developers of HCE payment apps and to protect confidential information obtained in the context of an audit.

These commitments are applicable to users registered in the European Economic Area, including when they travel abroad, and will remain in place for at least 10 years. iPhone users will now be able to use their preferred mobile wallet for payments in stores. They will be able to do so while enjoying all the iPhone’s functionalities including tap-and-go, Double-Click and FaceID.

However, it’s also interesting to note (see point #6 above) that the possibility to initiate payments with HCE payment apps at other industry-certified terminals, such as merchant phones or devices used as terminal (so called SoftPOS), is not yet enabled.

Unfiltered card-read on iOS is the key for native SoftPOS support

We are seeking clarity from Apple in a few areas relevant to this point right now. For example, it’s currently unclear whether developers will be able to read payment card data without the current payment card filtering that Apple imposes. It’s important to distinguish here between being able to send data (data-send) to a payment terminal like Apple Pay, versus being able to read card data directly (card-read) on an iOS device (Apple Tap-to-Pay). For Mypinpad’s various ‘Tap-to-everything’ products, it’s critical that unfiltered card-reads on payment cards are possible.

Our overarching goal is to offer these products on iOS similar to our existing Android offerings. However, to date Apple has limited our iOS access to that of being an Apple Gateway Service Provider (GSP) certified for provision of SoftPOS services - preventing us from direct development of NFC under iOS. However, if we are granted unfiltered NFC access we will invest to adapt our kernel set for iOS and prepare our products to work on other operating systems over time.

How will our technology work with iOS if unfiltered NFC access is granted by Apple? After a card-read, the payload will be sent to the same backend used by all other Mypinpad solutions allowing us to deliver a device agnostic service to our customers. Functions such as tap-to-add, tap-to-confirm, tap-to-verify and tap-to-own-device (subject to card scheme approvals) will become much more widely available.

If our talks with Apple go well, we’ll be moving ahead to formal registration and securing necessary permissions to advance development of our ‘tap-to-everything’ features for iOS device users as quickly as we can.

Needs to deliver ease of use for acquirer, PSPs and merchants

Apple iOS is a big piece of the contactless payments market - of that there is no doubt. However, in order to have a payment acceptance solution with wide appeal what you really want is software which handles both iOS and Android transactions seamlessly. Sophisticated SoftPOS players, of which we are one, have built this consolidated offering across both mobile operating systems.

There is a lot of integration complexity under the hood but the power is in being able to consolidate your offering to the point that our customers - the Acquirer and Payment Service Providers (PSPs) serving the merchants - can offer one contract providing a single view of all transactions regardless of which mobile device enabled it.

It ought to be possible to have a single application using a framework which is on both platforms. Both the ‘look and feel’ at the front-end and the integration at the backend needs to be similar – and we now know this is what customers really want.

For mobile app developers, it’s also important that the way in which they are able to integrate SDKs to make a solution work, is similar for both Android and iOS. That is why we don’t just stop at the SDK-per-OS level, but rather assist Devs with a Flutter-based SDK so that they can develop a single app for both iOS and Android - providing the most seamless experience for users possible.

In summary, the ability of service providers like us to offer high quality, highly reliable and secure consolidated, multi-device, payment acceptance customer experiences is the key to extending mobile digital payments acceptance. The winners in the paytech market will be the ones that deliver a memorable, seamless, even fun user experience. Indeed, our focus today is already on making our technology easy to access and use for developers, merchants and end-customers alike.