“A2C”? As in “B2C”? Yes, and I’ll explain later.
ADVANCE WARNING: I am but a humble home gamer with no expertise in payments or tech. Read on only at your own risk/amusement/disbelief.
The (Unlikely?) Extension of In-App Apple Pay to a Essentially-OS-Independent “Remote Payment” System
Some Assembly Required
We all know the basics of how Apple Pay NFC works. A device account number is provisioned to the iPhone 6/+ after the card in question is properly registered. When the user authenticates to make a payment, one-time dynamic security codes are generated and transmitted via the NFC radio to any standard NFC terminal. And there’s some levels of security baked in throughout. (Apple’s iOS Security white paper, which includes information about Apple Pay, can be found here: https://www.apple.com/privacy/docs/iOS_Security_Guide_Oct_2014.pdf)
In-app Apple Pay (page 28 of the paper) works a bit differently, since data obviously has to move within the cloud. From what this home gamer can tell, iOS 8, the Secure Element, Touch ID or device passcode (huh, didn’t know that before now) and Apple Pay APIs (locally) act in concert with “Apple Pay Servers” and a Merchant ID in the cloud. It’s…kind of hard for me to understand. 😀 But suffice it to say, the payment/security/credential flow is pretty tightly controlled by iOS and Apple. As you’d expect.
“What If?”
Tom Noyes, who’s apparently a FinTech expert (sorry, we don’t run a full resume-checking service at the Tree, so take the Money 2020 conference website’s word for it I suppose), recently posted a prediction (with 95% confidence) that Apple Pay would be incorporated into “all Safari browsers” by Summer 2015.
His predicted payment modality is (slightly edited for clarity):
ApplePay on MacBook
- Consumer Checks Out
- Merchant checkout page finds supporting device/plug-in and displays “pay with Applepay”
- Consumer selects pay with Apple Pay
- Consumer’s iPhone 6 comes up with [Touch] ID prompt (touch ID to complete purchase with Merchant X). Side note somehow Apple Keychain management is involved in exchange between devices
- Merchant receives token(s) for user ID and for card. User ID token is resolved through Apple service, Card Token is routed through TSP in current iPhone 6 AP model.
The user-side prerequisites for Apple Pay Web would be an Apple Pay browser plug-in or “supported device” (presumably, a properly equipped Mac), along with an iPhone 5S or 6.
The “easiest” (to deploy/test/debug/control), though most restrictive, way to implement Apple Pay Web (gradual rollout is classic Apple Playbook) would be to require a late-model or yet-unreleased Mac, combined with a certain version of OS X and Safari. But hey, why stop there? In fact, why start there – in terms of involving the Mac at all?
What if Apple kept the Apple Pay payment process between the iPhone/iPad and the Apple Pay servers only?
Benefits and Implications
Apple Pay Web would be an engineering challenge no matter how it was implemented, since actual websites would now have to support Apple Pay (currently, merchant-app developers obviously have to add Apple Pay functionality according to Apple’s own iOS specifications). On the other hand, if the Apple Pay Web experience was just a browser-display abstraction of the actual process, would it be “that much” more difficult than it is now?
“Abstraction?” But wait, you’d Apple Pay Web through the MacBook, right? Not necessarily.
The Web in its elemental form is a window, through which interactivity layers were added over the years. The Internet connection was just the way by which you could transmit the hyperlink click and see the page result loaded onto your browser by the server through said connection.
So, why not make “Pay with Apple Pay Web” a one-click process that, once invoked, doesn’t involve your MacBook at all, but instead directly queries and interacts solely with your iOS device for payment?
It checks the simplicity and security boxes because the Apple Pay process remains strictly between the iPhone/iPad and Apple Pay Servers. When you authenticate to pay, the payment token and data exchange is handled from the iOS device. This removes your MacBook (or whatever) entirely from the actual payment process, and sidesteps any plug-in maintenance issues and even malware/keyloggers (on the MacBook, anyway).
Confining the Apple Pay Web process to Apple Pay servers and iPhone/iPad (since you need Touch ID, after all) has tremendous implications, because that theoretically allows payment “using” ANY OS with ANY standards-compliant, modern browser. All the magic happens behind the scenes after the “Apple Pay Web” link is clicked. The desktop browser is reduced to a thin(ner) client – it “prompts” the Apple Pay server to seek authentication from the iDevice, sure, but after that, merely displays the result of the payment/authentication attempt.
Meaning that you could “Apple Pay” for things via Safari, Firefox, or Chrome…on either OS X or Windows. Or with a Chromebook. Or via a “supported”, standards-compliant or whatever browser under, say, Linux.
Not that you’d generally want to do it, but it also means you could, in theory, use MobileSafari on your supported iDevice. (Awkward as it would surely be.)
It even means, in theory, that an Android browser session could invoke Apple Pay Web on an iPhone – the absolute height of irony.
All the host browser would have to do, given my hypothetical implementation, is get to the right webpage to query the Apple Pay server, identify the iPhone or iPad to pay from (say, enter a device ID or code first) and then load the payment result based on the Apple Pay server’s output (which would be more for convenience and consistency, since the iPhone or iPad would get the confirmation anyway).
Why Lack of Necessity, Development Headaches and “A2C” are Potential Reasons Why We May Never See Apple Pay Web
“Third Wheel” of Apple Pay
Now as nice as Apple Pay Web would be for the truck drivers of the world, it’s not really all that necessary, because desktops and laptops clearly aren’t the future of computing. Apple Pay will work with default NFC in-store for iPhone 6 and above. Apple Pay non-NFC is much more sensibly deployed (at least at first) on the platform with a Secure Enclave and a Secure Element engineered into the same device – in other words, the current flagship iPhone 6/Plus, iPad mini 3 and iPad Air 2 lines.
Apple Pay is exhaustively engineered to “just work” on Apple’s most important (and post-PC) product lines. What incentive does Apple have from a software development/time/resources/support standpoint to devolve the wheel, or at minimum reinvent it just so it works on certain new-generation Macs, which sell in far fewer volumes? If you want your iPhone to be a remote control, that’s what HomeKit is for.
What might Apple be leaving on the table? Well, Safari already runs on the consumer OSes that matter – OS X and Windows – and it already has AutoFill to streamline online checkout.
Until Microsoft miraculously gets its act together and garners tremendous market share gains in mobile, it’s hard to see it leapfrogging Apple with a Microsoft Pay Web system anytime soon. For one thing, it would make more sense for them to deploy it on Windows 10, which isn’t due until mid-2015. People are still downgrading to Windows 7 as we speak. Microsoft’s highest-numbered Lumia (the 1520) doesn’t even bother with a biometric system at present. Sure, it could skip over smartphones and, say, intro a biometric ID/payment platform on Surface first, but that just doesn’t sound very sensible.
That leaves Google. As you know, Google had an in-house smartphone OEM, but has since sold that business line to Lenovo. As far as I’m aware, Google never bothered investing in the fingerprint technology behind the long-forgotten Atrix – not in anything that’s shipped since, anyway. (But did you see the latest Moto X and Nexus 6, neither of which have a biometric security system?)
Google is cloud-based by design. With all of the Android devices on the market today, plus the Chrome OS, why would it bother extending Apple Pay-like, fingeprint-to-pay functionality to Windows or OS X? If you want to pay for things on the desktop web, there’s already Google Wallet.
Now, you could say that being cloud-savvy, Google could steal a march on Apple Pay Web somehow. But there’s one thing Google probably can never match – Apple integration. Besides, any energy Google would be expending on a common Android biometric payment platform – never mind that hardware isn’t a Google strong point – would be spent on Android first (that’s where all the units are) and Chrome second.
I may well be missing something, but it sure seems like the future, if not also here-and-now, of e-commerce is in ultramobile and pocketable devices – meaning that a biometric authentication/payment system on such devices interfacing with the “desktop Web” seems comparatively unimportant.
“A2C”, Disintermediation and Business Discomfort
The other problem with Apple Pay Web is the very nature of A2C – “Apple-to-consumer” commerce. It’s already in play on certain Apple Pay-enabled apps (like Uber) in that no account is required to actually pay for something.
So, while it would be nice to implement a zero-login, zero-account procedure for the desktop Web – err, that’s not how it works today. And I’m not sure that’s a genie you can put back into the bottle. Web accounts, with their useful order histories, customized suggestions and other e-commerce stuff, aren’t going away. “Continue with order as guest” does exist, but to me, generally begrudgingly. To support Apple Pay Web is to exalt that which many companies would prefer not to offer if they had their way.
Do you think major websites like Amazon or Target would be particularly happy with the extension of A2C to the desktop Web? After all, desktop Web e-commerce is still one of the best ways for e-commerce sites to…well…collect consumer data. Which is valuable stuff – Google, Facebook and such, after all.
And that’s where the disintermediation “problem” comes in. Apple’s all for privacy, but as MCX demonstrates, Apple’s interests aren’t necessarily aligned with merchants.
If Apple Pay evolves into a more robust platform with support for loyalty programs and opt-in user identification, thereby addressing “the MCX problem” to some degree, great. But, going back to a prior point, it just makes much more business sense to add those improvements into the Apple Pay-ready iOS platform first.
Just Slightly Too Rube Goldberg for Its Time
Having gone through this embarrassingly uninformed thought exercise, Apple Pay Web sure seems like it’d be a nifty, secure, even fun way to incrementally improve the desktop Web e-commerce payment process. But at the end of the day, it’s more work than Apple Pay as we know it, and quite possibly more trouble than it’s worth. And really, Apple Pay Web just doesn’t seem to be where the “e-commerce puck” is headed, in my humble opinion. So a nifty, unrealized idea it may forever remain.
The AAPL Tree 