Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)

> In any case, the proposal is not to devalue or "not do" the HTTP API but to de-prioritize it to save the editors re-doing it when the messaging in the browser API stabilizes.

The PaymentRequest API does not define an independent message format. Full stop.

Even if it did, you are making an assumption here that the browser API messages will stabilize before we go to FPWD. I highly doubt the browser API will stabilize in the next month or two (based on our current rate of progress). I'm happy to be proven wrong, though. :)

Waiting for the Browser API to stabilize before doing anything on the HTTP API doesn't seem like a workable strategy. Remember, an FPWD doesn't have to be anywhere close to perfect. FPWDs are published mainly to demonstrate that we are making *some* progress and to give the world some idea of the types of things we've made it a priority to work on.

Fundamentally, if the group thinks that publishing an HTTP API is an important thing for us to do (and I think we have consensus on that), we can't push work on it out to some unknown timeframe. We should either 1) publish an FPWD of the Browser API and HTTP API at the same time, or 2) publish an FPWD of the Browser API and them immediately switch focus and publish an FPWD of the HTTP API.

The Web Payments CG's Browser API proposal demonstrates that the same messaging format can be used in multiple APIs (Browser, HTTP, Bluetooth, etc.). It demonstrates this in the spec and it demonstrates it via the web-payments.io polyfill. The Web Payments CG's Browser API *and* the Web Payments CG's HTTP API (and ISO20022) have been designed w/ a shared message format at their core. The PaymentRequest API does not and it does not have the notion of a shared message format.

So, to go back to the proposal: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized.

One of these things might be going on right now:

1. The messaging schemas are stable enough for FPWD because there is a set of specs from the Web Payments CG that demonstrates (with spec text and a polyfill) how the same messages can be used between both the Browser API and the HTTP API, or
2. We haven't had the opportunity to really dive into this in the WG, but there is nothing in the Payment Request API that enables that discussion to happen, so postponing the discussion just kicks the can down the road instead of dealing with something we really should be discussing as a group.

COUNTERPROPOSAL: Focus on releasing a Browser API FPWD and then immediately switch focus and define a common Payment Messaging FPWD and HTTP API FPWD (based on anything we may learn from the Browser API).

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