Comments (8)
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.
from webpayments.
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.
from webpayments.
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]
from webpayments.
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
from webpayments.
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
from webpayments.
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.
from webpayments.
Updated title to better reflect the discussion
from webpayments.
Migrated to w3c/payment-request#46.
from webpayments.
Related Issues (20)
- [Payment apps] How can we optimize user experience when there is only one match? HOT 1
- Pull filters out of payment method data HOT 2
- Overview document figure 5 HOT 13
- Propose a payment method specification that includes an example of field level security HOT 1
- propose to add encoding attribute to data set HOT 18
- European market - Security concerns HOT 10
- [Tokenized Card Payment] Replace usage of 'last4' with 'suffix' HOT 8
- [Tokenized Card Payment] TokenCardRequest should inherit from BasicCardRequest HOT 3
- 3D secure support HOT 4
- Sepamail WebIDL syntax and algorithms HOT 4
- Payment Method Manifest spec - should enable country specific app discovery HOT 9
- Fingerprint and version metadata (in Web App Manifest spec) HOT 36
- Should the WPWG develop a cryptocurrency payment method specification HOT 14
- Adopt a "test as you commit" policy HOT 10
- Just a question, curious HOT 1
- Visual Identity for Web Payments HOT 14
- Specify both pickup and delivery addresses in a single payment request HOT 2
- QR use cases HOT 5
- Proposal to restore charter text around UI being out of scope HOT 10
- Pagos alex
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpayments.