Web Payments Working Group Teleconference

<scribe> scribe: Ian

Introductions

[Laura Townsend, MAG]

Laura: Seeking to identify a more tech person to participate

[Christian Weiss, Stripe]

Christian: Happy to join you

[Manash Bhattacharjee, Mastercard]

Manash: We just joined W3C, are in the process of joining the WG

IJ: MC joined W3C this week

[Michel Weksler (AirBNB)]

Payment Request API

https://github.com/w3c/webpayments/wiki/Agenda-20170302

IJ: Where are editors currently on billing address?

zkoch: Background is that in some locales the VAT needs to be calculated based on billing address or where you live
... right now there's no way to get that via the API
... for a digital good
... without support, we eliminate some use cases
... at this point if we can figure out this PR and issues with it, I'm ok to make this one of the last feature changes (before CR)
... but as the PR stands now, the larger challenge (beyond the name) is the behavior
... in case of billing address, there is no shipping options
... if you pass back "empty" it indicates a problem.
... we have to do the work to figure out how to treat this
... this also extends to another issue: "store pickup"

<nicktr> issue: https://github.com/w3c/browser-payment-api/pull/409

<trackbot> Created ISSUE-1 - Https://github.com/w3c/browser-payment-api/pull/409. Please complete additional details at <http://www.w3.org/Payments/WG/track/issues/1/edit>.

IJ: Should we talk about store pickup here as well?

zkoch: no; we can handle separately

IJ: What question would you ask the group?

zkoch: Do we think this use case is important enough to worry about? Our previous decision (about 1 year ago) was that it was not
... but what's changed in the past year is that we didn't have shipping type affordance
... we could do this if we think it's a priority...
... so how important is this?

nicktr: Any opinions on this?

adamR: The only thing that comes to mind here is if we separate shipping from billing address..it would be nice to have the question resolved before finalizing basic card spec

zkoch: not sure that's entirely the case...I don't think "billing address" is accurate. I think "VAT" is better
... and different countries have different requirements about which address to use
... so they are not always synonymous

AdamR: Let's avoid a 100% overlap with what basic card asks for ... if so, that's fine

zkoch: You may also use a friend's credit card...so I think lots of cases where the addresses are disjoint

Stan: Looking at the pull request - does this mean if you ask for billing you can't get shipping?

zkoch: VAT calculation is only an issue for digital goods (where you don't get a shipping address)
... if you use basic card you'll get back address with basic card...but if you don't use basic card, there's no guarantee you'll get back an address.

stan: To give some context about how Stripe handles this - we did split the two and we recognize them as separate...billing address available for any payment address...it has served us well
... I am concerned about conflation of shipping address for this purpose in some cases

zkoch: The way I look at this - the user agent presumably has a set of addresses for a user
... what we are talking about here is (1) in the UI explain to a user what set of information is being requested (e.g., pickup address, delivery address, etc.)
... and one of these things might be a VAT computation address (UA's will find the right string to educate users)
... and (2) a set of addresses that show up for users
... it could easily be that the VAT address you select is different from your credit card billing address

stan: The canonical user experience we think about here is what you see on Amazon
... Amazon did a fine job of understanding your previous billing and shipping addresses
... I think the PR pushes user agents to conflate all addresses...I think that will lead to confusion
... I think we need to have a clearer definition of billing address

zkoch: I think you raised a few issues...e.g., sharing billing addresses with payment apps may be problematic
... but our general stance here is that a lot of things you are mentioning are important, but they are user experience issues that will be handled by UAs
... so while I agree, not sure we should specify the behavior

stan: As a developer experience, I've been PR API, I had a hard time to understand the PR.....I think it could be cleared up to be about VAT

<Zakim> nicktr, you wanted to ask if the payment app can supply any addresses

nicktr: Stan, would appreciate your input on GitHub list as well
... Can payment app provide the billing address?

zkoch: First answer is that for any payment app that is returning a basic card, you are expecting to pass back the associated billing address
... the second answer is that apps can pass back whatever they think makes sense for their payment app based on payment method
... but there is no mechanism for the payment app systematically to integrate addresses given event model

nicktr: What if payment app returns different address than what the UA knows about?

zkoch: You mean in general or in light of VAT computation?
... billing address does not have to be same as VAT computation address
... e.g., in EU, for digital goods, the VAT computation is based on your home address, which may not be the address on the card

AdamR: If a payment method is returning the information, you can't have payment method specific prices
... or for the VAT to vary based on payment methlood

nicktr: So it has to be the mediator

AlanMarshall: Great discussion. Could you restate the core question
... is it strictly around the address being used for the VAT? What's the issue that needs to be addressed?

zkoch: The problem statement is that for taxation you need to know VAT address for the user
... today in PR API there is no way to get an address from user to let you do this
... so the user experience problem is that you can't show accurate total price
... so there is a proposal for a new type (e.g., "VAT" or "billing address") that would allow the user to see in the user interface a place to see an address
... there would be no shipping options, it would just be a way to send information to the merchant, and update the price
... question is - should we accommodate in the spec for V1

PROPOSED: Support VAT info collection in V1 of the spec

<rouslan> +0

<oyiptong> +1

<spolu> +1 (AdamR distinction that these are the address that influence total amount is :100:)

<AlanMarshall> +1

<mweksler> +1

<adamR> +1 (but only if we can make it clear that it’s something other than shipping address)

<cweiss> +1

Alan: I think this is important for the Korean market

zkoch: Hearing general support, I think the question we need to look at is how complex will this be.
... it might also be some time until this is broadly support across user agents
... I will follow up with Roy

RESOLUTION: There is support for VAT info collection in V1

Payment option filtering

nicktr: We had good discussion last week...want to check with implementers

https://github.com/w3c/browser-payment-api/pull/420

https://github.com/w3c/browser-payment-api/pull/420

[IJ Summarizes the filter topic]

Laura: quick question - what you are talking about, from a merchant perspective

nicktr: We are focused on card payments - basic card is the payment method; the filter is about conditions under which you accept basic card

Laura: does this also mean filtering on payment apps?

nick: No. Which app is present is determined by the browser, looking at payment methods and filters and user's payment apps

IJ: Implementers?

Rouslan: The essence of the proposal is to do string set matching
... the browser compares string sets provided by merchant and payment app
... the major point of contention between firefox and chrome is how we should specify the filters
... an important point for Google is backward compatibiliyt
... don't want to change the shape of the API, only the behavior of the API
... Mozilla is proposing to name filters explicitly (change shape of API)
... Google is preferring to treat string sets as filters (but not requiring those filters to be explicitly named)
... so the practical implication of we move to mozilla's proposal is that data would be moved to a new explicit field
... Google could deprecate the old way of doing this over several months
... Edge plans to support basic card...wanted to hear from MS about renaming filters => "filters"

zkoch: I want to make it clear that the functionality exists for basic card

IJ: The heart of the question is whether to use this for other payment methods

adamR: To expand on Rouslan's comments. This is not a renaming of "data" to "filters"
... there is still payment-specific data
... the second part is that is a way to do this with backwards compatibility by allowing the specific
... fields in basic card to appear in either place for a transitional period...this is not a breaking change
... this is an evolution of the API

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

https://w3c.github.io/webpayments/proposals/tokenized_cards.html

https://www.w3.org/Payments/card-network-ids

IJ: So there are three payment method specs that want filtering AND regulatory issue of limiting string sets (cf https://www.w3.org/Payments/card-network-ids)

adamR: We are likely to also going to want to say something similar for future payment methods (e.g., cryptocurrencies where you accept different types)

zkoch: the last time the conversation came up we said that we thought this would only be relevant for WG specs...
... I get why this is useful for tokenization
... I also spec that you'll define that in the tokenization spec
... I still don't see us in chrome doing generic string matching and hoping for the best on the UI

nicktr: To clarify my comment - i was concerned there would be a competition issue... I want there to be a level playing field on filtering

AdamR: Can you say what you mean by user epxerience? This is just a rendez-vous function
... the purpose of this is to allow the browser to determine which apps to display to the user

IJ: My proposal is to say "let's use the same simple filtering language in those supported payment methods"
... The rules for filtering are known in advance. The string values are not

AdamR: This is fundamentally a different view on how much work browsers should do to accommodate new payment methods
... if you allow the specific to have a setup whereby browsers can simply adopt new methods without adding new code, browsers can still have their own whitelists to allow the ones they trust to work.
... if you do the other way around, everyone always has to write new code to support a new payment method
... for browsers that only come out every 18months, this is problematic
... I would prefer to not require new code for each new payment method

<AlanMarshall> Is this Issue #96 ?

Molly: I will check in and come back next week or by email

FTF agenda

<nicktr> Face-to-face meeting agenda, updated

(Ian thinks this is near final)

Next meeting

* More on filtering

* More on line items privacy

<zkoch> thanks!

<nicktr> thanks everyone

nickTR: Thanks again to new people; I or Ian happy to chat before FTF