Short Blog – Chrome AutoFill 

I missed a key development 6 months ago: Google’s Chrome autofill began using network tokens in May 2022 (see article) after the Google Wallet relauch which was announced as part of Google I/O. Google now allows issuers to provision cards to the mobile device and to the browser desperately (see Web Push Provisioning) using network tokenization services (VTS/MDES).  I discussed this in detail in my 2016 post Browser Tokens. 

A Correction to previous blogs. Google’s Chrome autofil has network tokens, but (within the US) does not obtain a liability shift. For Google autofill to get a liability shift (within network rules), they would need to enable the 3DS 2.2 authentication features. Exceptions to 3DS 2.2 are where Issuer has provisioned card with Cryptogram (ie ApplePay card provisioned into wallet by bank). See Mastercard API doc for detail.

Cards on File to Browser Tokens. 

Today most VTS/MDES volume is from the tokenization of Merchant Cards on File (COF). These merchant tokens will begin to be replaced by device and browser tokens which are more secure as it ties both a consumer and a device, to a card (rather than just consumer to card). 

The big picture thought here is that Google’s Chrome autofill is much more advanced (and usable) than Secure Remote Commerce (SRC) and 3DS 2.0. Rather than have a 3DS 2.0 auth challenge presented by the bank, the bank has provisioned the token to the user (for the browser). There is not 3DS 2.0 Auth required (in the US). 

Question: Will GPay token provisioning satisfy PSD2’s SCA mandate or is 3DS 2.0 auth still required?

Google Pay’s transaction volume in browser (ie Autofill) is likely 6-10x that of Google pay in App (and POS) here in the US. Important to note that Apple is still in the lead here, as a single card is provisioned into ApplePay that can be used: POS, inApp or in Browser. My blog subscription takes ApplePay for example (w/ Safari). 

As a Chome in MacOS user, I didnt realize that my auto fills were tokenized. 

SRC Implications

GIven that both Apple and Google have fully tokenized browser solutions, and that these solutions are far in advance of SRC, I’m questioning the viability of SRC.  Browser OEMs would need to implement the payment provider spec for SRC to work, now it seems proprietary APIs have been created by Google which would supersede the w3C APIs. 

I need to assess the views of my European friends. For ex is 3DS still required (ie SCA) . 

TCH Implications

In August there were rumblings of a Google TCH launch (see blog). I discounted much of this because Google Pay has no real US traction. But given this autofill, is there a new vector for TCH tokens? Google has no interest in payment revenue, which makes them a better partner (from Bank/TCH view). Google is also VERY interested in enabling a UPI like platform in the US. Thus it is s likely that Google has a few TCH areas of collaboration. 

Given that JPMC is Google’s processor today, I would love to know if tokenized Chase cards are routed through Visa. 

Of course any routing outside of V/MA, or new TCH product like RfP, is limited by both the gateways and acquirers ability to transform these tokens into the payment instrument (see acceptance hurdles), and also by the consumers interest in USING that instrument (vs their card). 

Sorry to leave with so many open questions. More to come.