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.
