Re: [w3ctag/design-reviews] Payment Handler (#231)

@dbaron wrote:

> I'd still be interested in seeing a reaction to the points in the first paragraph of "Extensibility, permissions, and UI" in #231 (comment) -- in particular, whether the API offers enough information to present sufficient information to the user at the time of installing the payment handler, if user agents believe they should be more restrictive at install time?

The API makes a service worker into a payment handler when the service worker registers its first instrument. This instrument can contain payment method identifier, instrument name, and instrument icon. All these could be presented to the user in a prompt.  The payment method identifier in particular can be used to explain the types of payments that could be handled, e.g., "basic-card" or "tokenized-card".

Because Chrome does not present individual payment handler instruments in its UI, Chrome instead downloads the web app manifest of the current page at the time of payment handler installation and saves the icon and name information from there. These also can be presented to the user in a prompt.

@dbaron wrote:

> the biggest concern behind my question about "running the necessary level of detail through the API" was more about whether the issue of presenting content from the handler's UI inside of browser chrome was a workaround for deficiencies in the API. I see that you've said that you think it's not feasible to avoid this -- but what happens if other browsers aren't comfortable with putting this content inside of browser chrome? It seems like we're then stuck with very little information coming through the API.

It would be difficult to define an API that can accomplish everything that a payment handler might need. For example, a payment handler may ask the user to re-enter their password, enter a captcha, or update their billing address. Therefore, we believe that allowing the payment handler to display an HTML page is the best option.

Another school of thought is that the API must be at least as useful as the existing solutions of iframes and popups. If we restrict the payment handlers too much, API adoption would suffer.

In addition, although Chrome currently displays payment handler's UI in a dialog, it is also possible to use a popup or a new tab to display the payment handler UI in a more canonical way.

@dbaron wrote:

> I'm still concerned about some of the items in my "Other" section in #231 (comment) , especially the first item about specifying how these various Web Payment specifications relate to each other, e.g., the relationship between payment method identifiers and manifests. Many of the other items there are details, but I'm curious if you've looked into them.

I have filed issues https://github.com/w3c/payment-method-id/issues/52, https://github.com/w3c/payment-handler/issues/308, https://github.com/w3c/payment-handler/issues/309, and https://github.com/w3c/payment-handler/issues/310 to address these.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/231#issuecomment-408983474