Comments (6)
If we have a core set of payment messages, are they extensible?
Yes, developers should be able to encapsulate arbitrary information into the core payment messages.
If they are extensible, what is the extensibility mechanism?
Linked Data should be the extensibility mechanism. Specifically, JSON-LD.
Is the browser required to understand this extensibility mechanism?
No, the browser (nor most developers) need to understand the extensibility mechanism. However, there does need to be one and JSON-LD provides a mechanism that looks a great deal like JSON w/o having the extensibility issues that JSON has.
from webpayments.
From Payment Request Architecture
For example, we expect multiple different payment apps to support returning credit card PANs and they should all do so using the same field names.
This seems to imply either:
a) A registry of JSON field names, or
b) A JSON-LD context and Linked Data vocabulary that specifies those field names, their expected types, usage, etc.
Strong +1 for the latter, since there are many other considerations when attempting to create common registries and do decentralized extensibility other than just the names of the fields themselves. Lots of people have put a great deal of thought into b) after failing (to various degrees) at a).
from webpayments.
From Payment Request Architecture:
If we choose to support well-known short strings for payment methods then we will need to determine where to define them. We may choose to define these well-known strings in a formal specification.
You can have well-known short strings for payment methods via a JSON-LD Context (another reason to use JSON-LD). For example, this is easy to do:
{
"@context": "https://w3c.org/vocabs/payments/v1",
"type": "PaymentInstrument",
"method": "Visa",
"paymentService": "https://psp.example.com/pay"
}
which formally means (via a JSON-LD Context):
"https://w3c.org/vocabs/payments#method": "https://visa.com/vocabs#Visa"
"https://w3c.org/vocabs/payments#paymentService": "https://psp.example.com/pay"
No danger of conflicts, formal meaning for what "Visa" means, and the benefit that the browser nor developers need to care about those details (they use the markup at the top, which looks more or less like JSON, which they're used to).
from webpayments.
+1 to JSON-LD context w/ well-known short strings. Has both the advantage that machines can process it and that developers don't need to care about it if they don't want to.
from webpayments.
I am not convinced of the need for decentralised extensibility of the messages.
The message extensions will be defined by the publishers of a payment method specification and the implementors of that payment method will reference that specification.
It's possible that the developers of a payment method specification may choose to use JSON-LD for their payment method so that it can be arbitrarily extended by others but that would be a special case for that payment method.
I worry that if we say the messages use JSON-LD but also say:
Is the browser required to understand this extensibility mechanism?
No, the browser (nor most developers) need to understand the extensibility mechanism.
Then we run the risk of developers assuming they can use the full features of JSON-LD or passing the JSON-LD data through a library that de-references keys or similar and outputs valid JSON-LD but the browser or PSP that consumes it is unable to parse it because they are not treating it as JSON-LD.
from webpayments.
Migrated to w3c/payment-request#40
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.