Payment-request: Should payment app registration be included in the conformance criteria of the browser API spec?

[adrianba]

This issue comes from WICG/paymentrequest#5.

From the spec:

There is an open question within the working group about what registration scenarios should be supported by specifications from the group.

[adrianhopebailie]

Changed title to formulate as a question for discussion.

Unless there is a need for user agents to support registration of, at a minimum, web-based payment apps there is a risk that independent payment app publishers become beholden on browser and platform vendors.

As we are designing a system for the web platform we should at a minimum describe how registration of a web platform based app must be supported by user agents.

[msporny]

+1 to @adrianhopebailie's formulation of the problem. We should, at a minimum, mention how web-based payment apps are registered and communicated with to complete a payment flow. This is the minimum bar for browser api <-> payment app interoperability as far as our organization is concerned.

[adrianba]

No, the conformance criteria should state what is needed to implement the spec, which is the PaymentRequest API. Conformance criteria for the registration spec should be in the registration spec. The documentation architecture is designed to allow these to be in their own documents proceeding at their own pace to get to Recommendation and lock in associated commitments when they are ready.

Unless there is a need for user agents to support registration of, at a minimum, web-based payment apps there is a risk that independent payment app publishers become beholden on browser and platform vendors.

In my experience, changing the conformance criteria of a W3C Recommendation has little impact in whether various implementations choose to implement all or part of a set of specifications or in what order different parts might be implemented. I propose we don't spend time on this exercise and instead describe the conformance required to get interop of the content of each spec.

[ianbjacobs]

-1 to including payment app registration in the browser API spec; I agree payment app functionality is a separate concern.

Ian

[dlongley]

I think how one registers a Payment App with a browser should either be in a Web Payments Browser API that covers everything you can do with Web Payments using a browser (request payment, register a payment app), or those two things should be divided into two specs: Browser Payment Request API and Browser Payment App Registration API. Keep in mind that there are other ways to request payment and to potentially register Payment Apps that do not involve browsers.

I do not think we should not create a "Payment Request API" spec that covers _all possible request APIs_ and a "Payment App Registration API" spec that covers _all possible registration APIs_. Rather, each type of API (eg: HTTP, Browser, ?) should define its own set of documents and they can be broken up in whatever way makes the most sense for that type of API.

A minor addendum -- I think that payment registration for the browser API should probably be relatively short; so I would prefer it to be rolled in. It would be good to avoid an unnecessary spec explosion problem.

[ianbjacobs]

How a payment app announces its capabilities is distinct from how a browser learns about it. I think there are a set of capabilities like that that have nothing to do with paymentRequest API and therefore should be dealt with separately.

The way that one registers a payment app with some other software entity that wants to use the HTTP API will likely be different. But the way the payment app announces its capabilities would likely be the same, hence the desire to factor that out.

Ian

[adrianhopebailie]

How a payment app announces its capabilities is distinct from how a browser learns about it

Agreed. The latter belongs in the browser spec, at a minimum for apps built on the Web platform.

[adrianhopebailie]

Conformance criteria for the registration spec should be in the registration spec.

This assume that there should be a stand-alone spec for registration. Payment mediators have two functions:

1. Registering payment apps and maintaining an updated list of the payment methods they have enabled.
2. Accepting payment requests, deciding which of their registered payment apps can process the request and then passing the request on to one of them.

The browser API spec is an attempt to define how a user agent might act as a payment mediator, except that right now it only addresses one of these functions.

[adrianhopebailie]

Being addressed in the Payment Apps proposal.

[tnguyen14]

@adrianhopebailie is there a repo for the Payment Apps proposal?

[adrianhopebailie]

@tnguyen14 not yet. if you want to log issues you can do so in the WG repo at https://github.com/w3c/webpayments/issues (Add the label Proposal: Payment Apps)

[adrianhopebailie]

The proposal draft is here: https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html