What can I do with a URL-based payment method identifier?

[rsolomakhin]

During a TAG review of Payment Handler, a reviewer raised concern that it was not clear what a user agent could do with a URL-based payment method identifier. For example, does a manifest live there?

Payment method manifest ingestion is something that we have defined in the payment method manifest spec, but we should also mention it in this spec.

cc @dbaron

[ianbjacobs]

Hi @rsolomakhin,

There used to be some text in the spec, but it was removed. However, I think at the time we did not have a Manifest spec, so maybe we could add mention to the spec, e.g.:

CURRENT: Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Best Practice document.

NEW: Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Manifest specification and the Payment Method Best Practice document.

Thoughts?

Ian

[rsolomakhin]

That change sounds good. Perhaps we can be even more clear by adding this sentence at the end of the paragraph:

"These documents describe how to find the payment method manifest from a payment method identifier, allowing the user agent to discover installable payment apps, for example."

That wouldn't be too much, would it?

[stpeter]

Maybe s/installable/available/ (it's not clear to me what we mean by "installable" - does it imply that an app can be installed "in real time / behind the scenes" or that payment apps require an explicit installation step?)

[rsolomakhin]

"available" sounds good.

[ianbjacobs]

Updated proposal (deleting both installable and available):

Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Manifest specification and the Payment Method Best Practice document. Together, these documents describe how the owner of a payment method can manage the ecosystem of authorized payment handlers and how the browser can discover them (e.g., for just-in-time payment handler installation).

Ian

[stpeter]

@ianbjacobs I think we've gone astray with the last sentence. What about payment methods that don't have "owners" (say, Bitcoin) or that don't require authorization with a controlling entity (say, Interledger)? I liked what @rsolomakhin proposed, modulo the one word: "These documents describe how to find the payment method manifest from a payment method identifier, allowing the user agent to discover available payment apps, for example."

[ianbjacobs]

I am not uncomfortable saying "owner of a payment method" in the sense that some entity controls the origin. I also like adding the other bit about manifests - that the entity controls the ecosystem of payment handlers.

Here's a simpler version that does not say owner:

Developers wanting to use a URL-based payment method identifier for a third party payment handler are encouraged to read the Payment Method Manifest specification and the Payment Method Best Practice document. Together, these documents describe how to manage the ecosystem of authorized payment handlers for a payment method, including just-in-time payment handler installation by the browser.