Re: [w3c/browser-payment-api] Should the browser API support the concept of "messages"? (#154)

> should a website be able to pass a complete payment request message to the API and expect that message to be passed (unchanged) to the payment app

Yes

> should the payment app be able to return a payment response message and be certain that it will be passed unchanged to the calling website.

Yes

This is important in establishing the role of the browser API within a broader payments ecosystem. 

The browser API is intended to be a way to facilitate exchange of payments related data between parties on either side of the interface. By preventing the complete payment message from being constructed outside the API the browser puts itself in the path of the flow of payment data in a way that is obstructive and unnecessarily makes the browser a gatekeeper in this flow.

The function of the browser in its role as payment mediator is to simply inspect the payment request and determine where to route it (possibly taking input from the user where required).

Unless it is possible to pass a complete and atomic payment request into the browser API the browser will need to construct this complete request dynamically in order to pass it to a payment app. The result is that the website has no certainty about the format of the payment request message that is passed on to the payment app.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/154#issuecomment-213454418