The Bullet that you dodged: Apple Pay and CNP


There has been a lot of focus on the Card Present rate rebate Apple has been able to extract from the Issuers, and continue to extract from banks lining up behind networks who are signing them up for Apple Pay. Networks are finally finding use for the “Issuer Provisioning Service” they hastily put together during the lost decade (the “Isis years”). Term sheets are blunt and non-negotiable, they don’t provide a lot of clarity other than demanding absolute acquiescence. There are traditional bankers sitting in wood paneled rooms wondering – “How on earth did we get here?” “Well Ed, you finally lost control of the form factor and now all you have is borrowed time, to play in someone else’s playground!”.

But beyond the CP win, apparently Apple almost got their way with CNP transactions as well – in finally affording parity to Card Present and Card Not Present transactions through Apple Pay. And if issuers hadn’t finally rejected it – I believe there would have been ripple effects beyond Apple Pay and even mobile payments – with far reaching repercussions for traditional players. Banks and Networks don’t fully understand what it is that they just dodged.

But first – here are the reasons why the CP rate rebate afforded to Apple is more than just a fee for using their ‘better mouse trap’ for authentication:

It’s not a rebate, it’s an acquisitions cost: The 15bps for credit and the $0.05 for debit ought to be looked at as an acquisitions fee paid to Apple for “acquiring” transactions. Paying the fee is the only way the issuer can gain access to the “level playing field” Apple has created inside the wallet. And though marginal when compared to the rate rebate to Apple – Issuers also incur other costs. These include paying networks a token provisioning fee (for tokens provisioned for the life of the device) and then a separate monthly maintenance fee (latter is only if you were to use the network’s OBO – On behalf of – service). And the business impact for enabling Apple Pay hardly stops there – because each Issuer or a partner must enable the customer service functions required to pacify customers who call to decommission credentials due to lost phones, cancelled cards etc. So it’s important to look at the impact of participating in Apple Pay broader than the rate rebate. And further – how it shall tie in to one’s Android/HCE strategy. You didn’t forget about Android, did you?

Next, an integrated auth/payment solution: Other than Apple, no one else could tie together the authentication and the transmission of the credential more fluidly, because doing so requires a tightly integrated approach where hardware (or even processor) level encapsulation of the authentication & transmission of the credential to the point-of-sale as an atomic transaction. Requiring a PIN for payment from within Google Wallet or SoftCard has never been an ideal step – requiring unnecessary consumer intervention that is but a four digit fig leaf (Thank you V/MC for crippling HCE with a ridiculous PIN requirement). There have been concerns raised that a CVV check is inadequate as an ID&V step for adding a card to Apple Pay. I doubt that if I stole a card – the last thing I would want to do is add it to MY Apple Pay account – using MY biometric credentials and go to a physical store to commit fraud VS..oh you know..ordering stuff online and shipping it to a P.O Box.

Finally, Apple’s role as a market mover: After participating in Google Wallet (or) Isis and realizing that neither managed to move the market an inch, from a terminal acceptance standpoint, Issuers were willing to gamble that Apple could break that logjam – by seeding enough phones and sending enough affluent customers using Apple Pay in to stores. Granted – consumers do not yet sort merchants using payment acceptance as a criteria. Apple has to reconcile with the reality that it face – frequency matters and for it to matter – merchants who take Apple Pay matters. I do not patronize Macy’s enough during the week for a payment behavior to set in. That being said – Acquirers & Terminal manufacturers are now energized to reopen this conversation with retailers. We won’t see retailers making any PoS changes in Q4 with the holiday season creeping up, but they could be swayed either way based on the Apple Pay payments volume during the holiday season.

Card Present for In-App Payments through Apple Pay:

Fresh off of its Card Present rate concession – there were rumors that Apple was able to convince issuers to treat in-app payments using Apple Pay as Card Present. However, this is not true. Issuers have not agreed for Card Present rates to apply for in-app Apple Pay Card Not Present transactions. However – you would be surprised how close some of the issuers came around to that notion. I doubt they understood the gravity of such a decision and its impact to their future role in payments. So here’s why issuers/networks have existential reasons for not wanting to go down that road. You know, fairness be damned.

Any cloud based payment option looking to curry favor with merchants have a shared weakness. Merchants love to decouple the credential from the point-of-sale terminal and be less fixated on how the credential is transmitted – so that a more varied and rich interaction can take place. But if that meant that they would have to pay a higher rate – these efforts remain experimental at best, unless they are backed by a merchant friendly funding option – for example: ACH. But those alternatives have not resonated with consumers – and I suspect MCX will be a repeat of that failure in customer on-boarding. You want me to share my SSN and Drivers License to sign up for coupons? Where do I sign up? Sigh. Update: My MCX friends did reach out to point that I am wrong above about indicating that the customer will not be able to participate in any of the marketing related activities unless they chose MCX’s preferred payment type.

It is interesting to see both MCX and Apple arriving at payments from opposite directions. MCX – regardless of its argument that it is all about customer data is really about payment economics. They are incentivizing a switch in consumer payments choice by using offers and discounts as compelling reasons. Where as, Apple is starting off unabashedly with payments – and now that it has established that there is no ambiguity about its choice – is building the rest of the merchant value prop.

Now there is no reason for CNP rates to stay the same as they have since Paypal (irony!) drove consumer trust in online commerce. Our ability to detect and mitigate fraud have significantly improved since then – for example – the device used in the transaction itself can be an anchor in fighting fraud – and so can efforts like tokenization and fraud rules that are nuanced to account for past/aggregate customer behavior, location, items in the basket etc. Merchants instituting any number of these measures are in effect doing little more than reducing their exposure to fraud – knowing there is hardly any advantage to do more – once they have brought fraud down to an acceptable level. Good behavior is hardly incentivized. If merchants had an incentive to improve their fraud fighting measures without negatively impacting customer experience – an incentive that translates to interchange reduction – we would see the whole industry being aligned to fight fraud – rather than pockets of efforts and mis-alignment elsewhere. From where I sit – there is little industry alignment today on this topic.

So when Apple approached Issuers through Networks to bring parity to both CP and CNP – it is believable that the response wasn’t in anyway aligned across issuers. More than one issuer teams responsible for driving mobile payment efforts – had at first blush agreed to that parity, without being fully cognizant of the impact and reach of such a decision. Apple may have been quite persuasive with the suggestion that, since the same credentials in the secure element were being used to authorize purchases through apps – they effectively deserve Card Present recognition. A cogent argument for sure – except it was scuttled when the broader Cards organization got wind of it. Apparently networks in their role in this negotiation had been largely apathetic – but if they knew what they just veered to avoid – they would have been less so.

Here’s why parity poses an existential threat for Issuers, Networks, Terminal manufacturers while benefitting Apple, Merchants and 3rd parties.

Issuers – They hate it for all the obvious reasons and then some. They are loathe to give up the CNP revenue especially when online and mobile commerce grab a rising share of revenue from retail. CNP fraud is a carefully tracked metric across issuers and is less worrisome compared to the non-fraud declines that means lost revenue and ticked off customers. For Issuers, keeping the disparity between CNP – CP is not just a revenue play, but affording them parity may also mean that the liability may begin to shift towards issuer. And no one wants that in a model which allows the merchant to be lax in resolving consumer identity – without being on the hook for it. Further – for all the elegance of Apple’s TouchID, there will be better authentication mouse traps in the future – better ones maybe – and there won’t be any room then for maneuvering other than compressing margins. So it is within the Issuer’s interests to have disparity – fair or not.

Networks – They were apathetic mostly – due to this being more of an issuer burden. But a hidden danger for networks was that the cost of a CP transaction vs the cost of a CNP transaction is not always measured just by the rate differential. For the merchant – once these two rates are brought closer to each other, a bigger incentive takes shape – which is to get rid of the traditional point-of-sale altogether and focus entirely on in-app payments and/or cloud payments. The additional cost of CNP transaction is literally that holds back a merchant from getting rid of the traditional point-of-sale and focus on new pathways for commerce, and new pathways for transmitting the credential from the customer to the merchant. And if that decision is made easy for the merchant – then the traditional point of sale will fall away faster. And the chain of entrenched stakeholders will collapse with it. Once CNP and CP are equal, the merchant can focus entirely on in-app or cloud solutions – and then the infrastructure is pretty much available for newer funding sources to be stacked up in parallel – whether they be ACH, PayPal, Bitcoin or whatever. The difficulty in point-of-sale integration is literally what’s keeping these others at bay.

So I believe no matter how much better of a mousetrap that Apple and others may come to build – the reasons I gave vacate any chance of Card Not Present transactions being afforded the same rate as Card Present. The rate difference and the merchant liability that exists – is a reminder of what dominos may fall if they were ever allowed to be the same. Does it mean that we won’t see rate reductions on CNP? I hope we will – since today the disparity that exists between these rates exist to penalize the merchant and dis-incentivize any real measures in the attempt to eradicate fraud. And we could do better.

So who would have benefitted by such a move?

Merchants – They would love it for reasons that it can now decouple payment from the terminal, be less fixated on how the payment card is transmitted – and look at ways to improve customer experience inside the store without having to corral them like cattle towards the front of the store. Retailers would also put more emphasis on apps as a legitimate strategy to drive more transactions through in-app methods vs forcing the customer to switch to a plastic swipe in-store. Line busting apps would proliferate and so shall interoperability and friction become the primary concerns for apps without having to worry about rate economics.

Third Party Payment Enablers – Google, Paypal, Samsung, FIDO Alliance, App devs et al.

Granted – none of the above today really can compare with Apple in their ability to marry authentication with payment. Other than Samsung – and even if so – no one else has had been able to leverage biometrics to the scale that Apple did, and to allow it to mature and open it up to third party devs – around the same time that it looked to leverage it for payment. But Google, Paypal and others can lay a claim through other anchors – such as the visibility they have had in to the individual consumer and their spending habits – and yet struggle to distill those down to an attribute that is as simple and elegant and as deterministic as a fingerprint. But with Apple guaranteed to make a second attempt at bringing down CNP costs (for reasons I outline below) – these players do not have a lot of time to waste before demonstrating that collectively they are able to do just as much. Once Apple is able to negotiate a better CNP rate – Google, Paypal and others are screwed.

Apple – Apple loves a level playing field. And that was written with tongue firmly held against cheek.

First – Apple’s consistent approach to both retail and in-app payments: The Paypass/Paywave applets in the iPhone6 Secure element are modified to be triggered when a customer authenticates through TouchID irrespective of it being an in-store or an in-app transaction. And because the assurance level guaranteed through a TouchID authentication meets a higher threshold for risk reduction – Apple surely was justified to ask for CNP – CP parity. And if that request was in fact met – Apple would be first to offer Card Present rates for in-app transactions – which means there would have been a stampede of third party developers, retailers to develop for iOS and leverage TouchID for authentication. This would have completely scuttled any meaningful Android development – unless Google and the Android ecosystem collectively got off their butts and lobbied for the same. Which would have been tough to explain – due to the lack of any hardware solution – sans the Samsung Biometric capability which I doubt comes close to the integrated Apple Pay/TouchID approach.

Second – and more importantly for Apple, a parity between CP and CNP would mean that traditional terminals would have been tossed out, those that exist only to ensure that the current payment value chain stays free of disintermediation. The complexity around terminal integration has been the reason for effectively locking out most of the new players – and dumbing down the efforts of those who even had the stomach to attempt (remember the Paypal 4 digit PIN) – and this residual complexity is inherited from the decades of entrenched relationships, software upgrades and business models. If all of a sudden one day – CNP is allowed parity with CP – and traditional terminals gave way to mPoS solutions that did bulk of its processing on the cloud – iOS devices would have benefitted most from that shift. In my post on Apple’s MFi program – I had written more of how Apple shall come to address device security to be solved entirely through hardware – and it’s a powerful message when iOS is angling to be more than a consumer oriented device. If an mPoS platform were to develop entirely around iOS hardware – Apple will have two key components ready to roll – payments and marketing. And those are the only two that truly rely on hardware – solved via NFC and BT/BLE. Everything else can be solved by Apple (Passbook) or its partners and can be ready subsequently. So Apple stands to benefit most from such parity – which is all the more reason for the rest of the industry to prevent it. At the cost of merchants – no less. Payments is so messed up.

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