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

@msporny,

Thanks for writing up your list. (I also hope Adrian Bateman and/or Zach do so.) Here are a few comments.

> Technical

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

That's a good question. For the moment, I'm not sure which use cases
in our current charter require the checkout API. There is a smaller
question of whether shipping address should be in or out of the payment
API. But after shipping address, what are the topics in scope for our
charter that the checkout API would cover?

> What if we get the Checkout API wrong? Should we specify APIs to get shipping address, request payment, and polyfill the rest until we can figure out the best way to do it?

I don't think "what if we get something wrong" is a question we
need to focus on. I do agree there is a question of whether
shipping addres is in the payment API.

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

Registration is in scope of our charter. We have not discussed much
lately. I agree we need to.

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

That question sounds like a reference to the HTTP API. Right now there is no question we will do an HTTP API per our charter. We've postponed expectations about FPWD until 1 June. Is there something new in your question?

> What are the combinatorial issues with adding the ability to "get more payer information" to the Checkout API?

I'm not sure to understand the question.

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

Agree that's an important question.

> Strategic

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

That's a reasonable question (per my comment above that I'm not
sure yet what the goals of the Checkout API are).


> What data do we have to study in order to see if the APIs will meet their goals?

I propose these questions instead:

* What criteria will we use to make decisions about API direction? (cf our agenda for some)
* How will we get implementation experience?

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

I'm not sure what that question means. It depends on the question about
goals for that API (and also what's in scope for this WG).

> Operational

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

Personally, I hope that we make a WG decision to take up the work as of the end of the FTF meeting. Our decision will affect who the editors will be.







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