Apple Pay Aims to Disrupt Payment Industry
Apple CEO Tim Cook concluded Apple’s special event last week by bringing U2 on stage, but the theme song for the middle part of the presentation could have been ABBA’s “Money, Money, Money.” As the 1970s Swedish supergroup sang, “It’s a rich man’s world,” and nowhere was that truism more apparent than in Apple’s announcement of the Apple Pay mobile payment system, due in October 2014 as a free update to iOS 8.
With Apple Pay, Apple’s self-described mission is to replace your wallet, enabling you to pay a bill by holding an iPhone 6 or 6 Plus, or the forthcoming Apple Watch, up to a payment sensor. No more fumbling with credit cards and signing receipts, or worrying about having enough cash. In theory, at least, Apple Pay both improves the payment experience and brings new levels of security and privacy to credit card payments.
(Not to quibble too much, but replacing a wallet is a much larger task, given that carrying official identification — such as a driver’s license — is mandatory or at least a good idea in many countries. Plus, we’re still a ways off from a truly cashless society.)
Apple Pay Payments — The comment about it being a rich man’s world relates to Apple being perhaps the only company that’s sufficiently large and powerful to entice both the financial industry and enough major retailers to support a new payment system. The concept is far from new, and even companies as large as Google and PayPal have tried and largely failed to create mobile payment systems. The problem is one of size and coherency, and overcoming the inertia of the existing credit card system. The previous attempts at solutions weren’t enough of an improvement, due to the fuss of setup and never knowing which retailers would accept your particular system’s
technology or app.
For Apple Pay, Apple has lined up support from Visa, MasterCard, and American Express, and is working with a number of large banks to cover 83 percent of all credit card use in the United States. (Apple said they were “working hard to bring Apple Pay to even more countries.”). Even more important, Apple has convinced numerous major retailers that already support contactless payments to work with Apple Pay, meaning there will be at least 220,000 stores taking Apple Pay at launch. Some of the retailers include the Apple Store (of course!), Disney, Macy’s, McDonald’s, Nike, Panera Bread, Petco, Sephora, Staples, Subway, Walgreens, and Whole Foods, among others.
Apple is also taking advantage of its ecosystem to enable developers to add Apple Pay directly to apps, which will provide one-touch (with the Touch ID sensor in the iPhone 6) checkout of orders made within apps. Apple’s SVP of Internet Software and Services Eddy Cue talked about it working within the Apple Store app, as well as apps from Groupon, Major League Baseball, department store Target, and ride-sharing service Uber. Most interesting was the mention of the restaurant reservation service OpenTable; at participating restaurants, you’ll be able to both book a table via the OpenTable app and pay your bill when you’re done eating. We expect that most apps doing payment will support Apple Pay quickly; the payment-processing
company Stripe has announced that apps that use Stripe will be able to accept payment via Apple Pay once it launches.
Nothing was said about making it possible to use Apple Pay within a Safari-hosted Web page, but it would seem logical for Apple to attempt to crack that nut.
The huge question is whether Apple is taking a percentage of each transaction that runs through Apple Pay. This wouldn’t be the 30-percent chunk that Apple extracts as a transaction fee for all sales through the App Store, Mac App Store, and iBooks Store. But it could be along the lines of the 2.9 percent and 30 cent fees that companies like PayPal and Stripe charge. We’re seeing conflicting reports about this. Benedict Evans of the VC firm Andreessen Horowitz said on Twitter that “Apple does not charge users, merchants or developers to use Apple Pay for payments.” That may be true, but Bloomberg is reporting that Apple will be charging banks a portion of the so-called “swipe fees” that they collect from merchants. Swipe fees account for $40 billion annually, so even a small percentage of that could add up fast for Apple. The BankInnovation blog is also reporting that Apple has negotiated with the banks for lower “card present” rates for payments via Apple Pay, which will result in Apple saving roughly 10 percent on the processing fees it pays.
Apple Pay Security and Privacy — The Apple Pay system relies on near-field communication (NFC), a technology that uses extremely short-range radio waves to establish a two-way communications channel. This is unlike RFID (the technology used to tag pets) which works in only one direction. NFC has been used for payments for a number of years, but typically with stand-alone dongles kept on your physical keychain. This isn’t the first time we have seen NFC on a phone, but never at this scale.
More important is how Apple architected Apple Pay to ensure both security and privacy (and they’re very different). On the security side, Apple relies on the combination of the device and their back-end payment system: the device to handle the secure request for payment, and the back-end system for the secure processing of the payment, all without exposing your identity or credit card details.
When you enroll a credit card on your iPhone 6 (by taking a photo of it), your card number is associated by the credit card company with a unique payment token that is then stored in the secure element of your iPhone. The card number itself is never stored on the phone.
This approach, called “tokenization,” changes the payment process. Instead of sending the credit card number to the merchant, Apple Pay sends the token, which the merchant then transmits to the payment processor, who matches it up with the actual credit card number in their highly secure back end to complete the transaction.
Tokenization has been around for quite a few years, and has grown in popularity since it reduces the risks of card breaches (and especially the compliance costs for merchants). Your actual credit card number is never exposed during a transaction, merely a token that can be regenerated whenever necessary, without forcing you to re-enter your card number for all your recurring bills.
In Apple’s case, it seems the token is tied to a specific device. Lose it, and you can wipe the token using Find My iPhone. Then, just take a picture of your cards to re-enroll them on your new (or recovered) phone. This dramatically reduces your risk since your card numbers are never exposed, not even to the merchant. If a merchant is breached, I suspect Apple will either ask you to regenerate the token, or handle it on the back-end system.
Apple’s Eddie Cue also mentioned that a one-time code is used in the transaction, which could be a more complex form of tokenization that protects both your card and the token associated with your device. That likely eliminates the risk of a lost token being used like your credit card for fraud.
Keep in mind that, as a credit card customer, you have zero liability for fraudulent purchases, but those costs are pushed onto merchants and banks, especially when the bank needs to reissue a card. Also, believe it or not, fraud rates are at near-historic lows, but have been creeping up recently due to the larger breaches.
In terms of privacy, Apple Pay doesn’t go as far as the anonymity of cash, but it’s a lot better than today’s credit card world. First, with Apple Pay, cashiers won’t even see your name, credit card number, or security code. And Apple doesn’t know what you buy, where you buy it, or how much you paid. It’s not as private as cash because the purchase information is still recorded by the merchant and your bank, but it’s better than where we are today with credit cards. It is also consistent with Apple’s unofficial policy of collecting as little personal information on customers as possible.
A Significant Disruption — Apple Pay has the potential to disrupt the existing payment industry (one Rich deals with extensively as a security analyst). It is likely the largest deployment of both tokenization and NFC technologies we’ve seen. Although Apple Pay will initially be limited to those who buy the iPhone 6 or 6 Plus, the Apple Watch will expand the audience to anyone who has an iPhone 5, 5s, or 5c as well, since the Apple Watch will work with those models and includes NFC and Apple Pay support. And with millions of customers in play, merchants will have more and more incentive to buy into NFC readers, which will in turn benefit other NFC-based payment
systems.
The payment industry has attempted to change consumer, merchant, and banking behaviors as we’ve entered the digital era, due in large part to increasing concerns over card thefts and fraud. Apple Pay’s combination of improved user experience, reduced risk, and increased consumer privacy could shake up how we buy things, both in person and online.
"The huge question is whether Apple is taking a percentage of each transaction that runs through Apple Pay."
Benedict Evans: ""Apple does not charge users, merchants or developers to use Apple Pay for payments." https://twitter.com/BenedictEvans/status/509453819655106561
Yeah, just saw that and worked it in. I'm a little surprised (since Apple will eventually need some new businesses to maintain revenue growth), but perhaps they want to do everything to ensure adoption now. They could always start charging a tiny percentage in the future if they felt it necessary. On the other hand, they've kept push notifications entirely free, and lots of companies are essentially making money there too.
Another option for Apple is to become a payment processor themselves, replacing PayPal, Visa, MasterCard or brand loyalty cards.
Why take a slice of the pie when you are supremely placed to take the entire pie by doing a better job than anyone else in the market?
It does seem as though this opens up a lot of possibilities for Apple to make money. :-)
For the moment by negotiating with the backend processors and banks and assuming extra potential risk (which they obviously believe their systems mitigate), Apple are achieving much better than industry norm rates on transactions. Hence offsetting extra charges they (or others) might have had to levy to get this rolling.
Looks like effectively Apple is underwriting and using its financial (and trade) might to kickstart adoption.
How will this work for the bricks and mortar retailer? They'll have an Apple Pay terminal, but what about all the people who don't have an Apple device? Will they have to have a separate terminal for Android devices? And another for whatever other device gets popular? That doesn't seem scalable. The reason credit cards work so well is that all the companies use the same terminal.
If I understand properly, the NFC readers are fairly generalized; the trick is the software on the back end.
So one NFC reader could work for Apple Pay and whatever other payment methods the merchant wants to support?
Yes, I believe so.
Since Apple said that they're piggybacking on the 220,000 locations that already have contactless readers, yes, the same reader should work for everything.
I'll be curious if you can use an iOS device as a reader too, since then individuals could take payments via Apple Pay much like is possible with the Square credit card reader now.
Any device that has NFC by definition has to be two-way. Square announced that they would enable all their merchants for ApplePay ... whether that is in the dongle that WILL have NFC built-in (they have already anounced this part) or by using the built-in NFC radio inside the iPhone 6 and 6plus has yet to be determined. There is no current API ("kit" in ios sdk terms) in the current GM of iOS8...or they have yet to announce one. So the answer to your question is this: Any dongle can contain a NFC radio so therefore, yes, you can use an iOS device as a reader--given the right dongle.
On the iPhone 6 and 6+, the payment token info is stored in the Secure Element. How is this going to work with an Watch paired with an iPhone 5/5s/5c? Presumably, the private data can be stored in the Secure Enclave in the iPhone 5s (does the 5c have one?), but where is such data to be stored when the Watch is paired with an iPhone 5 (or 5c)?
If they can't secure the naked pictures of me with the shapely water buffalo one long summer Nam evening, how do I trust my money to them?
Unlike your passwords and IDs, Apple won't leave it up to you to manage the level of the security of the credit card transaction. They don't want to see the water buffalo pic any more than the rest of us.
Kudos to this response. It is exactly the right tone. Celebs photos were hacked using a combination of social engineering and stupid passwords...or common information found in so many places.
I wonder if there is an option to take payments via a safari page. If I don't have an app, but I do have a service, I might still like to charge for it
Yes during the keynote, they did say it will work over Internet purchase as well.
I went back and listened to the Apple Pay section of the keynote and they didn't mention Web payments at all. Only online payments within apps.
I think the "card" is well overdue for replacement. They crack, get lost,stolen,dont read, get swiped with skimmers, and the list goes on. I think inevitably this NFC will dominate transactions.
According to a Bloomberg article by Elizabeth Dexheimer “according to three people with knowledge of the arrangement.”, Apple is going to charge a fee from banks. I wonder.
http://www.bloomberg.com/news/2014-09-10/apple-said-to-reap-fees-from-banks-in-new-payment-system.html
Thanks, I've worked that in!
Re: "The card number itself is never stored on the phone, and although Apple hasn’t yet clarified for us who stores the credit card number on the back end, we expect it to be Apple itself..."
From what I see, Apple isn't storing the credit card, since they're not involved in the transaction at the store. (Since they've said they don't know the amount of the transaction, they can't be.)
I'm guessing Apple takes the credit card number, hands it to the bank and asks for the token, it then sends the token to the phone. This is why each bank has to be enabled individually, instead of just all Visa cards... It'd be in Apple's security interests not to hang onto this token. If they don't have it, it can't be obtained by hackers unless they have an active hack on one of Apple's systems and they've got it while its in play. Although Apple could also pass the bank the phone's public key so they never have the token in a form that they can read it.
Some more details that we've learned since in Rich's article for Macworld:
http://www.macworld.com/article/2607181/why-apple-pay-could-be-the-mobile-payment-system-youll-actually-use.html
I keep looking at the 6% fraud rate and I'm not sure what it means. I was reading over at ARS: http://arstechnica.com/business/2014/08/chip-based-credit-cards-are-a-decade-old-why-doesnt-the-us-rely-on-them-yet/ that in 2004 the US's fraud rate was 0.05%.
The 6% rate seems far too high, since banks only get 1-4% as a transaction fee, they'd be losing money hand over fist with a 6% fraud rate.