[w3c/browser-payment-api] What is the extensibility mechanism for the payment request and response messages? (#146)

Forked from #40 

The concept of "messages" has been raised in numerous issues and PRs but not clearly defined. 

There is a requirement for websites to be able to construct a payment request message (a JSON-serialized object) that is passed to the API and passed, unchanged by the browser, to the payment app that processes the payment request.

Likewise, there is a requirement for payment apps to be able to construct a payment response message (a JSON-serialized object) that is passed back unchanged to the website that made the original request.

The need for JSON serialization of these messages is driven by a requirement to pass them across process and network boundaries. Until such a mechanism exists there will be no standard for interfacing with payment apps which implies they will either be built into the browser or their integration will be entirely proprietary. Put differently, the current API spec has no conformance criteria imposed on browsers to support third-party payment apps.

It is unclear how the current API would cater for this requirement to pass an unaltered payment request message on to the payment app as the current design does not allow for a complete message to even be passed to the API.

There is a proposal to address this #133 BUT this issue assumes that this will be resolved (either through that or some other proposal) and that what is being discussed here is how this message can be extended.

In #40 @triblondon (in his review for the TAG) made the observation:

> AFAICT, the merchant doesn't know about payment apps, only payment methods, so it's hard to see how custom data not tied to a payment method could be useful.

This suggest that it's not necessary (and would be very difficult) to facilitate extensibility of the whole payment request message.

However, there was also a previous resolution by the group at https://github.com/w3c/webpayments/issues/83 to include the following text in the API spec once a companion document was available describing how the API parameters could be extended:

> The JSON-LD Payment Extension specification (linked to the document) explains how to extend the parameters used with this API using JSON-LD.

This suggests that the requirement is to define a standardized format for the payment request message which maps directly to the WebIDL definition of one of the input parameters to the API and includes extension points for the custom payment method data.

---
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/146