Apple Pay : What happens when it hits 100%

lucy

What happens when Apple Pay hits 100%? I am not talking about 100% merchant acceptance, as much of that is driven by an alignment of merchant interests – cost reduction, potential for increased sales and marketing etc. Instead, I am talking about coverage – the share of total available cards across US banks that can be provisioned into Apple Pay. Today, partly due to the diligence of networks in signing up banks for AP, cards that are responsible for 90% of total retail payment volume are now ready to be provisioned. Separately, I am told 90% of issuer portfolios will be tokenized by end of 2015. (Forget/Ignore Private Label and Discover, for the moment)

This is not my follow-up AP Fraud Post. Skip to the end, if that’s what floats your boat.

Today, it is possible for an Apple customer to come across an unsupported card while attempting to add a bank card in to AP – just because their bank is not supported in AP. It is in Apple’s interest to minimize these occurrences. Beauty of AP is that Apple accrues no cost for onboarding, even when the remaining issuers represent the long tail of US banking. The cost to be in Apple Pay is entirely borne by the issuer, and from the looks of it – no issuer wants to be left behind. Networks act solely as the aggregator and the muscle.

Issuer support was a huge hurdle for Google Wallet and Isis. Dwindling issuer support (in the case of Isis) or the sheer absence of it (in the case of Google) stymied both initiatives quite a bit – as customers struggled with having to remember which carrier, which phone, which Issuer and which card was supported. Once Google decoupled from direct Issuer support and started to use a real-time funded prepaid Master card as its front – it began directing more focus towards driving acquisitions (via offers and other customer incentives). Still, without issuer support Google cannot enable end to end transactions like AP, and has to incur a cost instead – of paying Card Not Present rates to the Issuer while charging Card Present rates to the merchant.

The “Cards representing 90% of total retail payments volume, now ready for AP” is a significant milestone. It’s one that places little requirement on who or how payments are initiated, so as to be useful to Apple and to the consumer. Failure of all that preceded it (GW, Softcard et al) was because customer utility tended to orient itself around actual usage. Use to be useful.

Anecdotally, I have noticed a trend where Apple customers who activate AP are choosing to add all of their supported cards – irrespective of their intent to use these cards to pay, or even use AP for that matter. I don’t think this scenario is totally tangential to Apple’s original intent either. If customers had to wait for network effects to manifest before deriving any real value from AP, well..you get the drift.

The desire to make AP useful even as payment acceptance remain spotty, was evident as Apple negotiated terms of AP with each of the major issuers. Apple pushed hard to gain access to useful transactional data (sans PII) from each issuer – in some cases, negotiations went right down to the wire (weeks leading up to the launch). Transaction data, scrubbed of any PII, still proved elusive with some banks, who chose to provide transactional data – only for those purchases made through Apple Pay. There was much contrast in Issuer agreements, some who held back rich transactional detail even for AP transactions, where as atleast one issuer agreed to share detail for all transactions – even for swipe and other non-AP transactions(should be easy to guess which).

Back in 2011, I had written about the poor user experience in Google Wallet – loaded with useless transaction detail (‘Merchant name’ in GW transactions showed up as “Paypass Merchant” and ‘Amount Paid’ displayed as “Sent”). The lack of trust in the Google – Issuer relationship was evident in the poor GW customer experience, and all parties were at fault. Banks wouldn’t share customer PII data with Google, and Google would not settle for anonymized transaction data. In the end, the “fly on the wall” approach that Google picked proved to be a non-starter..and yada..yada..Google Wallet remains a shadow of its potential.

Apple seems to have had some success in extracting usable transaction data from banks. Even in the case where it is not, the rolling AP agreements will be up for renewal in 3 years, when Apple will have another hand at influencing a favorable outcome. Apple does have some legitimate ground to stand on – asking for usable transaction data. Passbook/AP as a safety net for all transaction data has a lot of customer utility (especially if you have not heard of BillGuard) by alerting you to *every* transaction made with your card.

So, provided that Apple has *convinced* your bank to share, you are now able to use Passbook to view all your payment transactions, and if you are lucky to have been impacted by a breach – before receiving them in mail, you may receive your new card first in AP, thanks to the decoupling and abstraction available through tokenization. Complaining to your card issuer for mailing yet another plastic card due to a breach, will become a thing of the past. Apple Pay will also become someone’s first place to be notified when fraud happens.

If you are a bank, there is also another disturbing trend going on. If mobile banking pushed up the rate of customer engagement from online banking – Apple Pay represented the same on steroids. If I were a banker, I would be worried why Passbook is taking over as the primary channel for engagement – even if it meant that my customers were only receiving one way transaction alerts. And for the issuers who are holding back on transaction detail, similar to how customers have pushed for Apple Pay support, they can be expected to be held to task. “Why doesn’t my bank support Apple Pay” has sent a clear message to banks that having vertical apps aren’t enough – that they should be looking to have key consumer facing services exposed as API’s – to be wrapped.

Tokenization was that layer of abstraction over paymentsthat allowed the decoupling between the credential originally issued by the bank, and the one accepted by the merchant during the lifetime of that credential. This trend of abstraction will continue beyond payments – in to other services – whether it be depositing cheques, managing deposit accounts, loan origination, money movement, so that the front line is managed by someone entirely other than the bank. And it no longer will be enough for a bank to say that they have a vertically integrated app that exposes some or all of these services in mobile – instead, they will be judged on the efficacy of extending these core services in to new platforms wholly owned by others. We may increase our interaction and engagement with a bank – but those won’t happen inside a branch or even within its own app. The sooner a banker reconcile with that statement, the quicker they can remove themselves as the chokepoint.

Hence, It is my belief that banking apps are now passé. Regardless of what banks tell themselves, (that – banking apps are a source of differentiation) – truth is that app usage for banks coalesce around two primary customer use-cases – check balance/view incoming transactions, and deposit cheques. Former has already been absorbed mostly in to AP, and the latter can be but an integration or acquisition away. At the launch of AP, I wrote that AP is the only bridge to payments in iOS for banks. Now, there is the real possibility that Passbook will become the preferred way to interact with your bank.

Finally – Apple’s transactional data agreements around AP has another benefit. Mobile Wallets were supposed to close the loop – to connect the dots between online and offline attribution through payments data. Except, AP’s predecessors failed due to lack of scale, stakeholder support and overall alignment. AP however, is unique in its view that it hardly wants to be encumbered by a two-sided market, that it is bypassing that gap by channeling every transaction firing on provisioned cards via AP/Passbook – regardless of whether that transaction was initiated through AP. And even when that data is sufficiently anonymized, Apple as the single party present at all end-points, is the only one that can verify attribution and measure effectiveness for its partners.

Apple Pay is a multi-billion dollar business in waiting. It just has very little to do with the transactional revenue collected from its partner banks. It has everything to do with connecting the dots for commerce, driving in-store attribution while still maintaining a respectable distance from customer PII. And Apple wants to rub it in Google’s face, while doing it.

3 of the issuers who launched with AP did not flinch at my 6% fraud post. Read what you will, in to it. More at 11.


Board of Advisors at SimplyTapp – creators of Host Card Emulation driving democratization and open access to NFC in Android.

Mobile Commerce & Payments Lead at Experian Global Consulting, serving Experian’s clients in Banking, Retail, Consumer Credit & Payments.

A strategic adviser w/ over 17 years of international Tech & Business Strategy consulting, advising firms in banking, retail & asset mgmt that seek clarity & insight in to the myriad business models around payments, fraud & commerce.

Founded DROP Labs, a mobile payments/commerce strategy & advisory practice.

Tweets here. I’m on LinkedIn here.

Cherian Abraham
View all posts by Cherian Abraham
Tagged , , , , , , , , , , ,
  • Willam Hugh Murray, CISSP

    From your pen to God’s eye. By waiting a decade to introduce it, the brands and issuers missed the window for the success of EMV. In 2015, it is a day late and a dollar short.

    Apple Pay is retarded by the limited availabiity of NFC and TouchID on iPhones. Problem may persist for several years. There should be an Android app for Apple Pay and Google wallet should have access to the NFC API on iOS. Weeks to months, not months to years.

    We also need iOS and Android apps that will cough up a one-time payment authorization number (PAN) for use in “card not present” transactions.