In W3C’s Web Payments ecosystem:
- Merchants request payment via the browser (or other “mediator”).
- Users respond to those requests via payment handlers registered with the browser. These payment handlers are distributed to users by the entities that run payment systems and their participants.
- Payment systems leverage the standard interface for data exchange between merchant web sites and payment handlers to either authorize a payment, or request credentials from the user to authorize the payment via another channel.
Our hypothesis is that, together, these APIs can improve the user experience of making payments on the Web and make it easier to bring payment methods to market. In turn, we think merchants will see more transactions (due to ease of use) and higher conversion rates (due to higher quality data through the APIs).
In particular, we think that the way browsers support payment handlers can improve upon traditional checkout experiences –forms and redirects– in several ways:
- Better user experience. For example, once the user has selected a payment handler, the browser can run it in a modal window to keep the user “near” the merchant site.
- Enhanced security and user trust. Standards enable the browser to provide a variety of other services on behalf of the user, including protecting them against bad actors. In addition, running a payment handler in a browser modal window will reduce the opportunities for click-jacking, compared to iframe-based approaches for embedding a checkout experience in a merchant web site.
- Lower integration costs. We anticipate that coding to one API instead of many will reduce the front end integration cost of supporting a payment method.
One of the most interesting examples of improved user experience involves payment handler distribution. How do we get payment handlers quickly and easily into the hands of users?
First, users can “manually” find and register payment handlers. For example, a user might learn about a payment handler on her bank’s web site. In general we expect manual registration to be a low-friction process that takes place as part of some online wallet or banking experience. For example, when a user logs into a wallet, that might cause the wallet’s payment handler to be registered in the background.
By leveraging multiple standards, the Chrome Team has added a second distribution mechanism called “just-in-time registration”; see the previous post on this topic. Chrome presents candidate payment handlers for registration under certain conditions, including:
- The user has not yet registered any payment handler capable of supporting that payment method.
- The payment method is identified by a URL and the owner of the payment method has provided machine-readable information in a “payment method manifest” that authorizes the browser to show the candidate payment handlers to the user.
When the user selects a candidate “just-in-time” payment handler, Chrome registers it using the information provided by the payment method owner. In essence, this is a very targeted software distribution mechanism, based on what the merchant accepts and what the payment method owner prefers.
We have started discussion about a third distribution mechanism we have been calling “default payment handlers.” I model it alongside the first two mechanisms as follows:
- Manual: If the user has expressed a preference for a payment handler by registering it, the browser shows that payment handler to the user.
- Just-in-time: Otherwise, if the payment method owner has expressed a preference for one or more payment handlers, then the browser shows those payment handlers as candidates for registration.
- Default: Otherwise, if the browser knows about payment handlers, then the browser shows those payment handlers as candidates for registration.
Thus, the preference cascade is: user, then payment method owner, then browser (as a representative of the user).
There are already multiple examples of browsers knowing about default payment handlers through out-of-band mechanisms:
- Safari knows about Apple Pay.
- Edge knows about Microsoft Wallet.
- Chrome and several other browsers directly implement the “Basic Card” payment method. In effect, these implementations are default payment handlers known to the browser. Basic Card support is built into the browser, but in general, default payment handlers could be built-in, or Web-based, or native apps.
Browsers already provide users with similar services for access to search engines. The user finds a default when they first install the browser, but the user can change the default through configuration. We are thinking of the same sort of behavior for payment handlers.
Of course, getting payment handlers into the user’s hands includes browsers implementing APIs for communication with those payment handlers. It is our ongoing project to broaden both Web-based and native payment handler support in browsers.
For now, if you would like to experiment with Web-based payment handlers and Chrome, I recommend Google’s Web-based payment apps developer guide.
Thanks to Adrian Hope-Bailie, Rouslan Solomakhin, Nick Telford-Reed, Justin Toupin, and Danyao Wang for discussions about this topic and editorial contributions.