I was one of the first people in my area to adopt Google Wallet. Everywhere I did business soon knew me as “the guy who pays with his phone” – so long as they were equipped with a compatible terminal. I helped train cashiers how to use this “newfangled” payment method, and even helped identify when terminals were installed – but not configured – to use NFC payments.
I was also one of the folks who was burned by the “Secure element not responding” bug in Google Wallet on the Galaxy Nexus. For those of you who don’t know (or have forgotten), back in 2011 Google Wallet was just getting going. Paying with your phone using a relatively new technology that leveraged “NFC”, and was the peak of geekiness. You could add your bank account to your Google Wallet account, and Google Wallet would use a virtual MasterCard to let you purchase anywhere MasterCard and NFC payments were accepted – which wasn’t very many.
If you wanted to flash a new ROM on your phone (which we seemed to do a lot more of back then than we do today), you had to remember to uninstall the Google Wallet app first – doing so would free up your “Secure Element” so it could be used when you flashed your new image. Failure to do so would leave your Secure Element tied to the now non-existent version of Google Wallet that you just wiped out. In other words, you weren’t able to use Google Wallet on that phone ever again. Well, not until Google Wallet replaced the physical Secure Element with a virtual one – or something like that.
It has taken quite a while for NFC payments to be “widely accepted”, and I’d argue that we’re not there yet. To bridge the gap between NFC payments via your phone and being able to use Google Wallet to pay when the merchant didn’t accept NFC payments, Google released a physical card. Unfortunately, the card didn’t work like the app. The app, in my experience, would debit your checking account whenever it was used. The card seemed to require that you carry a balance inside your Google Wallet account, and wouldn’t draw from the funds in your associated bank account.
Nonetheless, I could still use my phone to pay at lots of places.
Before we go into Apple Pay, and how it’s different than Google Wallet, it’s important to know how credit cards work, at least at a high level.
These days your bank issues you a credit or debit card that uses the Visa or MasterCard systems for processing payments. Discover Card and American Express are the two oddballs here, so we won’t go into too much detail about them. Visa and MasterCard both offer systems to which merchants can subscribe (again, keeping this high-level). These systems let their customers use cards (rather than cash or checks) to make purchases.
Unlike checks, which are just a type of I.O.U. (a promise from the customer to pay the buyer an agreed upon amount via a promissory note – the check), credit cards come with some guarantees and almost instant verification of funds availability. What’s even better, credit cards offer the merchant at least some level of fraud protection, and the consumers at least some level of purchase protection.
All those benefits don’t come free. Credit card processors typically take a few percent of the purchase price plus a dime or so. The merchant typically absorbs this into the cost of their goods or services – in other words, they pass the fees along to you, whether you’re using a credit card or paying with cash.
Apple, Google, and even Samsung are trying to get into the middle-man game – there’s a lot of money to be made there. That’s why Apple and Samsung require your bank to be a direct partner in their ventures – they get to avoid many of the processing fees that they’d otherwise have to pay, and they get to offload a lot of the risk to the bank. It’s a win-win!
Google Wallet didn’t work that way, which was good for users, but not so good for Google, since costs were reportedly higher than Apple’s alternative. The solution was to change Google Wallet to more of a debit card and create another partner-based payment processor, like Apple Pay.
Unfortunately, this brought with it limitations which have seriously degraded the utility of Google Wallet, making Android Pay feel more like a downgrade than anything else.
First off, you can’t add any cards if you’re rooted. Sure, it’s easy enough to un-root, reboot, add the cards, re-root, and reboot, but that doesn’t work all the time. In order to get Android Pay to add a card on my rooted Nexus 6, I had to revert the kernel to stock, I had to roll-back my DPI from 493 to the default, then I was able to un-root, reboot, and successfully add my card. (Of course, I had to re-do all that afterwards, but at least the app kept working.)
Next, you’ve got to use a lock-screen if you’re going to use Android Pay. That makes sense, at first, but the old Google Wallet let you bypass that requirement if you locked the app itself (which would require a PIN to be entered at the time of purchase, rather than an unlocked phone at the time of purchase). Third-party lock-screens apparently aren’t trustworthy enough, so you’ll have to go stock or go home. At least you can set up a pin or password and combine that work with a Trusted Device (like Android Wear or your Bluetooth headset) to get around this inconvenience.
And then there’s the problem with partner banks. I was using Google Wallet just fine with my credit union’s Visa debit card with Google Wallet one day, and was told my card wasn’t supported the next. After reading this article, now you know why, but it would have been great if Google had grandfathered all those who had cards with non-partner banks so those who had been using the app (and advocating its use for all these years) weren’t left with a solution that no longer works.
In the long-run, Android Pay will probably be the best move for Google’s pay-by-phone initiatives. For the time being, it’s just too much hassle for the average user to put up with, and far too inconvenient for the (rooted) power user to work around.