Word had it that Google was readying a clone of Apple Pay -- right down to the name! -- and as it turned out at Google I/O yesterday, the word was right. Google is indeed releasing its own Android-based payments system that supersedes Google Wallet and goes toe-to-toe with Apple Pay.
The two systems are remarkably alike, but even if the ways they diverge are subtle, those subtleties add up to a lot. Here are three of the most important differences and what they'll mean to the average phone-wielder.
1. Android Pay works for KitKat users and higher, but Apple Pay works only in iOS 8 on just a few devices
What'll it take to run Android Pay on your phone? Three things: the Android Pay app, support for NFC, and a version of Android that's at least KitKat (4.4) or higher. The APIs needed for Android Pay were introduced as of Android 4.4, so anyone running a slightly older phone -- such as the Samsung Galaxy Note II, stuck at 4.3 -- is out of luck.
Still, Google is trumpeting that "7 out of 10" Android devices can use Android Pay, and new smartphones from AT&T, Verizon, and T-Mobile are set to have Android Pay preinstalled. That could be interpreted as a swipe at Apple, whose Apple Pay requires the latest iOS version (8) and an iPhone 6 or 6 Plus, which are the only devices that have the necessary NFC system.
On the other hand, Apple's "new devices only, please" approach forces a degree of additional security. Only the iPhone 6 and 6 Plus, as well as the Apple Watch when connected to an iPhone 5 or later smartphone, support Apple Pay in their hardware. All rely on the Secure Element encrypted hardware chip that stores the financial credentials, the iPhone 6 models rely on their Touch ID thumbprint reader, and the Apple Watch relies on the Bluetooth pairing with and matching Apple IDs on the iPhone.
Android Pay will work on Android smartphones that don't have a fingerprint reader (most Android devices don't have one), although it's unclear what kind of authentication it'll support outside of that. It is known that the Android smartphone has to be unlocked, so users who enable passwords or other forms of locks will have that protection.
Another possible disadvantage to Google's approach is that it doesn't control the entire stack -- hardware, software, apps -- the way Apple does. According to Jan Dawson, chief analyst at Jackdaw Research, Google "just creates Android, and then OEMs and carriers have to decide which elements and features to support, which means there's lots of room for something to break down or the implementation in an individual device to be poor."
Upshot: Android users will have the numbers, but Apple users will have the better security -- at least for now.
2. Android Pay never uses your real credit card, just like with Apple Pay -- but it's done a little differently
For the sake of safety, both Android Pay and Apple Pay eschew transmitting an actual credit card number, even an encrypted one. Instead, they send one-time tokens to the merchant, so even if the token is intercepted, it can't be traced back to a specific credit card, and it can't be reused for additional transactions.
Where the two systems part ways, though, is how they implement this behavior.
Apple Pay uses the Secure Element chip on the iPhone as part of the token-generation process (and also to store fingerprint data). Like its Google Wallet forebear, Android Pay uses a different technology, HCE (Host Card Emulation), a way for an NFC-equipped mobile device to emulate the behavior of a contactless smart card. HCE can also be implemented with a Secure Element chip, but Google's implementation of it on Android doesn't require this -- at least, not yet. There's nothing that says it couldn't be mandatory on future Android smartphones, bringing the two systems into parity.
Upshot: Google's approach is less secure for starters, but it's still a sight better than plain old card-swiping.
3. Apple Pay isn't going anywhere
Apple Pay will stick around even with Android Pay being on potentially so many more devices. And it isn't because Apple's implementation more secure out of the gate, either. It's because the two technologies are going to be serving two entirely distinct markets -- Apple and Android users -- without giving either one of them much incentive to leave for the other.
If anything, it means both Apple and Android users now have reason to stay right where they are. Apple users will be happy to know the payment system on their platform of choice has been outfitted with modern security features, and Android users will be thrilled to know they can make payments with a smartphone at many retailers just like these Apple users can.
If Android Pay threatens anyone, it is the forthcoming Samsung Pay.
Upshot: The only real pressure will be on users of earlier versions of either type of device to upgrade to a newer iPhone or Android smartphone. Very few will dump one platform for the other over mobile payments.