Re: [webpayments] Machine readability of payment methods? (#30)

>We certainly don't have to go very far with a description, but we will need some basics for the API to function, eg: information that goes into the manifest described in this architecture doc

The manifest described in that doc is for payment apps.

The function of a payment method identifier is simply to help the payer and payee establish a set of methods that are supported by both sides. i.e. It's just an identifier

For a payment app to support a payment method it will need to understand a potentially complex set of actions that need to be performed when receiving a payment request including how to interpret any custom (payment method specific) fields in the request and how to produce the correct response message.

It seems very unlikely that a payment app would ever be able to simply pull down the machine-readable description of the payment method and be able to spontaneously support that payment method.

In fact I'd be in favour of the payment method URI pointing to the root of some documentation for that payment method to assist payment app and payment gateway developers in implementing the payment method.

>You could also make it so that a payment method URL may list the payment apps that are capable of processing the payment method. This would make it easy for user agents to retrieve a payment app if one isn't available in the user agent already.

Some embedded machine readable content like this would be useful but would require the payment method publishers to maintain this list.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/30#issuecomment-163120286