Demystifying Apple Pay

When Apple Pay was announced in September I was super excited. See, in a previous life (10 or so years ago) I spent about a year consulting in the retail POS space and got to learn a lot about retail and its many inefficiencies, payment processing big one of the biggest offenders. Over the years I’ve been keeping an eye on, mainly because it was so ripe for disruption something better had to come, and Apple Pay is exactly that!

Although many have already covered Apple Pay in detail, I haven’t seen any posts that dive into the technical underbelly of the charge process. In this post I’m going to do just that.

Note: Apple Pay works over NFC as well as in apps that implemented it. This post is about the in-store, NFC version.

Without Apple Pay

Before we dive into how Apple Pay works we should first take a quick look how a payment is processed at a retail store today:

1. Customer collects items and presents them to cashier.
2. Cashier rings those items up on her POS (Point of Sale) system.
3. The POS system turns on the attached credit card reader.
4. Customer swipes her credit card.
5. The credit card reader passes on card information (card number, expiration, name of customer) to the POS system, unencrypted.
6. The POS validates the card number (using the Luhn algorithm) and expiration date, then passes that information to the merchant for processing using a payment gateway. Most gateways require a secure (SSL) connection but some don’t and some older POS systems still pass this information directly to the merchant unencrypted over a phone line.
7. The merchant receives the number from the gateway and looks up the issuing bank, then attempts to collect the specified amount from the bank and transfer it into the merchant’s account. The merchant then returns a response, including whether it was able to collect the amount from the bank, back to the gateway.
8. Almost done… The gateway then reads that response and if it sees a successful charge it will attempt to run a few more fraud checks. Some of these checks can be customized but most aren’t disclosed.
9. The gateway then passes the original response from the bank, along with the result of its checks to the POS system. In some cases, gateways have the ability to immediately cancel transactions it deems as fraud even though the charge was successful. In such cases two transactions take place, one to charge the card and another to revert that charge.

I bet you didn’t think a single payment needed so many steps or involves so many players. Well, now you know.

But there’s one big flaw

The major issue in this process is that the credit card number moved around quite a bit in plain format. This means a malicious hacker listening on any of those connections (between the terminal and the POS, POS and the gateway, gateway and the merchant) can see the number. Even someone looking over your shoulder or a security camera above can capture your full credit card number.

Once the number is compromised there’s no way to change it quickly without completely replacing the card, which takes time.

Apple Pay to the rescue!

Apple really did a great job architecting Apple Pay. From the way it secures information to the way it seamlessly integrates with payment terminals. For that reason the steps are actually similar but have one big difference — Apple Pay doesn’t use your real credit card number. Instead, it uses a token, which Apple calls a Device Account Number.

The Device Account Number

Apple’s solution to the big flaw I mentioned above is very simply to abstract the real credit card altogether so that it never actually has to leave your wallet. Instead, when you link your credit card to Apple Pay, your iPhone will first convert the card number into a token and store that directly into the Secure Element, where it will remain safe.

Let’s look at how Apple Pay converts a card number into a token:

1. The process starts by taking a picture of your credit card or manually inputting the card’s number, expiration, and CVV.
2. Apple takes this information and combines it with the current date and other information that identifies the device, and encrypts that into a cryptogram using a private key that’s most likely derived from your fingerprint. It then sends that cryptogram on to the issuing bank for verification.
3. The issuing bank receives the cryptogram and decrypts it using its private key. It then uses the various data points to ensure the cryptogram wasn’t altered along the way by a malicious attacker.
4. If the verification is successful, the issuing bank stores the card number and creates a brand new 16 digit number which it associates internally with the original number and sends that new number back to Apple.
5. Apple stores the new number in the iPhone’s Secure Element chip, which keeps it local.

* The contents of the cryptogram, other than the obvious card details, are kept under wraps. It’s good that Apple keeps it secure because for us it doesn’t really mean much.

What’s nice about the DAN is that it isn’t derived from the original number (like a hash) or is a result of encrypting the original number. It’s a completely arbitrary set of digits that can never be reversed to find out the original number. Apple calls this the Device Account Number, and it is only valid for the device that it was generated on.

By pre-creating this token, Apple Pay just works with existing payment terminals and doesn’t require any modifications to the software that runs them.

Once a transaction is complete, there’s one extra step to the flow. Instead of just sending the transaction result back to the merchant, the issuing bank will also send the result back to Apple to push to your device, where it’s stored for a about 30 days. That information includes: whether the transaction succeeded, the amount, the location (city and state), and the merchant’s name.

Apple claims this information isn’t saved anywhere other than locally on your device.

Tokenization isn’t actually that new

While this seems revolutionary, tokenization isn’t a new concept, albeit, just a concept. In 1994 the world’s largest credit card companies (Europay, Mastercard, and Visa) got together to figure out how to make credit card payments more secure. They came up with the (badly) named EMV spec. The spec describes a process in which information isn’t passed in clear text between devices and prevents a hacker from stealing sensitive information when it is sent from and to the merchant. Later on, a tokenization system was described and then implemented by Visa to enable replacing real card numbers with tokens.

Apple didn’t create something new, and that’s good. New things, especially the kind that involve money, take a long time to develop, require lots of forward thinking, and are always rough around the edges the first few iterations.

The real problem however was that those companies only controlled the retailer side of the process and hence relied on the credit card being swiped. This is, obviously, still vulnerable to hacking and so this spec wasn’t wildly adopted.

Apple was able to skip that hurdle altogether by offloading the process of creating a unique token from the POS system to the customer’s device. This means there’s no longer any need to expose the real card number outside of the customer’s device.

Apple went above and beyond the existing EMV spec. It did using a few pieces of technology that have been added to the iPhone over the last few iterations, a move Apple pulls regularly:

First Apple added Touch ID to the iPhone 5S. It didn’t do much other than let you unlock your phone with your fingerprint. Now, Apple Pay uses your fingerprint to create the cryptogram used to get a unique token.

Then, Apple added NFC and a Secure Element to the iPhone 6 and 6 Plus, as well as the new line of iPads to communicate with POS terminals and speed up the encryption process so paying with Apple Pay isn’t slow.

Most stores and POS vendors are already equipped to accept Apple Pay

Given that Apple Pay relies on NFC, a technology that has been around for a few years now, to communicate with POS terminals, I expected that it’d work with every POS solution that supports NFC payments. In theory this is very correct, and in my testing it’s almost correct in real life.

But…

I set up an NFC reader and tried to process a $5 transaction. Technically everything went well — the iPhone found the NFC reader and popped up the payments screen, the NFC successfully received the information and passed it on to the gateway, but for some reason the transaction kept getting declined.

I called Chase to see if they’d know what’s going on but they had no information about the decline, which makes me think it’s something in the way our merchant account is set up. I contacted our payment processor and am waiting to hear back on whether there’s something we need to do to enable Apple Pay.

There you have it, a complete look into the nitty gritty of payment processing with Apple pay.

No technology is hacker proof, we know that, but Apple pay definitely raises the bar, making it more difficult for hackers to put their hands on useful information. In a time where retailers and financial institutions see breach after breach, Apple pay is a comforting evolution.

Originally posted on http://arielmichaeli.com