Re: [webpayments] Minimum necessary information for merchant to process payment (#27)

I would agree that the request and response message do need some standardized basic fields. They should provide a basic structure that payment method specific data can hang off.

It's debatable whether or not the response needs to be standardized since the content doesn't need to be interpreted by the browser or website and can simply be passed to whoever is able to interpret the responses that are sent for a specific payment method (probably the PSP).

>The message format should not require special processing by the web developer or browser, and should avoid JSON-LD processing by the PSP and merchant unless some kind of significant data format validation/verification, like signature verification, is being performed.

Why use JSON-LD at all if the consumers don't need to process it as JSON-LD. That feels like a slippery slope where a developer, recognising that they are building a JSON-LD response, does so using features of JSON-LD that the PSP is not expecting and the PSP expecting a JSON with some specific characteristics gets something they can't process.

>The extensions to the request and response format should be documented in the payment method vocabulary/registry. The registry should be a living document under the control of the Web Payments IG. Optionally, JSON Schema could be linked from the registry and used to validate the messages and their extensions (this functionality would be optional).

I worry about us proposing a system where an entity like the IG needs to maintain anything of significance over time. The basic message structure should be very simple and provide just enough for intermediaries in the flow (such as the payment mediator) to do their jobs.

Beyond that all of the message content will be specific to the payment method and has no need for standardisation.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/27#issuecomment-163159946