Apple Enters Payments
Celent will help qualify your requirements and introduce you to the vendor
Spotted a missing vendor? Use this form to alert a vendor to the Celent service
Create a vendor selection project & run comparison reports
Register to access this feature
Click to express your interest in this report
Indication of coverage against your requirements
Vendor requires PRO subscription to activate this feature
Requires research subscription, contact Celent for more info
10 September 2014Zilvinas Bareisis
Yesterday Apple announced entering the payments space with Apple Pay, a new way to pay in physical stores and mobile apps. The move was not unexpected - the question of when and how Apply would do something in payments was subject to much speculation in recent months. At Celent we also published a report in March this year called Apple in Payments: What to Expect? Yesterday, we got the answer. Details of the announcement can be found here. In this blog I would like to focus on some of the key highlights of the solution and consider its chances of success. As we predicted in March, Apple did NOT launch an open wallet available on all mobile devices, including those using Android and Windows operating systems. Instead, Apple focused on providing a seamless payments experience for customers using Apple’s own hardware devices. In fact, those devices are only limited today to the newly announced iPhone 6 models and the Apple Watch. We can only assume that any future iPad models will also have this capability, as otherwise Apple would be shooting itself in the foot in the m-POS market. Our report also discussed that Apple was going to make use of its relevant assets, namely access to card details registered at iTunes, Passbook app, Touch ID and biometric customer authentication, iCloud keychain, AirDrop and iBeacon. The first three are indeed at the heart of Apple Pay’s proposition. However, I was surprised to see no mention of iBeacons, especially given their potential synergies with payments. P2P payments capability is also currently missing. Again, I would expect we will hear more from Apple on both of those topics. We thought that Apple would start with payments facilitation online before entering physical stores. However, yesterday’s solution addresses both areas immediately. Also, we thought that Apple might want to leverage NFC technology, but would implement it differently from traditional NFC contactless payments. Indeed, Apple Pay uses NFC in a very different way – instead of storing actual card details, Secure Element on the new iPhone only stores a token associated with a card. The payments transaction requires combining that token with a dynamic security code generated for each transaction and a biometric customer authentication based on Touch ID. This approach also turns card provisioning on its head – instead of starting with banks and TSMs, it starts with the customer who can take a picture of the card and have it “tokenised” immediately (assuming it is issued by one of the participant banks.) It is interesting to note that when Google Wallet launched, they were not going take any cut on the payment transaction, but were seeking to make money from transaction data. Apple claims not to see any of the transaction data, which would alleviate major concerns for both merchants and issuers. However, it also begs the question of how Apple intends to make money from this service. One view is that they won’t. However, although unconfirmed, there are rumours that the issuers will be paying Apple up to 25 bps for each transaction. Some speculate that Apple, confident on the security of its approach, has promised issuers to take on some of the transaction risk. Others argue that Apple can pull it off because of its size and importance, perceived or otherwise. Which brings us to a number of questions:
- How easy will it be for Apple Pay to scale? The announcement talked about the issuers who agreed to participate as well as merchants that will be able to accept the service. But what kind of pre-existing relationships are required between Apple and issuers and merchants for the system to work? Clearly, issuers will need to be able to handle tokenised transactions, although that perhaps can be done by 3rd parties on their behalf. However, if they also need to negotiate the commercials, the enrolment process is likely to be more onerous. For merchants, my understanding is that any merchant capable of accepting contactless should be able to accept Apple Pay; however, online and in-app merchants would have to integrate Apple Pay into their checkout experience.
- How will the merchants react? On one hand, Apple and its market clout can set the standard for the industry providing a much needed direction to merchants where to invest. It also helps that the approach is aligned with EMV migration in the US and any new terminal that the merchants install should be capable of accepting Apple Pay transactions. However, other questions remain, such as:
- How will the consumers react? Clearly, the early demos show a very slick user experience, as we have grown to expect from Apple. However, without any additional bells and whistles, will it be enough to convince the consumers to reach for their mobile phones instead of their cards when paying? Sure, Apple’s approach is more secure than a mag stripe transaction, but will consumers understand the nuances of tokenisation or will they rather remember the nude pictures stolen from iCloud? In Europe, these arguments are even weaker – many consumers already enjoy the benefits of EMV and the speed and convenience of contactless (card) transactions.
Asia-Pacific, EMEA, LATAM, North America