Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89)

> * Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?

I think this is a good question but will be implicitly answered by this: 

> * What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?

There is a strong desire from the browser vendors to "streamline the checkout experience" including gathering shipping data. (Please keep me honest here @adrianba, @zkoch, @bifurcation, @nickjshearer, @haavardmolland)

The goals in our charter go beyond this which suggests other flows are needed for other use cases or a low level payment API is needed that can be used to compose other flows.

The paymentRequest API takes a different approach to the checkout API on how these two functions are exposed and we should decide which we like most.

> * Are we going to support "payment app" registration via the API or is it going to remain unspecified?

+1 - We need to start defining this. The CG proposal does address registration but I think we need to answer the following question before we can tackle registration:

* How will payment apps be implemented?

Which you partly address in the question:

> * How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?

I also think we need to decide if there is such a thing as a Web-based payment app or if we're advocating for something like a sandboxed ServiceWorker? Hence the broader question above.

> * Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

I think we're making good progress on this in the list but don't believe we can close this till we've tried to implement the UI and understood the constraints properly. To my mind there is still too much hand waving about flow of control and inter-dependancies between steps.

> * How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

We should consider this in the finer details of the design. The flexibility that the checkout API offers is my preference but we need to consider situations where a call like `request('billingAddress')` may be made in future in a browser that only supports returning the shipping address. i.e. Versioning

>     Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?

Editors chosen and WG spec in a W3C repo soon after the face to face would be my hope.

>     How are we going to fix the transparency issues and backchannel discussions in the group?

Are there transparency issues? There's no restriction on people have sidebars but any impact those have on the deliverables need to still be made via a proposal that gets group consensus. Think this will be related to the choice of editors and work process we define for the specs.

>     Is the "incubate the specs in a CG" model working?

Don't think we should tackle this at the F2F. It's a topic for the AC.

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