See also: IRC log
<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
<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
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 :)
<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
<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
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