Android Pay has just come out on the Google Play Store and it's an interesting concept in many ways. I can't help but be curious about its internal workings and after some discussion with a co-worker, I've decided to quickly write up our initial thoughts on the application.

Scope

These are some initial thoughts I had from a security perspective after using Android Pay for the first time. These observations are purely speculative and black box, so they should not be mistaken for fact. These speculations are being made before having done any decompilation or reverse engineering. I will try my best throughout this document to clearly state the observations driving each speculation I make.

Transparency

The first thing that stuck out to me is that Android Pay does not appear to be transparent to the banks. When I added my debit card to the application, for example, I was presented with an EULA from my particular bank. After that, I had to verify my card by signing into my bank's application. In the case of my co-worker, he didn't have to verify his card, but he did receive an email from his bank within minutes containing information regarding Android Pay. In other words, while I may not know exactly how the Android Pay system works, I speculate that it does necessitate the banks being aware of Android Pay. You'll see why this is important in the next speculation.

Virtual Account Number

The other thing that immediately stuck out to me is that upon adding a card to Android Pay, that card is given a "virtual account number." The in-app description of this number reads, "This number is used instead of your actual card number so that your info isn't shared with stores."

Interesting.

While privacy may indeed be part of the motivation behind using a virtual number instead of the real card number, I don't believe this to be the full story. Having worked in a bank for a short while, I know that one of the biggest concerns a bank has is liability and therefore risk management. As we speculated earlier, Android Pay isn't transparent to the banks. This means that the banks have a choice in participating which, in turn, means that they aren't going to participate unless the risks associated with Android Pay are minimal. I speculate this to be the true reason for the virtual number. By using this number in place of the real card's number, should a vulnerability in Android Pay be exploited, damage is limited to exposure of the virtual number and not the real number. Google can reissue this virtual number while the banks are protected from having to reissue a new card. Granted, a fraudulent transaction or two may occur in the time it takes for the virtual number to be deactivated and reissued, but the majority of the burden falls on Google and not the bank. It's even possible that the banks might have an agreement with Google where Google is responsible for repaying the banks for fradulent charges occuring due to Android Pay.

This idea of risk mitigation will come up again in a later speculation I make.

Transaction Processing

The ultimate question my speculations aim to shed light on is how does Android Pay work? What happens when a user makes a purchase using Android Pay? Given the previous two speculations, we can make some educated guesses. I must stress again that this is still speculation, but food for thought none the less.

Before I reveal my next speculation, a bit of background is necessary. Something which you must understand is that in card processing, time is greatly of the essence. A transaction must be processed in a matter of seconds in order for the customer to be satisfied. In these few seconds, the transaction has to pass through multiple parties. In the case of the traditional card, there's the point-of-sales terminal which swipes the card, some back-end system for managing these terminals, the credit card processor (such as Visa), and the bank (such as JPMorgan Chase). The transaction has to pass through all these parties in order to be allowed.

With that understood, I tease my next speculation with a question: Who translates the virtual number into the real number? Surely this translation must happen somewhere, otherwise why would the Android Pay user provide a credit or debit card number in the first place? I speculate that it isn't Google.

Think about it. If Google was translating the virtual number into the real number at the time of use, the process would become transparent to the banks. There would be no reason for Google to solicit partnership with them. But we know Android Pay isn't transparent to the banks, which is strong reason to speculate that this is not the case. Google likely shares the virtual number with the bank at some point during the process of adding or verifying the card.

Handling the virtual number in this manner benefits both parties. First, this decreases the bank's risk because if the translation isn't handled by Google, then Google won't have to send the real number over the wire to the next party in the processing chain. This benefits Google as well because no translating on their end means no need to build out any infrastructure. They can piggyback off the existing card processing infrastructure.

Unanswered Questions

So who does the translation? If it isn't the retailer and it isn't Google, that leaves the bank and the card processor. Sadly, I don't have an answer to this question.

The other question I don't have an answer for is what is actually given to the retailer via NFC at the time of use. Is it simply the virtual number or is it something else?

These question I leave to the reverse-engineers.