Closed cyberphone closed 8 years ago
In https://github.com/w3c/webpayments/issues/156#issuecomment-232338220 I found these interesting lines by @adrianhopebailie
If we come to the conclusion that all payment apps are deployed as Javascript that runs in the browser (the current proposal - not yet documented) then I think we are in a better situation than the one you describe anyway.
which made me even more confused.
How, When, and by Whom is this code supplied?
The code is supplied by payment app publishers in the form of Javascript that runs in the browser in a non-visual context (like a ServiceWorker) and is loaded when the user selects that app.
How that code communicates or invokes other apps outside the browser is then left to the publisher of the app.
If platforms wish to provide alternative ways of running a payment app (e.g. invoking a native app directly) they can do so but that won't be standardized by the WG.
The code is supplied by payment app publishers in the form of Javascript that runs in the browser in a non-visual context (like a ServiceWorker) and is loaded when the user selects that app.
It would be interesting seeing a specification showing how Methods, Domains, Payment Apps, and the PaymentRequest API relate to each other, also including possible Native Apps. It obviously requires a bit of wizardry.
It would be interesting seeing a specification showing how Methods, Domains, Payment Apps, and the PaymentRequest API relate to each other, also including possible Native Apps. It obviously requires a bit of wizardry.
If this is a requirement please log it as such specifically. Closing this issue as I believe the question has been answered.
There is an Web Payment API which can use different payment apps.
However, inside of the API there must still be Scheme-, OS-, and Browser-dependent code for accessing native payments apps if such are used.
How, When, and by Whom is this code supplied?