If you’ve ever bought gas from inside the station, or perhaps some aspirin from a national pharmacy chain, you’ve probably seen those payment terminals with a Touch Here sticker at the top, inviting you to pay by just tapping the terminal with your credit card (instead of swiping). If you saw Tuesday’s video demo of Apple’s new Apple Pay system in action, you probably noticed something very similar.
That’s because payments using Near Field Communications (NFC)—the technology behind those swipe-free terminals and now Apple Pay—is nothing new. The technology has existed since the late 1990s and appears in many forms, including key fobs, payment cards, and even (on certain phones) Google Wallet. It isn’t necessarily the most widely deployed payment technology, but it certainly isn’t new.
Which begs the question: Why all the hype about Apple Pay? Is it merely the Reality Distortion Field hyping something that’s actually ho-hum? Or is there something deeper here?
Something borrowed, something new
The easiest way to understand what is new about Apple Pay is to walk through the process of using it.
The first step is, you buy an iPhone 6 or 6 Plus. These are the only phones to support Apple Pay, because the entire system relies on two new pieces of hardware: the secure element and the NFC chipset.
Phone in hand, you next need to load it with a credit card, either by taking a picture of your credit card or by approving an existing card that’s already tied to your Apple Store account. Apple is the first vendor to support this loading system—possibly because it may be the first to get permission from the credit card brands to do so.
Serenity CaldwellBut this is where things get interesting. When the iPhone scans the number off your card, it doesn’t store it locally, or even on Apple servers. According to Apple sources, Apple mediates a connection to the payment network or issuing bank associated with your card, which then provides a Device Account Number.
This technique is known as tokenization. Tokenization has many flavors, but at core what it’s doing is replacing a sensitive piece of data (your credit card number, say) with a random piece of data that (typically) has the same structure and formatting. For example, there are a variety of tokenization systems that take a real, 16-digit credit card number, store it in a database, and return another 16-digit number that meets all the structural requirements of a credit card (it passes the LUHN check).
Tokenization is great because it reduces or eliminates the need to update legacy systems that expect a credit card number, without ever exposing the real number. Tokenization is typically handled by the payment network, which (in some implementations) encrypts the credit card number right when you swipe it, sends it back for the token, and then provides that to the merchant to keep for things like refunds or customer tracking. If the merchant’s system is breached, no real numbers are exposed; the tokens can also be merchant-specific for any given credit card, making them useless anywhere else.
Tokenization also works for online payments, usually by redirecting the consumer to a payment portal (or capturing the traffic to the site), collecting the card, and then passing the token back to the online site’s systems.
In both scenarios there are still exposure points. In point of sale (PoS) terminals, the credit card number is potentially still exposed every time you swipe it. In online transactions, it is exposed to attack on the computer you enter it from, the network you connect to, and the payment site that collects it.
Now back to our story
Apple has established partnerships with enough issuing banks and payment networks to cover the majority of credit cards in the United States. Each of these is responsible for taking the card number you scanned on your phone and issuing the device account number. Unlike my example above, in which the token is on a per-merchant basis, with Apple Pay you get a unique token for each card and each iPhone.
Right at the start, this is a powerful combination of usability and security. Enrolling a card is dirt-simple and effectively frictionless (you might think having the card in hand is a security control, but that’s easy to fake). Using per-device tokens means that only the bank that issued the card (or its payment network) ever has your card: You don’t have to trust Apple with it. This is different from the Google Wallet system, in which Google holds your cards on their servers. (For the record, Google is exceptionally good at maintaining that kind of security).
The next steps are even more interesting.
The Device Account Number (token) is sent to your device and stored in the secure element. Secure element isn’t an Apple term like Secure Enclave. It refers to protected memory on smart cards that’s reserved for high-security operations. If you have a SIM card in your phone, it has a secure element; so do most NFC chipsets. The secure element is the hardware piece that card brands require of anyone performing contactless payments.
Previous contactless phone-payment options required users to unlock their phones and (usually) enter a second passcode to unlock the card number from the secure element. Apple skips all this thanks to Touch ID. Just hold your phone near an NFC reader, approve with your fingerprint via Touch ID, and the Device Account Number (not your credit card number) is used for payment. This is dramatically faster and easier than entering passcodes.
Apple Watch will have its own secure element and Device Account Number. We don’t yet know the process for registering your card on the watch, but it is expected you’ll be able to use the watch without an iPhone to make payments. Go for a run wearing your Apple Watch, and you’ll be able to buy water at a gas station without pulling out a wad of sweaty cash from the tiny pocket in your running shorts. Security-wise there is a clear assumption here that physical possession of the watch is sufficient, but then again, so is physical possession of a credit card. Taking the Apple Watch off your wrist locks the screen, requiring a passcode to unlock, so there is still additional security.
Online purchases will follow a similar process, but limited to supporting apps. The app requests the Device Account Number from iOS using the new Apple Pay APIs, which is then used for the transaction. This won’t work for any site you visit with Safari, only for approved App Store apps.
Why Apple Pay is different
Apple Pay is far from the first mobile payment system. Google Wallet was released in 2011, a collection of mobile phone companies back Softcard, and even PayPal targets mobile payments. However, none has gained wide adoption, and Apple Pay is clearly poised to shake things, for several reasons.
First is the usual attention that Apple pays to the entire user experience. With Google Wallet, you need to enter your card numbers by hand, either online or through the app. To make a payment, you need to use the app and unlock it with a passcode. Although Google Wallet can work with NFC, the actual implementation depends on the hardware and software combination of your Android phone. Even if your phone has NFC, if it doesn’t have a secure element too, you can’t use it for contactless payments. And if your phone does have a secure element, it may not be accessible to Google Wallet because it isn’t accessible to the NFC chipset or due to carrier restrictions.
Those same mobile phone carriers are the ones backing the competing Softcard product, and they haven’t seemed very supportive of Google. Also, Google stores your card on its own servers and mediates and records all transactions with the payment networks. (Wallet issues a virtual prepaid card to the device). Google protects this with its privacy policy, but the company still has full records of all of your transactions. Softcard is also an app, only works on approved phone models, and is carrier-specific. The carriers back Softcard, in part, so they can track your purchases and use that information for their own purposes.
By contrast, Apple Pay works with every new iPhone and Apple Watch. Apple doesn’t track your transactions, and your privacy is protected even from the merchants.
But aside from the technical differences, Apple is in a unique position due to its business model. It doesn’t want or need to track transactions. It doesn’t want or need to be the payment processor. It isn’t restricted by carrier agreements, since it fully controls the hardware. Google, although first to the market by a matter of years, is still hamstrung by device manufacturers and carriers. Softcard is hamstrung by the usual greed and idiocy of mobile phone providers. PayPal has no footprint on devices.
This is a long-term investment by Apple, and possibly one of the most important since it first built the iTunes Store. Apple is putting its muscle behind improving the user experience of making payments, and using that to sell more devices. It won’t make much directly from Apple Pay now. But as more people use supported devices and push more merchants to support the user experience, odds are that those small per-transaction fees will grow into a significant source of revenue.
Using systems like Apple Pay also reduces merchant risk. You might not know it, but merchants pay the costs of fraudulent purchases, and online providers pay higher per-transaction fees due to the higher risk of not seeing the card. Issuing banks pay the costs of re-issuing compromised cards. (You’ll notice VISA, MasterCard, and American Express don’t seem to pay much of anything.) No wonder merchants and card issuers like Apple Pay: it reduces their risks and costs.
Apple Pay is simply more secure for merchants and payment networks, and more private for consumers. Better user experience, better security, and better privacy, all backed with a business model that makes sense for nearly everyone involved (except merchants and carriers who want to track your behavior): I think we can see where this is headed.