Web Payments Working Group Teleconference

<AdrianHB> Agenda https://github.com/w3c/webpayments/wiki/Agenda-20160519

<Ian> scribe: Roy

There are 3 issues related to addresses which we will try to get though

1) issue 186, adding a careOf field to shipping address, PR 197

not many comments on PR so far

any strong objections to PR 197...crickets, decided to merge

<adrianba> We agreed not to keep changing address fields - hopefully this is the last time

issue 2) PR 198, changes a few shipping address field names, regionCode -> country, etc

Adam: the way region is used is confusing, this is the most important field to update

<dlongley> "locality" is a bit more international than "city", but i'm not going to complain

Adrian: any objections?

<Ian> +1 to editors picking something not crazy

no objections at this time, moving on

Issue 27

<Ian> Should API support billing address capture (for tax computation)?

issue 27) billing address capture, no proposals yet, the issue is going to sit on the backlog until a proposal is made

Adrian: we should move to settle an address fields asap so implementers can get started

AdrianB: trying to explore whether the billing address can be associated with the payment method itself

<AdrianHB> +1 that billing address is prob something that's part of the payment method

AdrianB: billing address is important for tax computation particularly in europe
... maybe there can be an optional flag for billing address, but better requirements are needed to fully understand the problem

Adrian: we need feedback from those familiar with tax calculation and what the requirements are there
... agree that if address is required for use of a payment method then it makes sense to place the address there

Jason: european tax calculation on digital goods are taxed based on customer location, IP alone is not enough

<dlongley> i think these requirements support the idea of a lower-level API/components to allow websites to get this information as needed based on their own requirements.

Adrian: should we expect websites to capture billing address before calling payment request api or do we want the api to support it during its flow
... we need a concrete proposal on how this might work

Adam: concerned about the user experience when the merchant gathers one type of address and the api gathers another, address acquisition should be in one context

<ShaneM> +1 to what Adam said..

<Zakim> dlongley, you wanted to be a wet blanket

<ShaneM> (on the other hand, I won't ever use this part of the API)

Dave: second with Adam, not sure we can capture all use cases in our flow, its a moving target, new regulations can produce new uncaptured requirements

<adamR> +1 to dlongley

Dave: concerned about being reduced to abandoning the flow completely if merchant requirements are not captured, as opposed to using some of the functionality

Ian: the api can always be used without data gathering, so base functionality won't go away

Adrian: *summarizing* where do we draw the line

<Zakim> dlongley, you wanted to say some things may changes other things likely will not

Dave: I think we have well-defined abstractions for payment/payment apps/etc
... we need to be careful how hard we try to capture the last 20% of user experience

<Ian> How? We get feedback! Including through discussions and experimental implementations

Adrian: agreed, start small and gather feedback

Jason: agree, clarifying on digital goods case, its a low-usage use case, shopify does not support this for their merchants
... its up to merchant to verify customer location, as an example of the edge-case-ness of some of these scenarios

Adrian: we need to make a good case for adding in new use cases to our considerations
... no resolution for issue 27, but proposal in the works by Zach and AdrianB

<dlongley> +1 to getting feedback ... we may find that providing low-level APIs/some components to capture this data in an iterative way may be a better design

AdrianB: the digital goods examples supports our idea, but not yet hearing a resounding case for the idea
... maybe just leave the proposal and wait for more feedback

<adrianba> +1

<jnormore> +1

<Ian> +1 to having nothing on billing address and changing if we get market feedback

<AdrianHB> PROPOSAL: no change to api for billing address until we get feedback

<dlongley> +1

<Ian> +1 to having nothing on billing address and changing if we get market feedback

<adamR> +1 — I agree, in paritcular, that we need good use cases, since they’ll impact the design

RESOLUTION: Postpone issue 27 with no change to the specification

issue 27 not closed, but de-prioritized

Issue 187

AdrianB: when a shipping address change event occurs you can tell the user agent that you plan to update the payment details
... the issue is about what happens when instead of resolving the promise to update payment details, the promise is rejected, what happens
... the spec says do nothing, the argument is that the spec should dictate the UI reverts to the previous state
... since the webpage is in control, it can decide how to handle the case
... I think doing nothing is good because it is less work and the problem does not seem obvious
... the user might not notice the failure occurred and UI state reverted, so there is no clear solution
... suggesting to wait for industry examples before we decide on best practice

Adrian: the other part of the comment is handling the case where the website rejects the user input, ex) unable to deliver to selected address

Adam: that's a good summary of my concern
... I want to give the webpage additional control to be able to revert the UI, ie, tell the api to notify the user of the failure

<Ian> adrianHB: I am hearing "notify the user" capability

AdrianB: should we be able to provide a message that gets displayed in the UX when the user picks an address the merchant cannot handle

<dlongley> if we don't want to pass text from the website to show to the user for some reason, another option is to define an error type like "ShippingAddressNotSupported" and the user agent can figure out what to say about that to the user

AdrianB: mixed feeling about such a message in the UX

Adrian: let's continue discussion of this topic on the issue list

<dlongley> notes that if we provided a component for collecting this info instead we could avoid the problem :)

Issue 16

<adamR> +1 to leaving as-is for now

<Ian> AdrianHB: Adrian Bateman made case for leaving as-is

AdrianB: spent some time attempting a PR, unable to find something that felt similar

<Ian> [Key concept is "lightweight object creation"]

AdrianB: nothing happens apart from argument validation

<Ian> [Real work happens when method is called later]

<Ian> adrianba: Also other specs taking this approach.

<Ian> adrianhb: +1

Dave: agree with adrian's argument, will we need a namespace?

<Ian> dlongley: +1 for as-is (with namespace comment)

<Ian> IJ: +1

RESOLUTION: Issue 16 closed with no change to the spec.

Adrian: closing issue 16

PR 179

<Ian> https://github.com/w3c/browser-payment-api/pull/179

AdrianB: wanted to make a way to pass in a single shipping option which is auto-selected as the default one
... the expectation is that the total price and other display items will include that shipping option
... the address may dictate shipping options
... default shipping option may be used when multiple similar options are available

Adrian: any comments about the PR? or ready to merge?

Adam: good feature to have, but want this to be non-conformant

<Ian> [prefer it be a hint]

AdrianB: not sure that can work
... merchant must assume its included in the final price
... if its a hint then you do not get the feedback to the app without firing an event

Adam: okay with firing an event
... I will propose language in the PR

<dlongley> was just going to say we probably just need to say the user agent can change the selection but they need to fire an event if they do or something to that effect.

Adrian: it could be that this is one of the big topics at the face-to-face, let's move to currency types and rendering

Issue 185 - Currency Types and Rendering

Adrian: we want to support ISO currencies because browsers know what to do to display them
... we also want to support unknown currencies for use cases like crypto currency, loyalty points, etc

<Ian> Here are three proposals captured by AdamR:

<Ian> https://github.com/w3c/browser-payment-api/issues/185#issuecomment-220043533

Adrian: complication in that we don't want ambiguity in the codes between the two types
... we have not elegantly solved this, Adam with a proposal...

Adam: suggest 1 of 2 proposals, using ISO codes or using URLs for adhoc currencies

<ShaneM> non-ISO through URLs. Resolve to a document with JSON that has properties that are interesting?

Adam: the other proposal is to use some well-known non-ISO currencies explicitly for common non-ISO currencies

Ian: user agent must interpret a string looking like an ISO code as an ISO code
... also in support of a small number of non-ISO codes, but we must be careful
... not thrilled with URL proposal, not sure we get far in specifying what happens we you access those URLs
... non-ISO may be getting ahead of ourselves, but if we do use URLs lets keep it as only an identifier

<Zakim> ShaneM, you wanted to say that tools always render stuff on the fly

Shane: tools on the web render on the fly all the time

Adam: what I'm proposing is as simple as "here is the name of this currency to render"

<Mike5> +1 to what Adam said about URLs not having meaning to users

Adam: we minimally need a way to say this URL links to the text to show the user

Adrian: I agree with Ian's points and Adam's points, dereferencing the URL feels high cost, but we have the need to fetch the display text, etc
... maybe add these directly to CurrencyAmount somewhere down the line

<Zakim> dlongley, you wanted to say you could put in a link

Dave: I don't think we need to define what happens withe these URLs in V1

<Ian> IJ: One way to get extensibility is to say that behavior for other values is undefined

Dave: but if we do, maybe it is linking to more info rather than rendering it

Adam: concern with allowing the merchant to supply string could be used for phishing

<ShaneM> +1 to that concern from adam

Dave: good concern, but not sure its mitigated by using URLs

Ian: there are unexplored issues here, one approach is to leave non-ISO currency behavior unspecified
... I'd rather do less for this edge case and allow for experimentation and then we will learn from it after

Adrian: we are out of time, let's take this to the issue this

<dlongley> leaving it undefined doesn't solve the squatting problem

Adrian: (list)

<ShaneM> ... uggh

Adrian: face-to-face 7-8 July in London