How Apple Pay Really Works and Why You Should Begin Using it Immediately
Published by Kirk on , updatedThe announcement of Apple Pay was met with much press, and a lot of misunderstanding. Without naming names, it’s fair to say that there are a great number of misconceptions about how it works and why it’s superior (and, to be clear, it is vastly superior) to existing payment mechanisms. Before we get started on how it actually works, it’s useful to look at the existing problem.
What’s wrong with current credit cards?
In the United States, the answer to this is just about everything. Your credit card number, or in industry parlance Primary Account Number (PAN), is embedded in a primitive magnetic stripe on the back and, just for good measure, typically embossed on the front. There is no meaningful security on the card itself. For use in phone/internet transactions, the card also has a three- or four-digit security code printed on it as well, though this number is not absolutely required for transactions, and seems to be requested only at random. When you go to a store, you swipe your card and your plain-text PAN is seen by the merchant, then sent for verification through what you hope is a securely-encrypted connection to the credit card processor. The problems do not lie with that end of the transaction. MasterCard, et al., and the issuing banks generally do a fantastic job of keeping their systems incredibly secure. The problem is with the merchant. They get to see your number and store it in their systems, which can be handy for returns, but also problematic. The Payment Card Industry (PCI) Security Standards Council has created strict rules governing the storage, use, and transmission of cardholder data, and while merchants may be required to be PCI compliant, that doesn’t necessarily mean they actually are secure, or that there are not other holes the compliance measures have not fully accounted for. The number of large merchants that have announced major credit card breaches just in the past year is sobering reminder of this.
What about chipped cards?
Outside of the United States, most countries long ago switched from using so-called “magstripe” cards to much more secure EMV cards, more commonly known as “Chip and PIN.” The United States will finally begin switching over to EMV cards over the course of the next year, though most banks will issue “Chip and Signature” cards instead, that forgo the added security of using a PIN. These cards are a huge improvement, notably by generating single-use security codes, but they still transmit the PAN in the clear and provide no benefits for online transactions. The merchant still gets your number, and the merchant is the problem. There are just too many of them, with too many possible security holes. The only way to keep your account safe is for the merchant to never have your PAN in the first place. As part of the switch to chipped cards, all merchants will have to update their credit card terminals, if they have not already done so. The October 2015 “deadline” for the switch isn’t a hard deadline, but it is when the liability shifts, and that should be plenty of motivation for most merchants. Right now, if someone uses a credit card fraudulently, and the merchant follows the basic acceptance rules, then the credit card issuer is liable for the fraud. After the switch, if the merchant has a chip-capable terminal, but the credit card itself is chipless, then the credit card issuer is still liable. But, if the credit card company has issued a chipped card, but the customer has to run it using the stripe because the merchant hasn’t upgraded terminals, then the merchant is liable for any fraud. Since credit card terminals don’t last forever anyway, and a single incident of fraud could be very costly, the conversion should be rapid. The non-accidental timing of Apple Pay coincides with a hardware upgrade that is already going to happen regardless, which will help finally make NFC contactless payments common. The one critical side effect of America’s switch to accepting chipped cards is that almost all of the new terminals will also include support for contactless payments as well.
Apple Pay and the “Device Account Number”
Here is how Apple described Apple Pay in their press release:
When you add a credit or debit card with Apple Pay, the actual card numbers are not stored on the device nor on Apple servers. Instead, a unique Device Account Number is assigned, encrypted and securely stored in the Secure Element on your iPhone or Apple Watch. Each transaction is authorized with a one-time unique number using your Device Account Number and instead of using the security code from the back of your card, Apple Pay creates a dynamic security code to securely validate each transaction.
The “Device Account Number” is Apple’s term for a payment token. Rather than attempting to build some entirely new, proprietary payment method, Apple took the emerging technology of tokenization (another product of EMVco), and created a new implementation on top of it. The primary scenario in the tokenization specification is that the merchant still reads the PAN from your card, but when the payment is authorized, the merchant is given a token that they then save in their system instead of your actual credit card number. This solves the problem of hackers stealing your number that has been stored, but doesn’t help if the PAN is intercepted before then, such as the case if a malicious program has been loaded onto the card terminal itself.
A payment token “refers to a surrogate value for a PAN that is a 13 to 19-digit numeric value that must pass basic validation rules of an account number, including the Luhn check digit. […] Payment Tokens must not have the same value as or conflict with a real PAN.” In other words, to a merchant, a token looks just like any ordinary credit card number. A token for a Visa credit card will be 16-digits and start with a 4, but it cannot be used like a normal credit card number. A thief could steal a PAN and easily use it to make an online purchase, but a token won’t work. To clarify the most common misconception regarding Apple Pay, the Payment Token is not single-use. Every time you use a given card with a given phone, the same token is used. This is still secure, however, because the Payment Token can be used for transactions only as part of the overall tokenization scheme. Specifically, a token can’t be authorized without the token cryptogram, referred to in Apple’s press release as a “dynamic security code.” A token cryptogram is “generated using the Payment Token and additional transaction data to create a transaction-unique value. The calculation and format may vary by use case.” If someone were able to steal that token from a merchant, they couldn’t use it for an online purchase, or load it onto a fake credit card to use; the number would be declined because the thief cannot generate the dynamic security code.
How Apple Pay Works, Step-by-Step
The first step to using Apple Pay is to add your credit card to Passbook. You can use the camera on your iPhone 6 to read the cardholder data directly from the card. This is the only step in Apple Pay where your PAN is ever used. The PAN is sent over an encrypted connection first to Apple, who has to see the number to know which bank to route it to. Apple deletes this number after you have added the card. The PAN is then sent to the credit card companies who generate and send the payment token back to Apple in an encrypted format that can be decrypted only by your phone. Apple never sees the token and acts only as an intermediary to send the token back to your phone. The actual process of generating and storing tokens is done by either your issuing bank or, for example, Visa and MasterCard offer an “on behalf of” service for banks where they handle the tokenization process. The token is not cryptographically generated, and while certain elements can be set, the number is essentially random, which means it is impossible for a malicious agent to figure out the PAN from the token. The issuers maintain a “token vault” that maps tokens back to their respective PANs, and there can be multiple tokens for a single PAN. Once your iPhone receives the token, it then stores it in the Secure Element. When you go to pay in a store, your iPhone transmits the token to the merchant along with the token cryptogram, which is generated at transaction time by the Secure Element using the token and additional transaction-specific data. The token and this security code are sent through the normal payment networks where the token is finally mapped back to your PAN and your bank (hopefully) authorizes the transaction. The merchant never sees your actual account number, nor even your name. Your private information stays private and secure.
Also, note who is not a part of the payment process: Apple. Once you add your card to your phone, the rest of the transaction is between you, the merchant, and your credit card company or bank. Apple never knows where, when, or how much you spend using it. Apple does, however, get a small percentage of the credit card transaction fee each time you use it, perhaps as compensation for reducing fraud. The participating banks keep track of transactions coming from Apple Pay and make periodic lump-sum payments to Apple. They also provide Apple with high-level statistics regarding Apple Pay usage, but nothing user-specific.
Convenient and Secure
One of the objections I’ve seen to Apple Pay is “How is it faster/easier than just sliding my card?” The truth is, it isn’t always. It’s rarely going to take longer than sliding a card, but it’s not always going to be radically faster either. However, it is much, much more secure. Merchants simply can’t be trusted with your card number, and the only real solution is to never give it to them. Apple Pay solves that, and it does so in a way that embraces industry standards and is easy and maybe even a little bit fun.