Should this be a part of web app manifest?

[rsolomakhin]

Feedback on Payment Handler TAG review from @triblondon:

The TAG has previously encouraged the merging of manifest formats - having manifests for multiple parts of the web platform with overlapping goals transfers cognitive load onto web developers, and creates debuggability issues.

Where possible, we strongly recommend using or extending web app manifest. It does seem like the payments ecosystem work does require some manifest data that is not origin-scoped, but we want to emphasise the cost to developers of manifestitis and encourage their reduction and removal.

[kenchris]

I am fine discussing and reviewing such PRs for the web app manifest

[RByers]

As I understand it, this is really about ensuring that manifest keys don't overlap so that it is possible to reliably use the web app manifest. And so this is something we can clarify without worrying about it causing a big breaking change (eg. it's not like we'd want to reject paymenthandler manifet references which don't happen to have all the other elements of a web app manifest).

There's a Blink intent-to-ship now which we will likely approve under the assumption that this isn't a serious blocking issue...

[cvan]

I'm probably putting words in his mouth, but @marcoscaceres says in w3ctag/design-reviews#162 (comment) that key collisions could be avoided:

Right now, it's not a problem because I'm tracking all of them (🤞). I think it will have to remain a community effort to make sure we don't stomp on each other for now.

I see Blink's Intent to Ship posts for Web Payment Manifests and Payment Handler.

see @tantek's comments in the TAG review for the Payment Handler API.

@dbaron makes some very insightful points in this TAG review for Payment Handler:

It's not clear to me how browsers plan to explain to users what installing a payment handler means. In particular, will the user need to make judgments about what powers the payment handler has, or only about whether the user wants to allow a particular site to install something that handles payments? (Will the payment instruments then later be identified with that site when it's time for the user to choose them, perhaps?) I think the norm today is that payers think primarily in terms of payment instruments and a little bit in terms of what mechanisms that card supports (e.g., I have this card, and maybe that the card supports both credit and debit), whereas payees (merchants) also think in terms of payment methods or processors since they have different costs to the merchant. So perhaps the user permission issue isn't a big deal, assuming that the intent is the simple form of the question and there's a belief that that form is sufficient. But if there's a need for the user to understand more detail, then it's not clear to me that this system gives that detail in any form that can be presented to the user as reliable or trustworthy information.

I'm a little worried, however, about the proliferation of manifest formats, and (as mentioned above) the proliferation of ways of specifying icons.

and, to conclude with, it seems there is TAG feedback from @triblondon to suggest merging the Payment Method Manifest and the Web-App Manifest formats: w3ctag/design-reviews#231 (comment)

what are the outstanding issues to address to merge this with the Web-App Manifest? or if the spec editors and TAG are comfortable with keeping them separate, are there particular notes that can be added to both manifests to explain the rationale?

thanks in advance for reading through all this 👍

[adrianhopebailie]

Merging the manifests doesn't make sense because they are for very different things.

A Web App is a user application whereas a payment method is a sub-protocol (or specifically a request/response format) of the Payment Request API. The designer of a payment method may wish to provide meta-data about the method to browsers to:

• limit the origins that are permitted to handle payments using this methods
• indicate which web apps (and also non-Web apps) are preferred for processing payments using this method (to facilitate Just In Time installation for example)

If these manifests were to be merged then the only common element would be the origin, in which case it seems what is actually desired is some kind of origin manifest