Browser Tokens – Payments in OS Part 4

My last articles on this topic were
I’ll forgive you if you didn’t see the big news out of Google I/O. There is a MUST READ article in Android Police that is spot on. Summary? Google (Chrome/Android) and Apple (Safari) are ready to integrate payment tokens in the browser.. Buy buttons will be integrated into ads, product listings, or a single “pay” button with no subsequent user information to fill out “quasi one-click”. From Android Police

Websites are still where most people buy things, and not all of them will be connected to an instant app. So, Google has a set of web APIs to call up Android Pay, making the checkout process less awkward (see above). This “PaymentRequest” API is being developed with Chrome and will be standardized across browsers through the W3C.
This means any website can put together a small API that asks the browser if it is Chrome and if the consumer has a chrome token (Assist API for auto fill) and a payment token. Apple will likely have the same thing, and if merchant completes this small integration everything on the checkout page “autofills” … at NO COST.   Now Paypal could technically make themselves a payment option with Google (hence the open W3C standard), but it will be up to consumers to make Paypal the default payment instrument within Google’s system.

The merchant advantages w/ Google
  1. CONVERSION regardless of which gateway/processor I choose
  2. “Bundled Pricing” with ad discounts for integrating the API
  3. Improved ad analytics where Google can track intent to purchase
  4. This will all run under the new VBV 2.0 specification and a) Shift liability onto the bank and b) Run under the 3DS rate tier that has been on the books since 2003 (20-30 bps rate reduction in US).
Take these things together with a staged digital wallet fee  (30bps on volume with MA – 2012, Visa rumored to be considering) and this ‘bundled’ value equation make life more difficult for PayPal.. although braintree could still manage the merchant checkout experience.. consumers will self direct into their preferred payment product…  and merchants can select processors that provide the best rate.  The clear remaining opportunity is for Paypal to own small merchant acquiring (which is their international home run). Paypal’s other core asset is payment focus.. which neither Google nor Apple has done a great job of…. But the sales equation is getting harder.

Apple is ready with a similar flow.. my guess is late 3Q. With respect to timing, my guess is that we are still 9-12 months on the liability shift and rate reduction as bank fraud systems must get up to speed and “bake” the new token assurance information within VBV 2.0. This delay will take the form of formal finalization of the new 3DS 2.0 spec and “certification” of individual schemes (Google, Apple, Amazon).

VERY SMART of Google, Visa, and Mastercard to make all of their work sit in standards bodies (EMVCo/W3C). They win with open-ness and ease of use. Networks want everyone to invest…  1000+ companies building on their networks.. standards makes investment more predictable.. and thus allows their role in Commerce to increase.  I think of payment tokens in browser as VisaCheckout and Masterpass without the UI and Google/Apple doing all the browser work and Networks running the standard/rules. The value equation is coming together nicely.. and Issuers clearly win here.. as cards become the defacto standard for payment. Mobile authentication is now extending itself well beyond the Mobile OS to the browser (see yesterday’s Tech Chrunch on Google Auth)

As a refresher, let me tell you how silly the alternate scheme’s value proposition was. The 27 bank consortium (operating with TCH) came to Google in 2011 and said “you should tokenize with us”.. Google asks “we are open to the idea.. what is the value?” Banks “the regulators are going to mandate it and you will get a jump on the competition by exchanging all the cards your customers willingly gave you for numbers we get to control”… Google “umm.. can we de-tokenize as we have things like Google chrome that autofills on eCommerce checkout sites”.. Banks “no.. you can’t do that”.  Google “so we will need to keep both a token and the COF”. Banks “no you should get rid of COF (to give us control)”… Google “??? what are you smoking?”.  BTW.. there was never a regulatory requirement. Now you can see the benefit of moving everything into an open standards body with rules open for comment.

One thought on “Browser Tokens – Payments in OS Part 4”

Leave a Reply

Your email address will not be published.