Should a payment method identifier (URL) resolve to a machine readable resource that describes the payment method?

[msporny]

The Payment Method Identifiers asks:

If the payment method identifier is a URL, should there be a resource that can be fetched from the URL? Is there a need to describe the payment method at the URL or provide some other information?

[ianbjacobs]

URIs would essentially be namespace URIs, in which case please see the TAG finding:
http://www.w3.org/2001/tag/doc/nsDocuments/

I would not recommend any conformance requirement.

[msporny]

If the payment method identifier is a URL, should there be a resource that can be fetched from the URL?

Yes. The resource should be machine-readable (expressed as JSON-LD, at a minimum) for the reasons specified here:

http://www.w3.org/TR/json-ld/#introduction

Is there a need to describe the payment method at the URL or provide some other information?

We should not require it, but encourage it.

At a bare minimum, you could publish a human readable string in various languages for the payment method. You could also publish the payment method's branding image.

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. It could address the "no available payment apps" use case. I'm not suggesting that's how it would work, just that it seems like there are enough use cases to think more deeply about it.

[halindrome]

I actually prefer the mechanism that is required in RDFa Core. It
basically states that the URI MUST resolve to something machine readable in
an approved format, and then enumerates the approved format(s). And yes, I
think JSON-LD is the right way to go for describing payment methods. I
would not mind if the URI did content negotiation and could also be viewed
as HTML5+RDFa for humans too!

[1] http://www.w3.org/TR/rdfa-core/#s_initialcontexts

On Sun, Dec 6, 2015 at 4:22 PM, Manu Sporny [email protected]
wrote:

If the payment method identifier is a URL, should there be a resource that
can be fetched from the URL?

Yes. The resource should be machine-readable (expressed as JSON-LD) for
the reasons specified here:

http://www.w3.org/TR/json-ld/#introduction

Is there a need to describe the payment method at the URL or provide some
other information?

We should not require it, but encourage it.

At a bare minimum, you could publish a human readable string in various
languages for the payment method. You could also publish the payment
method's branding image.

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. It could address the "no available payment apps"
use case. I'm not suggesting that's how it would work, just that it seems
like there are enough use cases to think more deeply about it.

—
Reply to this email directly or view it on GitHub
#30 (comment).

Shane McCarron
[email protected]

[ianbjacobs]

I don't believe we are chartered to produce a payment instrument description format that would be served at such a namespace URI. I don't think we should try to address this question at this time.

I would not object to saying it's good practice to provide information and once we see what people do, look for some standardization opportunity in the future.

Ian

[dlongley]

I don't believe we are chartered to produce a payment instrument description format that would be served at such a namespace URI. I don't think we should try to address this question at this time.

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:

https://github.com/w3c/webpayments/wiki/Components#payment-app

[adrianhopebailie]

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.

[adrianhopebailie]

Updated title to better reflect the discussion

[msporny]

Migrated to w3c/payment-request#46.