Google: Standardizing Payments on the Web: Introducing requestAutocomplete()

Google is taking huge steps to simplify payments. Which is great!

If you have about 25 minutes then watch this presentation.

The major takeaways:

• Sites should use standardized names for form input field's autocomplete attributes.
  <input id="nme" name="username" autocomplete="full-name">
  id and name stay as they are but site owner should use standard values for autocomplete.
  WhatWG
• The browser presents the user with a dialog that allows to choose between different sets of data; e.g. change to different shipping address.
• On Chrome there is tight integration with Google Wallet and instead of your real credit card information a one time credit card is issued by the Google Wallet backend.
  Caveat: Google Wallet currently is US only!

Google Wallet is only one data source for autocomplete. If Google Wallet is not available then Chrome's local autofill  data is used for autocomplete.

Google said that they talked to other browser vendors but that they could not talks about it right now... Mozilla's Ben Adida compares it to the geoLocation API. Although there is not official statement from Mozilla. Apple shows no reaction yet.


Here is  a screenshot from the presentation showing sample HTML markup.

The documentation is here.

Well, this reminds me of our information card efforts.

Microsoft - the inventor of information cards - took another approach then to integrate into the website. HTML5 was not really there in 2005. Microsoft suggested to use HTML object tags and the website could use the object's parameters to specify what attribute is needed. The Information Card foundation standardized the attribute names.
We did some things differently than Google is doing now and maybe Information Cards where too secure and required too much change on the website. The most important difference between requestAutocomplete and the integration with Information Cards is that the data delivered to the site was a signed SAML token which could contain many more attributes about the user instead of only payment detail.
Providing signed data is kind of a good thing because the site - the relying party - could immediately validate the signature and be sure that the attribute values are issued by a probably trusted issuer. (I won't go into self-issued cards here)
Anyway, it seems the changes needed to be made to the site seemed to have been too big.

Google's requestAutocomplete takes a smaller step. The user experience is probably similar if you compared requestAutocomplete and the information card selection. requestAutocomplete is a big step forward for the current web if it succeeds.
The security improvements are not so big compared to information cards. The one time credit card feature is bound to Google Wallet and other browser vendors might not support Google Wallet. But this is probably not a show stopper. The security level of many current online payment schemes is in fact near zero. And requestAutocomplete is not going to change that.

One thing that I would like to build. Support for requestAutocomplete through a wallet installed on the mobile phone.

So Google's step forward is not as ambitious as the Information Card's one. But...
Who cares if the overall completion rate sky rockets.