Took a while to crystallize some thoughts on Apple Pay, and having a sore throat meant it’s time to write instead of answering another call on the topic. All in all – the launch may have been exciting or uninspiring based on who you ask. But the truth is far more complicated – once you start to understand what this entails – such as the dynamics of the Apple – Issuer relationship, economics and a deeper look in to what Apple has sought to expose and keep out. As far as who is most impacted by today – I think we can say goodbye to the TSM’s forever. Even if they hope to convince to put SIM based Secure Elements on to iPhone6 and subsequent iterations, in my opinion – Apple would prefer a competing container to store payment credentials like it would want a third tit. The second one impacted is MCX. Third would be Discover/Paypal. Infact – if you paid notice to the press releases floated in the week before the Apple Pay launch (MCX CurrentC, Paypal API) – it would have been evident that these two had no role to play alongside in the oncoming Apple Pay launch. You wouldn’t risk the wrath of Apple if you were.
A few quick notes that I did not see being talked about till now – before I get to each party in this announcement and elsewhere and how they are impacted.
Apple Pay will be the only payment experience on the iPhone. Apple’s approach here must be noted – it’s choice of NFC, it’s selection of launch partners, deals discussed and rates negotiated (15 to 25bps on Credit, ~0.01 – 0.03 on Debit), it’s avoidance of Host Card Emulation etc. There is simply no route for competing wallets (read: Isis or GoogleWallet) to an iPhone anymore. The NFC stack is closed – Apple has chosen to only enable 14443 (Card Emulation) and Tag Reading and Peer to Peer are not available. This reflects Apple’s approach to TouchID as well – there is simply no room for anyone but Apple at the launch – before it socializes the concept beyond itself, as we saw with TouchID. But that being said – I am still very hesitant that Apple will allow Peer to Peer to ever be allowed for payment – as that will conflict with its own payments strategy.
For all the issuers on stage yesterday at launch, I would venture that most of them have mixed feelings at this point. There is much introspection on what they have unleashed – because they have had to sacrifice much of the room for negotiation banks retained with other wallet players. Most importantly – If you are an Apple Pay launch partner – having your credential/token on Apple Pay does not mean that you get to extend that credential in to your own mobile banking app or wallet. This point was non-negotiable as an issuer when considering Isis – because no bank wants its brand to be wrapped by another (Google, Isis) and neither do they want the customer to close the bank’s app and open ISIS or GoogleWallet to pay. But with Apple – those reservations have taken a back seat – certainly because with Apple that was never up for negotiation. So a Chase card in Passbook does not mean the customer can tap and pay directly from the Chase banking app. Apple tightly controls the payment experience. Simple as that. This should cause much concern among the Apple Pay partner banks – for whom enabling payments outside of Apple Pay in iOS is OFF THE TABLE.
So where does that leave you as an Issuer? It means iOS is done and any hope for you to have an integrated payment experience as a bank is to focus on Android and it means Host Card Emulation. Apple has provided zero room for Issuers to tie together an iOS payment experience – other than the clunky Apple approved “trigger Passbook and flip back and forth” model. There is also no room for banks to trigger their own cards over others – even as a partnership with a specific retailer. “Trigger Bank X Card when you are tapping at Macys” Any differentiation between the issuers will all be external to the payments experience – and will be less than optimal. I would expect banks to put a lot of focus in to revisiting Android and HCE in the oncoming months – and it goes double for those issuers who were not chosen by Apple – and working on adding payments capability as well as chasing merchant partnerships to incent usage and acceptance. Apple’s choice of NFC has made its continued presence in the retail environment an untenable position – and that will only be a good thing for HCE and other SE based approaches.
And If I am giving up 15-25bps per transaction to Apple – and I really have no say in how to use my credential outside of Apple Pay – how altruistic are my intentions at this point as an issuer? I would begin segmenting my customers active on iTunes (500M active iTunes accounts!) and respectively their cards in iTunes to see who are affluent spenders elsewhere – and which cards have higher rates and addressing those gaps. And for those who have debit on file with Apple – I would look for a customer incentive strategy to replace it with credit. Previously – I may have had to worry about merchant acceptance as a criteria from putting my higher rewards/interchange cards in a wallet – but now, Apple has pushed that door wide open and it’s for the merchant to worry.
What about the thousands of other banks, whose customers have their cards on file with Apple in iTunes? Apple seems to have chosen the exact same approach by Isis – in that “If we are not talking to you already – then you shouldn’t be asking us why”. That disenfranchises a considerable number of banks who feel jilted – who have to now reconcile with a) incentivizing their customers to add their cards to iTunes and b) jumping in to bed with less than stellar mobile payment choices just for the sake of being seen as doing something. With networks doing the token mapping for Apple to Issuer – may mean that they will take on the role of signing up new banks, but I suspect it’s a long tail of little residual value. I posit that banks across the board are going to be forced in to partnerships that are not optimal – for the fear of losing out. Expect much capital to be wasted in pursuit of the shiny apple.
What about ISIS (SoftCard)? It put out a press release stating it is talking with Apple about a path way to the iPhone – and it should go over like a lead balloon. There is no question that Apple’s stated affinity towards NFC lifts all boats – and Isis will find more locations for their brand to be accepted, but now with Host Card Emulation far less issuers would be willing to pony up the fees to suffer them. Isis cannot delay the inevitable any longer. Update: My view is validated by this NFC World story. Regardless of what Isis may claim – they have no play with Apple.
Role of Credential in the Wallet: Apple uses static network tokens issued at the time the cards are added to Apple Pay – where the three networks act as token service providers. The tokens do not change ever – unless the card is de-activated, or the customer gets a new phone. If you have two phones – and the same card across them both – you will have two separate tokens for the same card. I am sure networks charge a small fee to the Issuers for token issuance – but nothing compared to the per transaction fee (15-25bps) that Apple has sought to charge. The static token model is no different from how Google Wallet operated – except that one failed and here Apple through its clout – had all the issuers that matter on day one. Discover’s absence though should be duly noted.
Apple also has opted for a Secure Element approach to storing PAN Tokens in the phone – a considerably more secure – and yet wasteful approach that is far more optics than it cares to agree. Tokens are by nature meant to reduce the risk or need for storing actual credit card numbers. And Apple already had a Secure Enclave that currently stores payment tokens it uses for iTunes purchases – and yet it sought for a new piece of hardware. Weird, and I am sure we will find out as to why later on. Update: I think the reason for Apple to store the token in Secure Element vs TEE or even Secure Enclave is to remove any chance of latency being introduced in to a retail transaction. From what I have heard – the Apple payment experience is quick (thanks to an integrated stack and having the opportunity to tune it at all levels) and Apple would have figured that storing the token elsewhere may have resulted in a marginally slower transaction. Ofcourse, that’s the best reason I can think of. *Update: A friend in Google Wallet wrote: “You need the applets that are all written in Java to be running on a javacard OS. I believe iOS is primarily C#. So its possible the secure element was provided for a javacard OS environment for the payment applets to execute commands (APDUs) and interact with the POS.” <-- Certainly possible. Impact of tokens goes beyond positive for merchants – I have spoken to a number of retailers in the last 6 months – who currently use the PAN as the anchor and are understandably perturbed that tokenization is going to disrupt that. Merchants cannot use ignorance as an excuse any longer – after all Tokenization has been on the horizon for a while – and Walmart had rejoined the EMVCo Tokenization Standard committee after staying away. Merchant CRM systems will not be able to reconcile a static token issued by Visa or MC or Amex back to a customer profile they have on their end – if for years they had depended on a PAN with corresponding Track 1 data (Customer name being key). But Apple announcement hits merchants with a double whammy.
And so Merchants. Oh you had a bad day, didn’t you? Not all of you – but if you were a constituent of a loosely held collective (MCX) – of shared beliefs and divergent agendas. As I wrote before – Apple was asked by merchants quite pointedly that – “Pick a technology, Pick an approach – and at the least it should provide us some direction in how we should proceed with our terminal upgrades”. I must add – that the merchants who asked this question of Apple were not aligned with MCX then. With a significant majority of merchants in the middle of an upgrade cycle – many have been struggling with choices – should I get a normal swipe/chip & pin terminal – or should I get the contactless upgrade? The decision is further clouded intentionally by MCX and it’s stakeholders – who have everything to gain by reducing competition at the point-of-sale by encouraging merchants to dis-allow contactless.
Instead of approaching NFC as just another radio MCX and its constituents approached it with contempt and in turn made it impossible to decouple the radio from the baggage it had come to represent for the merchant community. Which in turn made it harder for any kind of pragmatic approach impossible for non-incumbents(for e.g. GoogleWallet). With Apple embracing NFC, and despite having zero new merchants at launch – it sends a powerful message that Apple prefers status quo. MCX will have a tougher time keeping it’s coalition – and even hard to attract new ones. Even if Apple chose not to utter a word about the marketing and loyalty play, for merchants – they are happy to fill in those gaps themselves, and hope that adoption of a payments standard affords them the possibility of communicating with iOS devices in a manner beyond payments. Even though Apple Pay is all of ISO 14443 on launch date – I suspect there will be a sudden urgency for software upgrades to allow ISO 18092 and additional capabilities to address BLE.
Apple also did not speak to Private Label Cards, Paypal, ACH and other merchant friendly funding sources – possibly because, quite pragmatically – Apple’s had zero Private label and other non-credit funding sources in its 500M active iTunes accounts.
This certainly takes the wind off the sails from Loop Pay, Coin, and the many other stop-gap measures that hoped to extend the life of your plastic, and subsequently the swipe terminals. In the scheme of things – they will have reduced customer utility and add little to advancing the narrative around mobile payments. I am off to an HCE panel – but I will try to clean this up later. Would appreciate thoughts from the community.
You can connect with me on LinkedIn here.
What about Amazon? They won’t embrace this will they?
I’m sure they’ll embrace this partially, like for in-app payments, especially as the rates are adjusted downwards to reflect the fact the CNP is now present. On amazon’s Fire and Kindle we’re likely to see a similar approach.
Great post Cherian. One point that I’d make is that there would still seem to be some opportunity for merchants to allow consumers to choose the default card for that particular merchant. The iBeacon (BLE) is already tied to coreBluetooth (in the OS, without an open app), and also to the lock screen and Passbook. So simply extending that API could allow for Passbook to use an iBeacon to know which merchant we’re currently at. It would be super nice if Apple would let us add our checking account to iTunes, and choose that as our default payment method. Then they could just ACH the transactions. But that leaves them no way to monetize it, even though they claim to be focused on “user experience”. And if that happened, then there would really be no need for MCX. Seems like a good ACH solution, monetized to Apple by the merchant, would save everybody money. Of course, Visa/MC doesn’t want to be marginalized out of the mix either. It’s a tough one.
Great points, Mark. It is definitely kludgy and further – Apple has ignored to provide clear guidance to merchants beyond the payment value proposition. And I am not trivializing the importance of that payment terminal/standards guidance – because most merchants are in the middle of a terminal upgrade cycle and is looking for that clarity. They now have it. And now Apple can build upon that clarity with other relationships and capabilities to enable marketing on top of the payments layer or along side of it.
Excellent article. A lot of things to chew!
A couple of thoughts…
1. My interpretation for the need for a Secure Element, is perhaps the need for the PayWave applet to communicate with the POS, rather than storing the token. Plus, as you pointed out, it puts a nice marketing spin.
2. One thing that perplexes me is that the user stories for payments (through NFC) and offers (through iBeacon/BLE) are not tied to each other very well in this initial iteration of Apple Pay. I mean, if I compare this to the Starbucks experience (where I can use my 12th star to pay for the coffee, instead of my card, using the same simple gesture), the Apple Pay experience feels like stone age.
3. Outside of payments, it would have been nice to see peer-to-peer mode available as a software SDK in iOS. While a lot of use cases of peer-to-peer NFC can be solved with BLE, NFC comes out ahead when you consider energy efficiency, cost and communication speed.
Excellent points. I agree that the location for the Paypass and Paywave applets had to have been a consideration for choosing SE vs Secure Enclave – which is a proprietary Apple architecture.
As for your note on P2P mode being exposed by Apple – I believe that eventually they will open it up similar to how they chose to do the same with TouchID. That said, I doubt Peer to Peer will ever be allowed to do payments type transactions. As for how Apple will prevent P2P usecases, I will blog about that later.
Great article, Cherian! You captured the essence of Apple Pay and the impact on existing ecosystem stakeholders. I think everyone in the payments industry shares your sore throat from the last couple of days. Everyone wanted to talk about how this affected them.
It was predicted that Apple would enter the payments space only when the formula was right for them to own the entire experience and they have done just that. The experience itself is going to be key to consumer adoption. Just like so many orphaned devices that predated Apple’s entry into their space (MP3 players, smart phones, etc.), existing open wallet schemes can complain that they were first, or the same, or better, but the fact is that Apple Pay will likely be the inflection point to real consumer adoption.
Last year at Money2020 an executive at another NFC-based wallet company remarked to me that they were going to “short Apple stock” because the iPhone 5S didn’t have NFC”, and therefore couldn’t play in their sandbox. Considering AAPL was trading at about $486 that day, and it is a (split adjusted) $707 today, that would have been ill advised. Apple loves making their own sandbox, and consumers will line up to play in it.
Thanks Scott.
Cherian,
Interested to know if you have any info on where the heck Discover was over the past year? How can Discover let something this big rollout with the “other 3” brands without their involvement? Are they tied up contractually somewhere else? Also, Wal-Mart and Best-Buy are now on the record that they won’t support Apple Pay. That’s primarily because they legally can’t, because of their contractual obligations to MCX. MCX eliminates most of the major brands we see every day from playing with Apple Pay, so that gives me at least a little more hope that MCX will get in play here as an Apple Pay issuer. But the MCX model is to own the entire experience and infrastructure, so there would have to be a lot of bending and welding to make that happen.
IMO – By missing the stage at the Apple Pay launch – Discover did more harm to its brand (from a customer perception view) vs stomaching the rebate to Apple. I can only surmise that Discover felt that what it was working on individually or with other partners would make a bigger wave (Sigh!).
As for WM and BBuy – I doubt how long the treasury/payment folks there can hold out against their Marketing organization – especially in light of how other retailers are making hay of the announcement now, and subsequently on iPhone6 launch. And how many customers walking in to BestBuy will ask about MCX vs complaining why they can’t use their iPhone6 to tap and pay? 🙂
For MCX – the exclusivity between MCX and it’s current roster of retailers is going to have some pressure (I believe we heard between 1 year for launch partners vs 3 years for all others) – because no retailer is going to want to give up being out of loop and inextricably stuck with MCX, if it’s not taking off.
Thanks for sharing your thoughts, great article.
Precision on the Secure Enclave thing: it is not just a piece of storage, but also a “trusted” (Apple-only controlled) execution environment, notably performing the device holder’s biometric authentication (fingerprint matching) – and thus per-transaction approval. Source is the iOS Security guide from Apple (“The Secure Enclave is a coprocessor fabricated in the Apple A7 chip. It utilizes its own secure boot and personalized software update separate from the application processor. It also provides all cryptographic operations for Data Protection key management and maintains the integrity of Data Protection even if the kernel has been compromised.”.
You are right. Will edit. So I am guessing it’s more of the ability to run network applets – as the Secure Enclave architecture is more proprietary.
Cherian, this is really well thought out, well written, and very helpful. Most kind thanks for sharing your wisdom.
Cherian, nice article, very well written. I think you missed another important point – Whether the fees paid by merchants for these transactions are still Card Present, or Card Not Present. If Apple can sway the card networks and others that the One-Touch+tokenization is good enough to be CP, I think Merchants will have an incentive …
Issuers are not going to be eager to ever .. And I mean … Ever.. Vacate a growing revenue stream. There may be a balanced approach to addressing risk in a traditional CNP environment and rewarding better authentication capabilities with rate reductions. But let’s not kid ourselves that banks are going to suddenly find Jesus.