Apple Pay: First Observations And Closing Thoughts

If rumors hold true, Apple Pay will launch in a week. Five of my last six posts had covered Apple’s likely and actual strategy in payments & commerce, and the rich tapestry of control, convenience, user experience, security and applied cryptography that constitutes as the backdrop. What follows is a summation of my views – with a couple of observations from having seen the Apple Pay payment experience up close. About three years ago – I published a similar commentary on Google Wallet that for kicks, you can find here. I hope what follows is a balanced perspective, as I try to cut through some FUD, provide some commentary on the payment experience, and offer up some predictions that are worth the price you pay to read my blog.

First the criticism.

Apple Pay doesn’t go far enough: Fair. But you seem to misunderstand Apple’s intentions here. Apple did not set out to make a mobile wallet. Apple Pay sits within Passbook – which in itself is a wrapper of rewards and loyalty cards issued by third parties. Similarly – Apple Pay is a wrapper of payments cards issued by third parties. Even the branding disappears once you provision your cards – when you are at the point-of-sale and your iPhone6 is in proximity to the reader (or enters the magnetic field created by the reader) – the screen turns on and your default payment card is displayed. One does not need to launch an app or fiddle around with Apple Pay.

And for that matter, it’s even more limited than you think. Apple’s choice to leave the Passbook driven Apple Pay experience as threadbare as possible seems an intentional choice to force consumers to interact more with their bank apps vs Passbook for all and any rich interaction. Infact the transaction detail displayed on the back of the payment card you use is limited – but you can launch the bank app to view and do a lot more. Similarly – the bank app can prompt a transaction alert that the consumer can select to view more detail as well. Counter to what has been publicized – Apple can – if they choose to – view transaction detail including consumer info, but only retains anonymized info on their servers. The contrast is apparent with Google – where (during early Google Wallet days) issuers dangled the same anonymized transaction info to appease Google – in return for participation in the wallet.

If your tap don’t work – will you blame Apple? Some claim that any transaction failures – such as a non-working reader – will cause consumers to blame Apple. This does not hold water simply because – Apple does not get in between the consumer, his chosen card and the merchant during payment. It provides the framework to trigger and communicate a payment credential – and then quietly gets out of the way. This is where Google stumbled – by wanting to become the perennial fly on the wall. And so if for whatever reason the transaction fails, the consumer sees no Apple branding for them to direct their blame. (I draw a contrast later on below with Samsung and LoopPay)

Apple Pay is not secure: Laughable and pure FUD. This article references an UBS note talking how Apple Pay is insecure compared to – a pure cloud based solution such as the yet-to-be-launched MCX. This is due to a total misunderstanding of not just Apple Pay – but the hardware/software platform it sits within (and I am not just talking about the benefits of a TouchID, Network Tokenization, Issuer Cryptogram, Secure Element based approach) including, the full weight of security measures that has been baked in to iOS and the underlying hardware that comes together to offer the best container for payments. And against all that backdrop of applied cryptography, Apple still sought to overlay its payments approach over an existing framework. So that, when it comes to risk – it leans away from the consumer and towards a bank that understands how to manage risk. That’s the biggest disparity between these two approaches – Apple Pay and MCX – that, Apple built a secure wrapper around an existing payments hierarchy and the latter seeks to disrupt that status quo.

Let the games begin: Consumers should get ready for an ad blitz from each of the launch partners of Apple Pay over the next few weeks. I expect we will also see these efforts concentrated around pockets of activation – because setting up Apple Pay is the next step to entering your Apple ID during activation. And for that reason – each of those launch partners understand the importance of reminding consumers why their card should be top of mind. There is also a subtle but important difference between top of wallet card (or default card) for payment in Apple Pay and it’s predecessors (Google Wallet for example). Changing your default card was an easy task – and wholly encapsulated – within the Google Wallet app. Where as in Apple Pay – changing your default card – is buried under Settings, and I doubt once you choose your default card – you are more likely to not bother with it.

    And here’s how quick the payment interaction is within Apple Pay (takes under 3 seconds) :-

  • Bring your phone in to proximity of the reader.
    • Screen turns on. Passbook is triggered and your default card is displayed.
      • You place your finger and authenticate using TouchID.
        • A beep notes the transaction is completed. You can flip the card to view a limited transaction detail.
        • Yes – you could swipe down and choose another card to pay. But unlikely. I remember how LevelUp used very much the same strategy to signup banks – stating that over 90% of it’s customers never change their default card inside LevelUp. This will be a blatant land grab over the next few months – as tens of millions of new iPhones are activated. According to what Apple has told it’s launch partners – they do expect over 95% of activations to add at least one card. What does this mean to banks who won’t be ready in 2014 or haven’t yet signed up? As I said before – there will be a long tail of reduced utility – as we get in to community banks and credit unions. The risk is amplified because Apple Pay is the only way to enable payments in iOS that uses Apple’s secure infrastructure – and using NFC.

          For those still debating whether it was a shotgun wedding, Apple’s approach had five main highlights that appealed to a Bank –

        • Utilizing an approach that was bank friendly (and to status quo) : NFC
          • Securing the transaction beyond the prerequisites of EMV contactless – via network tokenization & TouchID
            • Apple’s preference to stay entirely as an enabler – facilitating a secure container infrastructure to host bank issued credentials.
              • Compressing the stack: further shortening the payment authorization required of the consumer by removing the need for PIN entry, and not introducing any new parties in to the transaction flow that could have introduced delays, costs or complexity in the roundtrip.
                • Clear description of costs to participate – Free is ambiguous. Free leads to much angst as to what the true cost of participation really is(Remember Google Wallet?). Banks prefer clarity here – even if it means 15bps in credit.
                • As I wrote above, Apple opting to strictly coloring inside the lines – forces the banks to shoulder much of the responsibility in dealing with the ‘before’ and ‘after’ of payment. Most of the bank partners will be updating or activating parts of their mobile app to start interacting with Passbook/Apple Pay. Much of that interaction will use existing hooks in to Passbook – and provide richer transaction detail and context within the app. This is an area of differentiation for the future – because those banks who lack the investment, talent and commitment to build a redeeming mobile services approach will struggle to differentiate on retail footprint alone. And as smarter banks build entirely digital products for an entirely digital audience – the generic approaches will struggle and I expect at some point – that this will drive bank consolidation at the low end. On the other hand – if you are an issuer, the ‘before’ and ‘after’ of payments that you are able to control and the richer story you are able to weave, along with offline incentives – can aid in recapture.

                  The conspicuous and continued absence of Google: So whither Android? Uniformity in payments for Android is as fragmented as the ecosystem itself. Android must now look at Apple for lessons in consistency. For example, how Apple uses the same payment credential that is stored in the Secure Element for both in-person retail transactions as well as in-app payments. It may look trivial – but when you consider that Apple came dangerously close (and justified as well) in its attempt to obtain parity between those two payment scenarios from a rate economics point of view from issuers – Android flailing around without a coherent strategy is inexcusable. I will say this again: Google Wallet requires a reboot. And word from within Google is that a reboot may not imply a singular or even a cohesive approach. Google needs to swallow its pride and look to converge the Android payments and commerce experience across channels similar to iOS. Any delay or inaction risks a growing apathy from merchants who must decide what platform is worth building or focusing for.

                  Risk vs Reward is already skewed in favor of iOS: Even if Apple was not convincing enough in its attempt to ask for Card Present rates for its in-app transactions – it may have managed to shift liability to the issuer similar to 3DS and VBV – that in itself poses an imbalance in favor of iOS. For a retail app in iOS – there is now an incentive to utilize Apple Pay and iOS instead of all the other competing payment providers (Paypal for example, or Google Wallet) because transactional risk shifts to the issuer if my consumer authenticates via TouchID and uses a card stored in Apple Pay. I have now both an incentive to prefer iOS over Android as well as an opportunity to compress my funnel – much of my imperative to collect data during the purchase was an attempt to quantify for fraud risk – and the need for that goes out of the window if the customer chooses Apple Pay. This is huge and the repercussions go beyond Android – in to CNP fraud, CRM and loyalty.

                  Networks, Tokens and new end-points (e.g. LoopPay): The absence of uniformity in Android has provided a window of opportunity for others – regardless of how fragmented these approaches be. Networks shall parlay the success with tokenization in Apple Pay in to Android as well, soon. Prime example being: Loop Pay. If as rumors go – Samsung goes through with baking in Loop Pay in to its flagship S6, and Visa’s investment translates in to Loop using Visa tokenization – Loop may find the ubiquity it is looking for – on both ends. I don’t necessarily see the value accrued to Samsung for launching a risky play here: specifically because of the impact of putting Loop’s circuitry within S6. Any transaction failure in this case – will be attributed to Samsung, not to Loop, or the merchant, or the bank. That’s a risky move – and I hope – a well thought out one. I have some thoughts on how the Visa tokenization approach may solve for some of the challenges that Loop Pay face on merchant EMV terminals – and I will share those later.

                  The return of the comeback: Reliance on networks for tokenization does allay some of the challenges faced by payment wrappers like Loop, Coin etc – but they all focus on the last mile and tokenization does little more for them than kicking the can down the road and delaying the inevitable a little while more. The ones that benefit most are the networks themselves – who now has wide acceptance of their tokenization service – with themselves firmly entrenched in the middle. Even though the EMVCo tokenization standard made no assumptions regarding the role of a Token Service Provider – and in fact Issuers or 3rd parties could each pay the role sufficiently well – networks have left no room for ambiguity here. With their role as a TSP – networks have more to gain from legitimizing more end points than ever before – because these translate to more token traffic and subsequently incremental revenue – transactional and additional managed services costs (OBO – On behalf of service costs incurred by a card issuer or wallet provider). It has never been a better time to be a network. I must say – a whiplash effect for all of us – who called for their demise with the Chase-VisaNet deal.

                  So my predictions for Apple Pay a week before its launch:

                  We will see a substantial take-up and provisioning of cards in to Passbook over the next year. Easy in-app purchases will act as the carrot for consumers.

                  Apple Pay will be a quick affair at the point-of-sale: When I tried it few weeks ago – it took all of 3 seconds. A comparable swipe with a PIN (which is what Apple Pay equates to) took up to 10. A dip with an EMV card took 23 seconds on a good day. I am sure this is not the last time we will be measuring things.

                  The substantial take-up on in-app transactions will drive signups: Consumers will signup because Apple’s array of in-app partners will include the likes of Delta – and any airline that shortens the whole ticket buying experience to a simple TouchID authentication has my money.

                  Apple Pay will cause MCX to fragment: Even though I expect the initial take up to be driven more on the in-app side vs in-store, as more merchants switch to Apple Pay for in-app, consumers will expect a consistency in that approach across those merchants. We will see some high profile desertions – driven partly due to the fact that MCX asks for absolute fealty from its constituents, and in a rapidly changing and converging commerce landscape – that’s just a tall ask.

                  In the near-term, Android will stumble: Question is if Google can reclaim and steady its own strategy. Or will it spin off another costly experiment in chasing commerce and payments. The former will require it to be pragmatic and bring ecosystem capabilities up to par – and that’s a tall ask when you lack the capacity for vertical integration that Apple has. And from the looks of it – Samsung is all over the place at the moment. Again – not confidence inducing.

                  ISIS/SoftCard will get squeezed out of breath: SoftCard and GSMA can’t help but insert themselves in to the Apple Pay narrative by hoping that the existence of a second NFC controller on the iPhone6 validates/favors their SIM based Secure Element approach and indirectly offers Softcard/GSMA constituents a pathway to Apple Pay. If that didn’t make a lick of sense – It’s like saying ‘I’m happy about my neighbor’s Tesla because he plugs it in to my electric socket’.


                  You can connect with me on LinkedIn here.

                  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 , , , , , , , , , , , , , ,
                  • dr.aper

                    You have to make distinction between using at a counter
                    and using it inside an App.

                    When using from an App. Apple is more involved. It encrypts the
                    info using Apple Key to send the info to ApplePay servers where
                    it decrypts and encrypts using App Venders public key and
                    sends it forward to the Vender which has to send to payment network
                    and so on.

                    All this can be read from iOS_Security_Guide_Oct_2014.pdf

                    – Secure Element is a EMVco standard using JavaCard tech.
                    – Android and Microsoft are betting on FIDO to get them biometric id
                    and they can buy the secure element. Only thing missing from Android
                    is probably difficulty of reverse engineering Apple touch_id so they
                    can’t copy so easily. So if next year Android doesn’t ARM64 with secure enclave with its own micro kernel. Android won’t be able to catch until 2016 at the latest.

                    • droplabs

                      1. I hadn’t known that Apple had refreshed the iOS Sec WP. Thank you.
                      2. Agree on the challenges for Android and MS – who I hadn’t considered – in addressing the gaps for end to end security. Vertical integration will be a pretty significant hurdle for Android – owing to scale, fragmentation and lack of control.

                      Would love to chat more. Thanks for commenting.

                      • dr.aper

                        sorry I comment anonymously because I don’t like registering,
                        one less thing to track. I generally surf without leaving too many tracks.

                        I am not in the industry just another techie who thinks he knows too much.

                        Any way real impact of ApplePay in the first year
                        will be in the App scenario where
                        you can buy thru Target app and pay with ApplePay
                        and just pick up at the entrance of the store.
                        This way the updating of terminals will become moot.
                        May change the way Retailing, iBeacons, Tracking work currently, making consumer shop even more on the Web.

                  • Will Graylin

                    Cherian, I feel compelled to draw a big distinction between programmable cards like Coin, that tries to replicate the “mag stripe” on a card, for $50 to $100 each card (still waiting for product), compared to LoopPay a new contactless transmission technology that can be embedded in smartphones for less than $1. Coin is still waiting to launch, while LoopPay is live, on its 3rd generation product, and working with OEM partners. LoopPay, as a token requestor for its users, can deliver tokenized payloads (with 101 service code) for issuers, to virtually any EMV POS or Mag only POS around the world immediately. Tokens and keys can be stored in the Trust Zone, eSE, or any secure memory. Authentication can leverage biometrics or PIN whatever is available on the device. Adding tokenization, would make LoopPay the most secure payment delivery method on the planet, because it works immediately on merchants’ existing POS (EMV or otherwise). Without ubiquitous acceptance, consumers will not change their habits away from plastic and cash – consumer behavior change is still the #1 enemy for all mobile wallets. There are various transmission means, MST, NFC, QR, as a token requestor and deliverer, LoopPay does not care, and will use all accepted transmission means, to provide faster, safer, better commerce for consumers, merchants and issuers.

                    • Will – Thanks for your thoughts. I fail to see that large of a differentiation though between Loop, Coin, Plastc etc. The tokenization approach is certainly commendable and not surprising anymore- and hardly something that is exclusive to Loop.

                      My point with Samsung was broadly than LoopPay offering on retail – it’s to call out a fragmented strategy in approaching payments across channels – In retail (one approach for magstripe terminals and another for Contactless even though quite possibly the same credential is being used for both) and then for e-commerce a wholly different approach.

                    • droplabs

                      Will – Thanks for your thoughts. I fail to see that large of a differentiation though between Loop, Coin, Plastc etc. The tokenization approach is certainly commendable and not surprising anymore- and hardly something that is exclusive to Loop.

                      My point with Samsung was broadly than LoopPay offering on retail – it’s to call out a fragmented strategy in approaching payments across channels – In retail (one approach for magstripe terminals and another for Contactless even though quite possibly the same credential is being used for both) and then for e-commerce a wholly different approach.