About a year ago I posted about Google Wallet. Since then I’ve been using it where it was available. I still get questions of “What did you just do?” when I use it.
There was a transition time in NFC payment support when Apple introduced Apple Pay. Some businesses even withdrew their NFC payment support, e.g. CVS, over a squabble about fees.
NFC payment took a giant leap forward recently with the transition from Google Wallet to Android Pay.
Google let this transition appear confusing as they repurposed the Android Google Wallet app to a person-to-person payment system and introduced an Android Pay app to effect the NFC payments.
But there’s more here than meets the eye.
In a recent post on an xda-developers.com forum triggered by a deep technical question about rooted devices a Google developer said:
That “ensuring” [that the security model of Android is intact] is done by Android Pay and even third-party applications through the SafetyNet API. As you all might imagine, when payment credentials and — by proxy — real money are involved, security people like me get extra nervous. I and my counterparts in the payments industry took a long, hard look at how to make sure that Android Pay is running on a device that has a well documented set of API’s and a well understood security model.
The above discussion was about rooting and explained why Android Pay was sensitive to that condition. This also explains why using Android Pay requires you to have a lock screen on your device.
Then the developer went on to describe the difference in the relationship of Android Pay to the payment networks.
The earlier Google Wallet tap-and-pay service was structured differently and gave Wallet the ability to independently evaluate the risk of every transaction before payment authorization. In contrast, in Android Pay, we work with payment networks and banks to tokenize your actual card information and only pass this token info to the merchant.
You can experience the difference yourself when you add a credit/debit card to Android Pay. If Google has negotiated with the payment network you will be asked to confirm the addition of that credit/debit card with the payment network. In my experience this is done with a live phone call with the payment network. When that is completed and you subsequently use that credit/debit card in an Android Pay transaction you will NOT be required to enter a PIN.
Alternatively if Google has NOT negotiated with the payment network you will NOT be asked to confirm the addition of that credit/debit card with the payment network. Then when you subsequently use that credit/debit card in an Android Pay transaction you WILL be requested to enter a PIN. This seems to be the same method used by the former Google Wallet app.
This difference in the transaction appears to be related to the tokenization of the credit/debit card information.
Transactions involving credit/debit cards where Google has negotiated with the payment network use a token. Google is not a direct participant in the transaction.
Transactions involving credit/debit cards where Google has NOT negotiated with the payment network use virtual account numbers generated by Google.
Subsequent to my initial experience with Android Pay my financial institution canceled my debit card and reissued it. I went to the Android Pay app, deleted my old card and tried to add the new one. It wouldn’t add. It looks like Google is limiting addition of cards to those that they have negotiated with the payment network.
I don’t consider myself an expert on this subject. This post is just describing my observations.
Originally published at benmoore.blogspot.com on November 9, 2015.