Apple Pay monopoly, are we really comparing “Apples” with “Apples”?

Image source: CNET


It has been a lot of criticism on “Apple not opening its NFC chip” ever since Apple Pay was launched in 2014. Many markets, including Australia and Germany, have tried to fight for such “openness” in the past years. Recent announcement of EU Commission´s antitrust investigation on Apple Pay again put this topic back to the hotlist. There are, however, quite some misunderstanding on what the actual issues are, as the market may have many misconceptions of NFC mobile payments and hence Apple Pay. Moreover, people may have underestimated the complexity of NFC mobile payments and hence overestimated the benefits of a completely open ecosystem.

This article aims to provide a neutral view on what the real problems are, especially try to explain what is actually “closed”, what can potentially be “opened”, and most importantly what are the potential impacts depending on different potential “opening” options.

Market trends

Before diving into Apple Pay specific discussions, it may worth to highlight a few trends and/or facts in today’s mobile payment markets.

  1. Exponential growth of NFC mobile payments: Wide contactless terminal adoption is fuelling the high growth of NFC mobile payments globally. In the most mature markets, such as Europe and North America, transaction volumes are believed to have moved from a linear development to exponential growth in the last 18 months
  2. Consumers prefer solutions from tech giants: we have noticed that many Bank-branded (NFC) wallets are gradually phasing out, either being completely close down or offered in parallel to xPays (e.g. Apple Pay, Samsung Pay and Google Pay) with reducing focus over time
  3. xPays are challenging local solutions: over the last 12–18 months, we have also noticed that xPays, especially Apple Pay, are overtaking the markets once the majority of the banks are onboard. Consumers prefers to use Apple Pay, even in markets where local solutions (based on other technologies) have been dominating for many years, due to the strong brand awareness and superior performance of the NFC technology

Understand the basics

What actually is Apple´s NFC chip, and Apple Pay?

First of all, Apple´s NFC chip is not one chip, but an ecosystem consisting of seamlessly integrated hardware & software, as well as backend & frontend.

Figure 1. Apple Pay ecosystem in a nutshell

A very high-level picture of the Apple Pay ecosystem is shown in Figure 1. Apple uses a dedicated chip, called secure element (SE) to host the payment applications. Current supported technologies including contactless card (EMV), transit cards (MIFARE and Felica) and ID cards (ISO 7816). In connection with the SE, is the so-called Trusted Service Manager (TSM), which handles the secure provisioning and management of the applications running on the SE. The TSM also act as the “interface” between Apple Pay ecosystem and other third-parties, such as card schemes (Visa, Mastercard, etc.) and transit operators (Octopus). The wallet app, in fact, is more a UI component which handles the interaction between consumer and the payment application residing in the SE. Consumer verifications (either Face ID or fingerprint) are managed via Apple´s Secure Enclave. The NFC controller, which has been always in the centre of the debate, is responsible for routing the commands and responses between the payment application (in the SE) and the acceptance devices, e.g. a contactless enabled POS.

The overall design guarantees a high degree of security, because payment applications are hosted in a tamper-proof secure element with its own OS. And the access to the SE is strictly limited. e.g. only Apple´s own TSM has access to SE for installing, provisioning and managing the payment applications on behalf of the issuers of the payment instrument (e.g. the banks). Access from the main OS is also limited to only Apple´s own wallet.

On the user experience side, due to the single wallet design, it offers an unified experience across issuers of the payment instruments and geographical locations. For instance, it is always the same process enrolling a card into Apple Pay, no matter who the issuer of the card is, or where the consumer is based. Similarly, the payment experience is also pretty consistent, leading to very easy consumer adoptions.

When it comes to complexity for service providers (banks, transport operators, etc.) to integrate with Apple Pay, there are a few elements that makes it simple and scalable: First, Apple Pay is based on EMVCo tokenisations framework which is being adopted across the entire payment industry. As a result, service providers have a single point of integration with a token service provider (TSP), which handles the complexity of integrating with multiple wallet providers to ensure scalability; Second, Apple manages the lifecycles of the payment applets within the devices. Since Apple owns both the hardware and the software, they are in a good position to guarantee the reliability of the whole solution. This used to be a big challenge that costs millions of dollars to the banks and wallet providers because of the needs of extensive regression testing for every single release or upgrade of hardware, OS and firmware. If you have been in the pre-xPay mobile payment industry (2012–2014), you definitely will understand what I mean :).

The above-mentioned benefits mainly come from the fact of tight and seamless integration of Apple´s own components, which, at the same time, are also the reasons that lead to criticisms and debates on openness.

So what exactly is not open?

To answer this question, we need to quickly revisit a few basics of NFC mobile payments. Traditionally, there are two main groups of NFC mobile payment solutions, categorised by the storage location of the payment application: hardware-based and Software-based (also known as Host-Card-Emulation, or HCE). Since HCE is only available in Android and Blackberry, I will skip it throughout the rest of the article.

Figure 2. NFC mobile payments based on hardware security (or SE)

To help explaining the issues, let’s keep in mind the following three concepts:

  1. Payment application and wallet are two separated components: as shown in Figure 2, payment application is a smart card applet installed in an SE, which has its own OS (either JAVA Card or MULTOS). The wallet app, in the NFC payment context, is not performing payments nor hosting the payment function as such. Instead, the wallet app is only an UI component, which allows the user to manage the payment applets residing in the SE. e.g. show card art, select cards to use, set default cards, kick off enrolment or payment processes, and perform certain lifecycle management such as suspend or delete cards, etc.
  2. Payment is conducted between the payment application and the POS devices: the combination of the secure element with an active payment applet, the NFC controller and the NFC atenna is equivalent to a contactless card. Tapping a phone at a contactless-enabled POS is exactly the same as tapping a contactless card, in the sense that the transaction “dialogue” happens between the “card” (the secure element with payment applet) and the POS. During this process, the wallet app is not involved.
  3. Security is ensured by limiting the access to the secure element: When a phone is tapped at a POS device, the NFC controller will route the communication towards a SE that has been configured. In theory, there are a few possible destinations (depicted in Figure 2): a UICC (effectively your SIM card) provided by the mobile network operator (MNO); an embedded secure element (eSE) that comes with the hardware; or a slot to accommodate an external SD card. A payment application from certain provider (e.g. a bank) is installed in a dedicated space of the secure element, to which the access is strictly limited. More details of such processes, roles & responsibilities can be found at Global Platform. In a nutshell, we can compare an SE with a hotel, as shown in Figure 3. The owner of the SE, just like the owner of a hotel, is responsible to allocate a dedicated space, called security domain (SD), to a service provider (SP) who wants to load their own applet. Hence, depending on the owner of the SE, a SP always needs to establish a relationship (both business and technical) with a third-party. In the Apple Pay case, the NFC signal is configured to route to the embedded secure element (eSE), whose owner is Apple. As a consequence, every service provider (banks, transport operators, etc.) who wants to enable Apple Pay must rely on Apple to install, provision and maintain the relevant applets on their behalf. But it will be the same, if other SE´s are utilized. e.g. if UICC is the SE, SP´s need to have the same relationship with a mobile network operator who owns the UICC.
Figure 3. Secure Element management in comparison to a hotel management. Note: as mentioned earlier, there is an exception, called HCE (host-card-emulation), which allows service providers to independently manage their own payment application without the need of a third-party, e.g. one of the SE owners. Since there is no such capability in the iOS world, I am not going to elaborate further.

Ok, finally we are there!

Specific to Apple Pay, what is actually closed are two things:

Figure 4. What exactly are closed in Apple Pay system: 1. NFC routing to other SE´s; 2. Access to eSE from third-party wallets
  1. Access to NFC controller from other SE´s: currently, only the embedded SE (eSE) of Apple devices have access to the NFC controller for routing transaction APDUs (application protocol data unit). As a result, any payment application needs to be installed and managed via Apple (TSM), because Apple is the owner of the SE.
  2. Wallet access to eSE: when an application is installed in an SE, technically it could give access to any OS-level application by properly defining the access rules. However, in case of Apple, this access is not given to any non-Apple Wallet application.

Let´s compare Apples with Apples

To make a fair comparison, we must make sure that we are comparing the same things, which, I am afraid that is not the case when we talk about Apple Pay´s openness vs closeness.

Figure 5. Comparing “Apples” with “Apples”: Apple Pay is a software, hardware and solution package, while most of its rivals are not

Philosophically speaking, open v.s. close is a relative thing. Looking at the figure above, we may realize that we have not being really comparing the same thing, when making a bold statement that “Apple is closing its NFC capability”. Yes, true, but comparing to whom?

As shown in the figure, the “rival” of Apple Pay, is not one company, but a mixture of different companies, including OS (operating system) provider, hardware providers and third-party wallet providers, each of them provide one or multiple parts of the overall solution.

If we focus our discussions on NFC, here are the facts regarding the rivals of Apple:

  • OS providers have full control on software but most often no control on hardware nor wallet/payment solutions. So their key driver is to provider an OS that is flexible and powerful enough to benefit a wide range of hardware providers and solution providers. As a good example, Google introduced the host-card-emulation feature in Android, to unlock the potential of any solution provider to independently develop their own NFC payment solutions. From an OS provider point of view, it makes perfect sense, because you want your OS to be as useful as possible by as many as possible clients. Can you compare Apple Pay with an… OS? Probably not
  • Hardware providers, such as the smart device manufactures, have full control on hardware but no control on software nor solutions, hence they have different drivers. For them, it is important that their hardware is open and flexible enough to empower various solution providers to build their solutions. Comparing Apple Pay with a device manufacture? Doesn´t sound fair either
  • Third-party wallet providers, such as bank´s own wallets, are taking use of the capabilities provided by both the OS and hardware providers to build their own solution, for their own customers. In this case, they are not in a position to be involved in the open/close comparison
  • If we step back a bit now, none of the above parties are actually creating a complete payment ecosystem. What they do is to be as flexible as possible to attract others to their platform or hardware. On the contrary, Apple, with the full ownerships of both OS, hardware and a wallet solution, have invested heavily to create a tightly and seamlessly integrated ecosystem, with finely tuned security and UX. Irrespective of the legal aspects of keeping it like this forever, it is unfair to request for a brutal “openning”, not to mention that many of the players don´t have a clue of what exactly they want Apple to open

To quote my favorite blogger and expert in this domain, Joel Breckinridge Bassett: blindly forcing Apple to “open” (what, an NFC chip?) is like:

“Apple took the time and expense to build a first class restaurant and outsiders are demanding the right to use Apple’s kitchen to cook their own food to serve their own customers in Apple’s restaurant”

Joel Breckinridge Bassett

If we compare Apple Pay with Google Pay, or Samsung Pay, what is the difference? Very limited! Similar to Apple Pay, both Google and Samsung Pay are ecosystems with seamless frontend & backend integration to guarantee high degree of security, UX and ease of integration by other service providers. This is probably a more fair comparison.

So the problem is that, one can claim that Apple as a hardware provider is not opening every part of its hardware comparing to other hardware providers; or, as an OS provider, is not providing a feature that allows others to independently build a payment solution comparing to Android. However, there is no equivalent entity that can be compared with, to indicate how open or close Apple is as a whole.

What are the real issues?

It is no doubt that Apple´s approach has led to several practical issues. To list a few:

  • Branding: everyone wants its own branding. For example, a card issuer would always prefer that the payment application is branded with its own name. Hence a single and only wallet approach have challenged many people’s branding requirements
  • Business model: this is probably the biggest issue in my opinion. Banks are more reluctant to launch Apple Pay comparing to Google Pay and Samsung Pay, mainly because of Apple Pay´s business model. The model requires banks to share a certain percentage (exact number depends on the market) of its transactional income with Apple. This is even more challenging in regions where the issuer´s fees are strictly regulated. e.g. EU, because it would mean that the issuers can potentially lose a significant part of their transaction revenue, or in the extreme case leading a negative business case if the fee overweights the issuer´s income. However, we should not forget about the fact that running one´s own wallet solution also costs money. Depending on the implementation and scale, it can be even more expensive
  • Single app offering: some apps or wallets, such as the ones from many challenger banks (Revolut, Curve, N26, etc.), have been quite successful in terms of attracting consumers, because they offer one-stop shopping for their consumers to manage their financials with advanced UX and data analytics. For those players, fees are secondary issues. But since they have very successful apps that do lots of things, it would be even nicer if their users can also perform contactless payments directly from the same app, rather than switching to a different one, e.g. Apple Wallet, only for certain use cases. Such capability, is of course limited in an iOS environment, due to the closeness of Apple´s ecosystem
  • Politics: there is definitely a political element in the whole discussion. e.g. Next to all the technical and business issues, another elephant in the room is probably the concern of losing controls to a giant that may grow into some monsters. But I will not elaborate more, as this is my least comfort zone :).

What might be opened, if it ever has to?

Figure 6. Three potential options for Apple to be more “open”: 1. open NFC routing access to other SE form factors next to Apple´s own eSE; 2. open access of third-party wallet to Apple´s eSE; 3. UI-less service from Apple Pay

Generally speaking, I see three options that could technically “open” the Apple´s NFC ecosystem, each of them lead to different impacts to the rest of the industry. It is however important to keep in mind that this discussion focus on explaining possible options rather than the likelyhood of them from happening.

Option 1: open access to other SE form factors

First option might be a very straightforward one: allow the routing of NFC signal to other form factors of the SE, such as UICC and SD card. Since it is very unlikely that Apple would have additional slot for external SD card, I will skip the discussion around SD card.

Opening access to UICC next to Apple’s own eSE would eliminate the dependency on Apple, both in terms of secure storage and wallet front-end. However, we should keep in mind that it does introduce new dependencies/issues:

  • Mobile Network Operator (MNO) dependency: in case of a normal SIM, the dependency is moved from Apple to the MNO. e.g. as the owner of the secure element, the MNO is responsible to create secure domain for a wallet provider hence an integration and business relation (hence a cost) with the MNO needs to be in place. Historically, this model did not work well due to a few reasons: first, the dependency is not gone, it is just moved to another party. So the technical and business complexity are still there. Second, to achieve a good coverage of consumers, the wallet provider must replicate the same technical and business efforts with more than one MNOs, which introduces a lot more dependencies, costs and instabilities. Having said that, things might have changed in the last years. For example, eSIM might be a game changer as it also removes the dependencies on exact MNOs. However, it still remain to see how eSIM will evolve to accommodate different types of payment and transit applets, as well as to achieve the required coverage
  • User experience: the tap-and-pay feature without unlocking screen nor opening wallet app may not work anymore, at least not to the expectation of the majorities. Technically, NFC controller will route the communication to the default destination, unless an override is performed. For example, if the eSE is set as the default, and a consumer has his/her card in UICC with a different wallet, tapping the phone will lead to an auto-launch of Apple Pay wallet instead. Guess what could happen next? The consumer has to either open his/her preferred wallet before tapping, or understand how to change the default routing. This can cause lots of confusion especially to non-tech-savvy users, which we have seen enough in the Android world

Option 2: open access of third-party wallets to Apple’s eSE

Most parties are actually not complaining about the storage option, either because they are not ware of it or it is not of the most concern. Instead, the key criticism is around the single-wallet (Apple Pay) limitation. So an obvious (technical) option to open is to allow other wallets to gain access to their own payment applets reside in Apple’s eSE.

In this case, third-party wallet providers still rely on Apple to manage the provisioning and secure storage of payment applets inside the eSE. However, since the wallet could have access to its own security domain, there is a branding opportunity. After all, the end users do not have a clue about the secure elements or whatsoever, but only the “face”, which is the wallet. Of course, Apple can still charge a fee for using the provisioning service, as well as the space within the eSE. But probably they cannot claim a transaction based fee.

Though this option seems reasonable in many aspects, it is, in my opinion, the most unrealistic option. To explain it in plaintext: the current Apple Pay model streamlines the onboarding and integration process by treating everyone the same in terms of technical integrations and configurations. Opening eSE access for third-party wallets is in conflict with this strategy.

The simplicity of the current model is mainly achieved by two means: first, on the backend side, Apple only onboard providers via aggregators, namely a token service providers (TSPs), which is usually provided by schemes. Hence from Apple perspective, there is (almost) no difference in terms of onboarding provider A and B. Second, on the frontend side, due to the single-wallet strategy there is no need to manage different access rules per provider, which significantly simplifies the efforts of Apple. After all, payment is only a small business area of Apple Inc., so I couldn’t imagine Apple opens to configure access rules and handles certificates with thousands of providers worldwide. It will be a huge hassle.

Option 3: UI-less Apple Pay service

This option refers to the scenario in which Apple Pay opens API services to third-party wallets, while keeping the current Apple Pay ecosystem untouched, as shown in Figure 6. Instead of always promoting the Apple Wallet, other wallets could be in the front, while consuming the services of Apple Pay behind the scene. Regarding this option, there have been some “indications” from the Apple APIs that Apple might be considering something similar.

Following this approach, the security, UX, integration and even Apple Pay’s business model could remain the same, but the branding opportunity is given to other wallets. This probably solve the problem to a large extent. e.g. if not all, at least it would make many of the parties happy. Additionally, this approach keeps the simplicity of integration, onboarding and maintenance efforts from third-party wallet point of view.


The “closeness” of Apple Pay has been almost a forever debate. Although the criticism from different people sounds almost the same, they actually are very different, either due to different needs or different level of understanding of the whole picture. I do believe that when people ask for open, they may not asking for the same thing. Therefore, we cannot simply view it as one issue. In any case, understanding a little more of the overall picture will help us to make more rationale statement and actions.

We may all agree that open v.s. close is a tradeoff of security, UX and complexity. When it comes to payments, complete openness is not necessarily the best choice. At the same time, one cannot deny that openness will drive for innovation and cost reduction. Personally, I believe that Apple will gradually be more open to power the others, which they are already doing. But most likely it will not be the same way as many people are expected, especially around payments. As I said, payments is a special domain which requires a balance of security and convenience, hence also the balance of openness vs closeness. My worry is that many people may not have the full picture of what we are really asking for, and hence the consequences of asking for it.

Last but not the least, let’s don’t underestimate the consumers’ affinity to strong international brands like Apple. It is no doubt that one of the common key drivers for people to demand openess is to drive traffics to one’s own brands. However, we should all be careful to not blindly putting our own wishes over consumer preferences. Eventually, consumers choose what they would like to use.

Thanks for reading the article, if you found it interesting please clap for me, as it means a lot to me.




Writing about payments. No matter if it is issuing, acquiring, scheme processing, mobile payments, industry trends, the puzzles are decoded here

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Quantum Supremacy: The Final Frontier

'Nightmare inducing' robot picks itself up


Ambitious Elon Musk’s Tech Company Wants To Implant Wireless Chips In The Brain

Neuralink behind ear

Versatile eReader with Frontlight — Boox Nova Pro

Be a human router with a good cache: Networking Insights

Amazon Alexa — How to Smartify Your Home With Alexa’s Help

Why Microsoft Choose Asobo to make Microsoft Flight Simulator 2020?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Ruimin Yang

Ruimin Yang

Writing about payments. No matter if it is issuing, acquiring, scheme processing, mobile payments, industry trends, the puzzles are decoded here

More from Medium

How to resolve the “No ‘Access-Control-Allow-Origin’ header is present on the requested resource”…

Fixing no access control allow origin header is present on the requested source.

Trust in Your Wallet

Nodejs Event loop bottlenecks as a server and solution to scale it!

Using Toastr In Rails