Payment Handler Value Proposition

In the Payment Request architecture, the user interacts with a payment handler to respond to the merchant's request for data. As the Web Payments Working speaks with more organizations about providing services through payment handlers, it has become clear that we need to collect and socialize the benefits of this approach over other approaches.

Our colleagues from the Chrome Team gave a presentation on this topic at the Working Group's recent face-to-face meeting of the Web Payments Working Group. This blog post borrows heavily from that presentation and a subsequent conversation with Justin Toupin (Google). It also borrows from an early proposal for a modal dialog.

What Payment Services Want

Here is a short list of Web functionality needs —from the perspective of a payment service provider— that could be handled in multiple ways:

• Run the service in a top-level browsing context, often for security reasons.
• Minimize distraction and other UX friction.

Let's compare how different approaches satisfy these needs:

Feedback suggests that the primary and most immediate appeal of payment handlers is the potential for a superior user experience compared to iframes, popups, and redirects. Chrome displays the payment handler as a top-level origin in a modal window that does not obscure the merchant site. This is true in both mobile and desktop views. Chrome also displays the origin of the (Web-based) payment handler. The hypothesis is that this improved user experience will increase conversion rates because it does not abruptly change the user's checkout context and because there are more security signals to foster user trust.

Many merchants today redirect users to a payment service at another origin. In the best case, this is disruptive to the user experience, but usability can degrade further when an error takes place in the payment service. For example, the user may return to the wrong location in the merchant site, or may not return at all. Payment handlers, on the other hand, preserve the original merchant context.

Payment services cannot run as top-level origins in iframes. Iframes also create a risk of click-jacking, and current countermeasures that reduce this risk would make it very difficult to implement required payment and authentication services. Compare this to payment handlers, where Chrome displays the top-level origin and thus reduces the risk of phishing.

Finally, the way that pop-ups work today makes them less than ideal for payment use cases. If the browser opens a pop-up and the user clicks on the window or changes tabs, the browser hides the pop-up behind the window. This can confuse the user. This is especially true on a mobile device because popups open as new tabs. In addition, because it can be difficult to keep track of which tab a popup belongs to, this can be particularly confusing in a scenario where the user has opened a large number of tabs while comparison shopping. Pop-ups are also generally locked down and difficult to invoke reliably due to the measures introduced by browsers to counter their abuse. Finally, some mobile browsers limit the number of tabs that can be opened at any one time (leading to potential data loss). The payment-handler-in-a-modal approach enables the browser to eliminate confusion resulting from user interactions.

Longer term benefits

We also foresee a number of additional benefits that would start to materialize once there is more interoperable support across browsers, and once there are more payment handlers. Some of these include:

• make life easier
  • lower code development costs for payment handler developers (provided the same code works with all browsers)
  • lower integration costs for merchants, as more code moves out of checkout pages into payment handlers.
• improve security
  • browsers can enhance security by checking the digital signatures of native payment handlers (and Chrome does so in its implementation of these APIs). These sorts of checks may not be possible through other approaches.

We have also had some interesting discussions about how payment handlers might be able to increase payment method reach. For example, Klarna showed a demo where the customer received a real-time credit offer through the payment handler, and the payment handler paid the merchant by creating a virtual card. We referred to this as "riding the basic card rails" and the interesting opportunity was to allow for innovation within the payment handler without requiring any changes to the merchant Web site (provided the merchant already accepted a standardized payment method such as basic card through Payment Request). Several people have also raised the idea of connecting payment handlers to browser autofill capabilities, making payment handlers useful even on sites that do not yet use Payment Request.

During TPAC I attended a breakout session on a new idea from Chrome called portals. I wanted to see whether this might be a useful generalization of the modal dialog approach being used for payment handlers. Though very interesting, at first glance it seems it would not meet our needs. (More discussion may be appropriate, of course.)

It does seem that the modal dialog could be useful beyond payment handlers. During TPAC, colleagues from Coil, Google, Microsoft, and Mozilla began to sketch a more general modal window proposal. It would be great if we could satisfy more use cases with such a feature. More discussion is also required on this topic.

Experimenting with Payment Handlers

I have created rudimentary slide deck (Creating a proof of concept for PR API) to help those who want to experiment with payment methods and their handlers. While the data exchanged through Payment Request API by default is limited (by design), this should not limit innovation because one can define the necessary data model in the payment method.

How can you experiment with payment handlers in a world where all browsers do not yet support them? For Google Pay, Google provides merchants a sort of polyfill. Where Payment Request and Payment Handlers are supported, they are used, otherwise the JavaScript provides a fallback user experience.

Please let me know if you think there are additional benefits to the payment handler model!