Is Apple Pay Revolutionary?
By David Dorf, senior director of technology strategy for Oracle Retail
Going from cash to checks to credit to debit was revolutionary, each step having its own unique business model and supporting technology. Apple Pay, however, is just a variant of existing models and technology. Don't get me wrong — I really like what I've heard so far, but it’s not the radical leap I was hoping for. It is more secure and perhaps slightly easier for consumers, but it does nothing to reduce costs nor does it address all channels. I guess you can't fault Apple as they aren't trying to solve all problems; they are trying to sell more phones.
Let's look at Apple Pay and their competitors for some comparisons from a retailer’s perspective.
Where is the credit card number (PAN) stored?
The traditional approach is to store it in the secure element, a specialized secure chip. Smartcards, like those issued by banks for EMV, are considered a secure element. When it comes to mobile, most phones use a SIM (the chip portion of a smartcard) inserted inside the phone. That's where Softcard (formerly ISIS) stores the PAN.
Since ISIS is owned by the telcos, they have easy access to the SIM. Google, on the other hand, couldn't get permission to use the SIM so they are limited to phones with a separate secure element built into the phone itself. To gain access to phones without a dedicated secure element, Google adopted Host Card Emulation (HCE), which allows for secure element data to be stored in the cloud.
It appears that the MCX CurrentCsolution will also store PANs centrally, and represent them using a QRcode or some other similar means. The merchant scans the code shown on the phone, which represents the PAN.
Apple says the PAN is not stored in the phone or in their cloud. Instead they create a token that represents the PAN and stores that in its secure element. The token has the same format that banks use for PANs except the BIN range indicates it’s a token. Tokenization is not new. I first ran into it 10 years ago with a company called Shift4 (love that name). EMV has created its own tokenization standard which Apple appears to be using.
At some point along the payment chain, the token is converted back into a PAN so the issuing bank can recognize it. So the actual PAN is stored somewhere, just not in Apple's cloud nor in the merchant's cloud. The bank and or payment network secures it.
Winner: Apple Pay
How is the cardholder verified?
For credit cards today, the cardholder is verified using a signature. The coming EMV implementation will also rely on signatures (instead of European Chip-and-PIN), which is woefully inadequate. Google and Softcard require a PIN to be entered similar to a debit transaction. CurrentC seems to have similar protections. Paypal and Visa reported using a cardholder's location as a potential second way to verify authenticity, but neither is beyond experiments. Instead of a PIN, Apple will use your fingerprint. Although not perfect, it’s certainly better than signatures.
Winner: Apple Pay
Could merchant data breaches be avoided?
The EMV chip card simply makes it hard to create counterfeit cards after PANs have been stolen. Until the EMV tokenization standard is required, the PANs are still susceptible to skimming attacks. And furthermore, EMV does nothing to address online or mobile payments, so stolen PANs will likely migrate to those channels.
In typical NFC payment schemes, like EMV contactless, Google Wallet, and Softcard, the PAN is transmitted to the terminal in the clear. Once in the terminal, it’s just as susceptible as if it had been swiped. There is no end-to-end encryption standard, but some solutions do provide it.
Apple Pay and CurrentC avoid this problem by dealing with tokens instead of PANs. In the Apple case the token is transmitted via NFC, and in the MCX case it’s scanned from the phone's screen.
Winner: Apple Pay & CurrentC
Does it work in all channels?
None of the solutions seem to work perfectly in all circumstances. Softcard handles only mobile payments as does CurrentC. Google Wallet and PayPal are efficient at the register, but they require login for online payments and they don't cover mobile in-app payments. Apple Pay works for registers and in-app, but not for online.
Winner: Paypal
Are costs reduced?
NFC requires new terminals, so that covers Softcard, Google Wallet, and Apple Pay. Paypal just wants your phone number at the PIN Pad, and CurrentC scans a code displayed on your phone. Both of those are using existing hardware.
Softcard and Google Wallet don't charge any additional fees, so whatever the payment network charges the merchant is the cost. Paypal tries to fund transactions using the ACH network, which is much cheaper. Apple Pay likely adds a small fee to existing fees charged the merchant. CurrentC is owned by merchants, so one of its major goals is to reduce fees.
Winner: CurrentC
Conclusions
With what I know so far, it appears Apple Pay might be the best solution available today (although I still love what Dwolla is doing). If Apple decides it actually wants to make money from Apple Pay, it will need to open its payment network to non-iOS devices. Doing that soon will allow them to gain momentum with adoption. Otherwise the market will continue to be fractured. There's also the "trust factor," and recent data breaches are doing nothing to endear consumers. Apple Pay can't have even a hint of a security flaw or consumers will run the other way. That's a tall order for a new solution. Time will tell.
David Dorf is senior director of technology strategy for Oracle Retail.