Re: [webpayments] How are payment instruments registered? (#14)

> their self-description (in manifest form for example) must provide enough information for user agents to retrieve and automatically install the software necessary to make use of them from the Web.

+1 - in terms of what we standardize.

We should specify a mechanism for payment apps to be registered via the browser API as a minimum and then expect platform vendors to offer other ways to achieve the same outcome as they see fit (installed as an app on mobile, as a browser extension on desktop etc).

This may be as simple as:
    "id" : ""
    "label" : "XYZ Bank",
    "icon"  : "",
    "supportedPaymentMethods" : ["", ""],
    "endpoint" : ""

I'd expect the payment mediator to also record what origin this app was installed from and block installation if the endpoint is not at the same origin. Further, I'd expect the payment mediator to offer a way for the app to update the set of supported payment methods over time.

An additional feature I'd like to see is an API like the following that allows app publishers to probe if their app is installed:
This API would only ever return true if the call is made from the same origin as the that which registered the app.

If the app was registered through an alternative mechanism then it should be able to specify it's origin. (I believe app stores have ways of doing this on mobile platforms. i.e. tying apps to an origin.)

Manifests are one way to facilitate this but they shouldn't be the only one as this seems to imply a single origin can only ever publish a single payment app.

I would also prefer the registration of a payment app to be an explicit request from the publisher via the API than something a user may stumble into because they visited the site and it's manifest specifies it has a payment app.

Reply to this email directly or view it on GitHub:

Received on Wednesday, 9 December 2015 10:57:10 UTC