Android Pay isn’t the first time Google has gotten into the mobile payments business. Google demonstrated Google Wallet way back in 2011, and released it in these United States that September. The Google Wallet used NFC and a “secure element” in your smartphone to take advantage of contactless payment terminals which were slated to replace traditional swipe-to-pay card readers. Since then, Apple has gotten into the game with its own product, Apple Pay, and Google has restructured and re-released its service, this time calling it Android Pay. Despite all the technological mumbo jumbo, there is one big question on everyone’s mind: Is Android Pay safe?
To answer that question we need to dig into how money works – and it involves a story about bees.
Historically, when someone wanted something from someone else they would barter or trade something of similar worth. Both parties would agree to a mutually acceptable exchange and carry out the transaction all on their own. While this is arguably the most “fair” method of transacting business, it’s also one of the least convenient. I’m a beekeeper, so I’ve got raw, bottled honey available (but not on-hand). My co-worker’s husband is a hunter and she has some extra deer meat in her freezer. Together we were able to agree on a mutually acceptable exchange: honey for deer steak. That’s all fine and dandy when two people have things the other wants, but not every trade is as easily facilitated.
To accommodate more generic trades, “currency” was “invented”. Currency (which comes in many forms) has a mutually agreed upon value. Here in the States, that co-worker and I could have figured out the value of the deer meat and the value of the honey in terms of dollars, and exchanged greenbacks for the goods instead, but they have their own pitfalls.
Greenbacks, or “dollars”, are more accurately described as Federal Reserve Notes (FRNs). They’re basically business checks from the Federal Reserve Bank which are backed by the “full faith and credit of the U.S. Government” – in other words, they’re I.O.U.s.
FRN’s aren’t hard to carry around, they’re accepted virtually everywhere in the country, and they’re relatively difficult to counterfeit. They, too, have inherent problems, paramount among them being their relative insecurity. Once you lose your FRNs – whether you misplace them, burn them, flush them down the toilet, or they get stolen – they’re gone.
To protect against this, banks and other financial institutions were set up. They’ll safeguard your money and let you withdraw it pretty much any time you want (as long as they’re open for business). To help customers have access to their deposits and spend their money more readily, banks let their customers write checks against their balances (another kind of I.O.U.). Checks aren’t always accepted and are much easier to counterfeit than FRNs, but they do offer a little more protection than simply carrying your money around in your wallet.
Merchants assume the risk of selling goods or services that are paid for with checks. If the check is fraudulent or the account it’s drafted against is overdrawn, the merchant has to eat the loss (and try to recoup it later).
To help protect the merchant, some new banking networks were created. Visa, Mastercard, and others came into existence. These networks replaced cash and checks with a plastic card tied to the customer’s account. Merchants could imprint or swipe the card and Visa or Mastercard would guarantee the funds. They don’t do this for free. For this added protection, the merchant has to pay a subscription fee, a transaction fee, and a percentage of each purchase price to cover the convenience and the added protection.
The problem with credit cards is how easily they can be “stolen”. No longer does a criminal have to break into your house or mug you on the street, now all they have to do is hack into a database from half-a-planet away.
To combat these new vectors, credit card companies have added expiration dates to their cards, card verification numbers, and even billing address zip code verification. Still, credit card information is being stolen at an alarming rate these days.
I’m an early adopter. I ride the cutting edge of technology like a surfer carving the perfect wave. Well, at least that’s how I’d like to picture myself. Nevertheless, when Google Wallet was first introduced, I happily jumped at the opportunity to use it. I added my bank information to my account and was ready to use my phone to tap and pay for all kinds of stuff. Unfortunately, there weren’t many places set up to use the technology at the time Google Wallet originally came out. I could buy my drinks at the local convenience store with Google Wallet, I could buy lunch at a local fast-food Mexican restaurant with my phone, and surprisingly, the local farm supply store was also set up to work with NFC payments. (You should have seen the faces on the old geezers behind the counter when I bought a bag of chicken feed by tapping my phone to the reader!)
Since then, Apple has released Apple Pay, which is set up a bit differently than the original Google Wallet system was. This system required banks to sign up with Apple, and Google followed suit when it rolled out Android Pay earlier this year. The services work a little differently than credit cards, but they use the same kind of system.
Both services generate a temporary credit card number that is used for your transaction. Should this number be compromised, it’s likely that it’s already expired and won’t be used to drain your account. As far as security goes, that’s the biggest advantage of Android Pay and Apple Pay.
These systems use a “token” approach, rather than the static number on a traditional credit card. On both platforms you have to have some level of device protection enabled to be able to use the app. This can slow down the payment process while you unlock the phone or app, but it’s relatively quick, and absolutely worth the extra layer of security it provides.
Once you’re in, your app talks to the Android Pay server to ensure your tokens are up-to-date. If you don’t have an internet connection, you’re still okay – for a while. You can perform a limited number of transactions without a connection to the ‘net. Think of this like a credit card with a very short expiration date. Once that date passes you’ll need to get a new card to make more purchases – but here, that “new card” is an updated token that’s created automatically for you once your app syncs with the server. The whole concept is called Host Card Emulation, or “HCE” for short. The way it works is a bit more technical than what I’ve described, but that’s a pretty close “tangible” example.
What if you lose your phone?
To answer that question we first have to ask what happens if you lose your wallet, or just your credit card. In those cases, you’ll have to call the card provider to report it as lost or stolen. They’ll issue you a new card, which you’ll get in the mail in a few days. In the meantime, charges on that card will be rejected – or if some slip through, they won’t be held against you (if you reported it in time).
If your phone is lost or stolen, it will automatically lock after a short amount of time (mine is set to one minute). After that you’ll have to unlock the phone to be able to use Android Pay. If you can’t unlock the phone, you can’t buy anything with the phone. Pick up a new phone, log in to your Google account, install Android Pay, and you’re back up and running – possibly even the same day. You can even deactivate the lost phone so even if someone was able to break through your lock screen they wouldn’t be able to use Android Pay.
Is Android Pay safe?
There are always going to be holes in any system – even trading deer meat for honey. Google has taken everything we’ve learned about paying for stuff over the decades, addressed all the known holes, and bundled all that together into an app and a service called Android Pay. Is it perfect? Nope, but Android Pay is a lot safer than virtually any other way you can pay.