Re: WPWG Priorities

It would also be nice to come to a conclusion on shipping/billing address
field names.

https://github.com/w3c/browser-payment-api/issues/6

We have two proposals at the moment:

   1. OASIS xAL based names: regionCode, administrativeArea, locality, etc.
   2. IETF ECML based names: countryCode, stateProvince, city, etc.

I've been working with OASIS names in Chrome, but changing to IETF would
not be a big deal for Chrome.

On Wed, Apr 20, 2016 at 8:21 PM Adrian Bateman <adrianba@microsoft.com>
wrote:

> Thanks Zach. As we begin working through issues in our initial
> experimental implementation
> <https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webpaymentsapi?filter=f3f0000bf&search=payment>
> these are basically the same topics we’re wrestling with and want to lock
> on.
>
>
>
> There are a few issues that follow on after these in our list such as
> locking on the address fields (it’s clear that there is no perfect solution
> but we need to pick something and try it out). But this list is the highest
> priority for us first.
>
>
>
> Once we get past these we think that it will make it easier to get more
> experience to help us shape the API is it relates to possible different
> payment methods.
>
>
>
> Cheers,
>
>
>
> Adrian.
>
>
>
>
>
> *From:* Zach Koch [mailto:zkoch@google.com]
> *Sent:* Wednesday, April 20, 2016 5:16 PM
> *To:* Payments WG <public-payments-wg@w3.org>
> *Subject:* WPWG Priorities
>
>
>
> Hi Chairs and WG Members -
>
>
>
> *Note: I'm speaking here as a member of the WG, not as an editor.*
>
>
>
> Given that we've now reached FPWD, I want to propose we start focusing on
> resolving issues that will allow us to start shipping experimental
> implementations of the API on the web platform. This means focusing on
> issues that affect the fundamental shape or interaction model of the API.
> By focusing on a key set of issues, we can hopefully prevent the case where
> different, incompatible versions of the API are being shipped.
>
>
>
> To that end, I've identified the following short list of issues as ones I
> think we should focus on getting consensus around, hopefully starting on
> tomorrow's call:
>
>
>
> *1.) Payment Method Identifiers (#11
> <https://github.com/w3c/browser-payment-api/issues/11>) - *This is at the
> top of the list for me. We need to make sure merchants can declare payment
> methods in a way that is consistent across implementations. We have a few
> proposals on the table, but I think it's complex enough that it will merit
> time on a call (or the full call) to move forward.
>
>
>
> *2.) Finalizing how "total" is passed in (#18
> <https://github.com/w3c/browser-payment-api/issues/18>)*
>
>
>
> *3.) Complete() and its accepted values (#17
> <https://github.com/w3c/browser-payment-api/issues/17>, #129
> <https://github.com/w3c/browser-payment-api/issues/129>)*
>
>
>
> *4.) Support for collection of email and phone (#1
> <https://github.com/w3c/browser-payment-api/issues/1>, PR #65
> <https://github.com/w3c/browser-payment-api/pull/65>) - *It seems like
> we're circling around consensus here, so discussion on a call might help to
> quickly resolve. At the very least, I'd like to resolve how we can get
> "email" in.
>
>
>
> This is not to say that other issues the group has highlighted are not
> important (e.g. registration), and I very much hope that discussion of
> those continues on Github in parallel. But given that we only have one
> opportunity per week to discuss live, I'd like to start making concrete
> progress on the above issues.
>
>
>
> Thanks,
>
>
>
> Zach
>