[w3c/payment-request] To address branded button issues and improve privacy, add browser support for payment method selection before the sheet (#777)

Hi all,
cc @adimallikarjunareddy

This post is inspired by:
 https://github.com/w3c/payment-request/issues/774

I would like to start discussion around a proposal for adding browser support for payment method selection before the sheet. Perhaps we can discuss at TPAC in October.

It seems to me that canMakePayment() is serving multiple roles. Perhaps we can tease those apart into at least least two needs:

 (1) The merchant wants to know whether to provide a Payment Request API user experience or a traditional Web form.
 (2) Having determined PR API is available, the merchant wants to know which payment buttons to show in a manner consistent with brand-specific requirements. 

Perhaps we can find away to limit canMakePayment() usage to just the first one. This would reduce the number of calls, improving privacy and perhaps avoiding rate limiting issues.

To address the second need, I propose that the browser offer a new user experience.

The browser knows the intersection of the payment methods accepted by the merchant and those for which the user has payment handlers.  Today the browser shows that intersection in the sheet.
What we are hearing is that we need something before the sheet as well.

Therefore, I propose the following (at a high level):

* The browser computes the intersection of merchant-accepted and user-supported payment methods.
* The browser automatically displays that information in the page at a location determined through code by the merchant (implementation details to be determined). However, the set of payment methods displayed must not be shared with the merchant (thus, for example, does not change
the DOM).
* For the display, the browser fetches an icon associated with each payment method (e.g., through the corresponding payment method manifest).
* If the user selects an icon, the browser launches PR API for just that payment method. The browser can optimize (as Chrome already does), showing the sheet if necessary or jumping straight to a single relevant payment handler.

Some advantages to this approach occur to me:

 * The user experience would match user expectations. They expect to see buttons on page, and they do.
 * The merchant would have less work to achieve that user experience. They just call PR API and magic happens to get the right logos.
 * The user experience is optimized for the user. The list of buttons is scoped to the intersection, so that improves on the NASCAR effect.
 * User privacy is protected. The merchant does not receive information about the user's environment before the user has chosen a payment method.
 * The sheet is still relevant (when collecting shipping and contact information).
 * Merchants have flexibility. Merchants could highlight payment buttons they want to highlight, and still use Payment Request this way for other payment methods.
 * We may not need any additional specifications beyond Payment Request API and Payment Method Manifest. Note that this idea does not require implementation of Payment Handler API. It can leverage Payment Handler API where Payment Handler is supported. However, see below for my point that for some calls to PR API the merchant may not want automatic button generation.
 * It seems like it would respect brand guidelines for buttons. For example, the user would see the Apple Pay button (if relevant for the transaction) and clicking that button would call Payment Request API with just the Apple Pay payment method.
 * The Web Payments visual identity needs to do less heavy lifting. Users see familiar brands and click those buttons. We can still have a Web Payments visual identity but it doesn't have to work as hard to communicate a user experience people will get when they click on an unfamiliar button.
* For security reasons, it needs to be made clear that this display is owned by the browser, not the merchant. So the display of information is obviously very very important!

So:

 * Does this make sense? What are the other benefits or issues with something like this?
 * Are browsers interested in doing a bit more natively to enhance the PR API user experience?
 * How would the information (namely a list of clickable payment methods) be presented to users
    in a manner that is convenient and secure? How would it work on mobile?
 * Would every call to Payment Request API behave like this, or only some of them? For instance, one could imagine a "Buy" button that calls Payment Request where the merchant really wants their button to be displayed. I can imagine that only some calls to PR API should have this behavior of browser-generated buttons.
 * How would this relate to polyfills that are being used today while PR API implementations are  not yet universal?

I look forward to your comments.

Ian


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/777