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

@adrianhopebailie,

> 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.

What is a "complete and atomic payment request"? Do you mean the PaymentDetails part
of the paymentRequestAPI?

As you said, the browser/mediator is acting as a router. It takes as input payment method
identifiers and some payment-method-specific data. Once the user has chosen an app,
the browser/mediator MUST NOT send more information than is necessary to the
payment app for processing. The browser/mediator MUST NOT send the merchant's
full list of supported payment methods, or the optional data for irrelevant payment
methods. Furthermore, the flags of PaymentOptions are irrelevant to the selected payment
app; what is important is the resulting data from the user interaction.

I agree we need to define how the browser/mediator gets relevant data to the
payment app. Handing "the entire blob of data from the merchant" does not seem
appropriate (indeed, could be harmful by sharing too much data, will take up
bandwidth, etc.)

Hence my question: what do you mean by "complete and atomic payment request"?

Ian

---
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-213501992