-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How do organizations layer additional information in the core payment messages? #40
Comments
This was partially resolved (via WG resolution) in the Web Payments CG spec via this language: http://wicg.github.io/web-payments-browser-api/#extensibility |
Also, the API allows for payment-method specific data. |
See also this issue about feature detection: I suggest we close this issue. Ian |
-1 to closing the issue because of the following reasons:
It's currently left unspecified how any of this payment-method specific data finds its way to a payment app. |
I believe point one is covered by |
@ianbjacobs agreed that point 1 is covered by #44. I was responding to the "close this issue", which we shouldn't do until there is a PR that's been accepted that covers 1 and 2 above. |
Extensibility is covered by #44. The developer accesses
|
Where is it specified how the payment app gets access to that information? A native payment app? What about a web-based payment app? |
For some very limited definition of extensibility. I'm asserting that not everything about extensibility is covered by #44 and there is nuance here that we need to discuss as a group. We still haven't had the discussion around extensibility that the Web Payment CG specs raised via the Messaging spec (see PaymentRequest) here: http://web-payments.github.io/web-payments-messaging/#payment-request |
Partially -- that may cover native payment apps, but not web-based payment apps. The Web Payments CG spec specified a mechanism by which web-based payment apps received a payment request message (which are extensible by nature). |
I maintain that a web-based payment app is an essential requirement for this API. The alternative is native thin payment apps that communicate with their web service outside of our context. I mean - that is what is going to happen anyway with any native payment app IMHO, but there is no reason I can think of to require that sort of an architecture. A payment app (read web app) should be able to register a URI that gets invoked using messaging we define for the various interactions we require. |
Please note the resolution taken by the group on this issue: We require an explicit conformance criteria that guarantees that if a website passes unknown properties or attributes in the payment request that these will be received by the payment app. We don't yet have the extensibility document which we resolved to create and link to, so the approved issue text doesn't make sense yet but an issue marker in the same vein should be added. |
In TAG review @triblondon said:
|
Comment cited here is from @triblondon instead of me |
Addressed by #44.
Partially addressed by #50 for the case of native payment apps. The unresolved and unaddressed aspects of this issue have been forked to #146 |
Migrated from w3c/webpayments#18:
Are the core set of payment messages extensible?
If they are extensible, what is the extensibility mechanism?
Is the browser required to understand this extensibility mechanism?
The text was updated successfully, but these errors were encountered: