This feature should be allowed only for privileged third parties

[agektmr]

I'm a big fan of this proposal, but current framing to make it available through window seems to offer only a slightly better UX than a popup window. I'd frame it a glue with third party applications with specifically catored to things like payment, auth, etc.

Here are benefits of Payment Handler API I consider:

• Less consideration needed for session management in the opened window, because the window opens modal and in-context with the parent page.
• The third party apps can respond to inquiries from the parent window (ex: canmakepayment) without opening the window because it uses a service worker and has a privilege to receive events from first parties.
• The code required to implement the payment app is independent (not need to load a JS at least in theory) and declarative.
• The URL is clearly displayed in the top part.
• It can open a native app alternatively.

I'm a bit worried If browsers make the modal dialog available to any purposes, why would one wants to implement the Payment Request API to launch a payment handler? Anyone can define their own proprietary payment framework, open random website and call it a payment handler without relying on the PR API. That's exactly what's already happening.

I'd make this available only as part of larger frames like Payment Handler API, but indepenedent from the API itself. Here's the idea:

Make it only available in service workers like self.openWindow(). This allows third parties to open the window only when it received an event from a first party. There are no other events than Payment Request related ones that can emit events across the origin borders. Where does the privilege come from?

In the Payment Handler API, the privilege is provided by a whitelist payment apps create which is called Payment Method Manifest.
https://w3c.github.io/payment-method-manifest/

A merchant declare what payment method to use, the browser fetches the payment method manifest and examine which website has the ability to convey the payment method. If one of websites' service worker is already installed, send a paymentrequest event to it so the service worker can open the window.

I believe similar ideas can be applied to identity federation. This can be also used to launch file picker, contact picker, camera, etc etc.

Anyway, my opinion is not to open this up to all web entities.

[adrianhopebailie]

I have a slightly different take on this. IMO this could replace pop-up windows entirely in the long run.

Are there use cases for cross-origin pop-ups that could not be served by a modal window? By making pop-ups modal we eliminate many of the ways that pop-ups have been abused in the past. (i.e. Only one can be shown at a time and it disables interactions with the parent context)

I'm a bit worried If browsers make the modal dialog available to any purposes, why would one wants to implement the Payment Request API to launch a payment handler?

This is a fair consideration but I think the answer is that for many websites PR API offers a "service discovery" interface (in the same way as the Share and Credential APIs do).

As a website I can call the API (with no knowledge of the services the user has installed) and know that one of the services I support will be invoked or the API call will fail.

An important nuance is that I don't have to be explicit about which providers I support, just which services. i.e. If I accept basic card then I don't care which handler returns me the card details as long as I get a valid response.

I like the direction we were going in Fukuoka with discussions around the UI.
i.e. The UA provides a service invocation API (share, credentials, payment request) and then, if the user has multiple providers installed/available prompts the user to pick one (see Share API and Credential API pickers).

This invokes the provider which MAY be a service worker in another origin and the service worker is then able to launch UI through the modal window API.

I think this pattern can be applied to the other use case you mention like files, contacts, camera etc.

The nice thing about this pattern is that the provider doesn't HAVE to be another origin, it COULD be a native application or a built-in capability fo the browser.

However, I think allowing websites to invoke a modal directly is useful because some websites won't support many providers so they prompt the user to select one and invoke it directly.

I'm not sure we should prevent them doing this?

[agektmr]

This is a fair consideration but I think the answer is that for many websites PR API offers a "service discovery" interface (in the same way as the Share and Credential APIs do).

I wish so, but branded button approach is becoming my recommendation over single Payment Request API with multiple payment methods lately for some reasons.

• Payment Handler API is not supported in multiple browsers and requires additional JS fallback mechanisms (Like Google Pay JS).
• To convey payment methods across ones that supports PR API and ones that don't in a single checkout page, branded button approach can serve better.

This will not require "service discovery" characteristic you mentioned.

However, I think allowing websites to invoke a modal directly is useful because some websites won't support many providers so they prompt the user to select one and invoke it directly.

This is exactly the case I mentioned above.

If I could simply replace existing pop up window mechanism with the modal window mechanism in the existing JS library, I'd be tempted to do that rather than building Payment Request API based library from scratch. Why would I?

I like the direction we were going in Fukuoka with discussions around the UI.
i.e. The UA provides a service invocation API (share, credentials, payment request) and then, if the user has multiple providers installed/available prompts the user to pick one (see Share API and Credential API pickers).

Yes, I still like this direction.

[adrianhopebailie]

@agektmr what do you think of limiting this API to only be available to same-origin workers inside specific event handlers?

e.g. Something similar to how we do paymentRequest.openWindow but make this generalized so that it can be referenced by other specs like Credentials API and Share API.

I mentioned this as an option in the TAG review

[agektmr]

@adrianhopebailie I think that makes sense as long as the parent origin can be different (ex. merchant.com sends a paymentrequest event to a payment.com service worker, which opens a payment.com modal window.)

[adrianhopebailie]

Yes, I thin that would always be the case