Web Payments Working Group Teleconference

Priorities

AdrianHB: There has been quite a bit of discussion on the list, lots of discussion to try and get ourselves aligned a bit in terms of priorities.
... We have a bunch of influencing factors on priority - lengthy discussion w/ chairs and staff and our proposal is to focus as described in the agenda.
... we're very concious that there is a strong demand from the group wrt. extensibility of the ecosystem - the ability to have independent 3rd party payment apps as a part of the ecosystem.
... How would that work in terms of UA interfacing w/ payment apps. That's from a browser perspective, but there is non-browser perspectives as well.
... With the browser specs doing experimental implementations, we are going to prioritize this over next few weeks. Provide guidance on that, we expect that to become priority.
... Next is moving browser API forward

<ShaneM> I am concerned that we end up with deployment that we feel we can't change as our work matures.

<zkoch> Just a quick clarification: The PRs are from us as individual participants, not in our capacity as editors

AdrianHB: The vendors would like to start implement this API - how many parameters, where do parameters fit, how do specific things work - we'll try to address some of those things today. Issues on the list - address those issues diretly.
... We're going to try to move that stuff to the mailing list as possible.
... There is a proposal from the Web Payments CG around Core Messaging and HTTP API - there is also payment methods - while we would like those things to happen in parallel, the next few weeks will drive what we spend time on.
... Focus very much on issue resolution

Nick: I don't have much to add. Adrian and I are trying hard to balance priorities of the group - appreciate everyone's contributions on helping stay focused - arch and extensibility, moving browser specs moving forward, open and excited on other proposals but would like to focus call time over next few weeks on 3 priorities.

AdrianHB: Various hats that people working in the group - contributors/editors/chairs - I'm certainly going to continue to contribute as a contributor - as a developer I'm intending to contribute. It should be accepted that contributions to PRs and issues are, unless stated otherwise, contributions from members of the group.

Nick: I'm fine w/ that position.

Face-to-face Meeting Update

Nick: Unfortunately dates conflict w/ Blockchain... we've put other dates up

Wednesday 13th July and Thursday 14th July

Monday 18th July and Tuesday 19th July

Tuesday 19th July and Wednesday 20th July

<nick_tr> https://www.w3.org/2002/09/wbs/83744/F2F_London/

Nick: Please do fill in the questionnaire - we'll try to fill in the dates that are most helpful - want to see if people would like WPIG / ILP meeting at same time - any questions/comments on that?

ChristopherA: The IETF thing starts on the 17th, SUnday - if there was something that was 14th and 15th I'd go to London and fly out to berlin.

Nick: Logistically, I can't host on the 15ht, but Wed/Thu works.

AdrianHB: The IG would like to co-host if they can - we might be able to do IG - venues for that are different - Nick can only do Wed/Thu.

dezell: Yes, we're actively thinking about having the face-to-face WPIG meeting w/ you around there -

Nick: I can't host Friday,

AdrianHB: We might be able to host

Brian: I might be able to host on Friday.

dezell: Yes we care and yes we're thinking about a WPIG meeting.

Nick: The questionnaire is open, we'll give you an update at the next meeting.

Proposals

Nick: Doubt we'll get through all of this today, but let's get started.

Subtopic: paymentrequest.complete()

AdrianHB: The intent was to pass information via complete - originally we asked about passing something to payment app - drop parameter all together?
... Push back on that to change parameter form boolean to enum - AdrianB updated - happy to drop my proposal w/ Adrian's counter-proposal.

<adrianba> https://github.com/w3c/browser-payment-api/pull/161

adrianba: A little bit more discussion in https://github.com/w3c/browser-payment-api/pull/161 today
... I'm open to a question about whether we want to talk about those proposals today or accept this PR or think about those more.

<zkoch> I think there is another proposal to do complete({status: “success”});

<zkoch> +1 to accepting this as is, and then refining later with enums if we want

AdrianHB: We could accept PR as it is to accept new messaging as it is - additional PR to accept a newer proposal.

adrianba: happy to accept as-is and then refine it.

manu: Happy to accept as is and then do different PR.

dlongley: Yes, fine w/ that.

AdrianHB: proposal to accept PR 161 as is.

<zkoch> +1

<AdrianHB> +1

Nick: Any objections?

+1 to accept PR161` as=is

<adrianba> \o/

<dlongley> +1

RESOLUTION: Adopt PR #161 as is.

AdrianHB: I put forward PR 133 that has a bunch of stuff in it - trying to do too much in a single PR - as a relative newbie to this process - there is a proposal to address total amount / merging of parameters - PR #158 is a counter-proposal to part of that.

<adrianba> https://github.com/w3c/browser-payment-api/pull/158

AdrianHB: In the current spec, we give special meaning to items in the final position in list. The total should stand on its own.
... AdrianHB uses a PaymentItem object, whereas I used an array of currency items. I was trying to support multiple currency amounts. AdrianB's moved total out of items array, but keeps it on same object. In my proposal, I've moved it onto separate parameter - probably a good contrast of two proposals.

adrianba: I was trying to have discussion of multiple currency amounts and price and discuss those separately

AdrianHB: I'm happy to do that, if we address these things incrementally, we'll make more progress.

adrianba: Manu asked the question about why "label"

AdrianHB: It does make sense to have some kind of label that we can have there. Rather than comparing the two, let's consider adrianba's and like that approach.
... There seem to be general consensus around it.

Manu: What happens if a UA doesn't display?

<Zakim> manu, you wanted to ask if that is a MUST be displayed... hard to do that.

<dlongley> maybe if the UA is going to display the list of items, they have to use all the labels

adrianba: Right now, it's a MAY show it.

Manu: My concern is that developers may be surprised if it's not displayed.

<dlongley> (or ... the UA may not pick and choose which labels to show)

Roy: Just wanted to say that I'm in favor of the PR - we may want to push other things like taxes.

AdrianHB: The proposal separates the total from display items.
... The UA may display that stuff - there is no MUST there - taxes, discounts, whatever other line items the merchant considers important.

<ShaneM> Since we don't have UI in our scope, MAY is appropriate here

AdrianHB: Are you saying we should have specific tax amount in there...

Roy: It's interesting that you say that display items don't have to be displayed.
... Going simply off of a string-based title on the items is error prone.

adamR: I don't want to go too far afield - do you mean that we have some messages that are going to impact the payment request? Or is this just for display purposes right now?

AdrianHB: Purely for display right now.
... Display items are for the UA to use in displaying the UA - pass request onto payment app.

Roy: I think it's important to call out to the user what's going on - you need display items for that purpose - but there are other item types, inclusive vs. exclusive taxes - important line items, but affect total in different ways - we may want to call other items out.

AdrianHB: We need to clarify that and submit a new PR to add additional items outside displayItems list. Right now what we have is a step in right direction.

Nick: That sounds like consensus

AdrianHB: Any objections to that PR?

<ShaneM> I think it could be interesting to extend displayItems with an optional 'type' parameter and a dictionary of semantically meaningful types (to address Roy's concern)

<zkoch> +1

<nick_tr> +1

PROPOSAL: Adopt PR158 as is.

<AdrianHB> +1

+1

<dlongley> +1

<zkoch> :)

<rouslan> +1

<Roy> +1

<ShaneM> +ian

RESOLUTION: Adopt PR #158 as is.

<dezell> +1

<zkoch> @adamR: Yep

Subtopic: Separation of payment parameters - PR #162

AdrianHB: Merge list of payment methods with payment method data - major difference is total is still details object - total and items list in details and then supported methods parameter and custom data for those - 2nd parameter which contains total and list of items - 3rd parameter that has options like "requestShipping"
... The difference is that middle parameter - total w/ supported method stuff - display items w/ options - biggest difference between the two.
... Since adrianba's is a step toward that - may submit another PR to get rid of details object and debate that separately - gist is to address a request w/ the TAG review and then issue raised before proposal was brought into WG - whether PMI should be passed as array of identifiers - or more complex objects.
... Looking at the thread, most people are agreed that this will work and it's a step in the right direction - any objections?

adrianba: One quick comment - role of this change was to remove antipattern of having two optional arguments .

PROPOSAL: Adopt PR #162 as is.

<AdrianHB> +1

+1

<dlongley> +1

<zkoch> +1

<nick_tr> +1

RESOLUTION: Adopt PR #162 as is.

<dezell> +1

<zkoch> oop, q-

Subtopic: Change the way we request user data - PR #65

AdrianHB: This one is contentious... it has to do w/ how we pull in user data.
... There have been multiple counter proposals - AdrianB - you had an argument against getting too generic. Can you explain why this is a bad idea?

<Zakim> zkoch, you wanted to say modifications are coming

zkoch: I don't think there is consensus around that PR - some good feedback - trying to make modification to it - probably not quite ready yet to be merged in yet. So, hoping we could punt it to the next call.

manu: Agree to punt to next call - no clear consensus yet.

AdrianHB: Let's talk about this PR, though.

adrianba: Agree w/ Zach - was going to work w/ Zach on working on this PR - didn't anticipate that we'd make fast progress on previous 3 issues.
... Counter proposal is to add request to options dictionary, specifically for email and phone number, but I don't like Zach's original proposal because it assumes that these are always boolean requests, merges them into a list.
... I think we should esign the API so we could protentially have things be required or optional
... we've had discussions - feasible around UI - is it something we need now? plan was to propose that we keep it simple to begin with - we have booleans in the same way we have requestShipping, requestEmail, requestPhone and show how that could be etensible and decide if we want to add required vs. optional.

AdrianHB: I get the sense that folks haven't followed this thread closely. From my perspective, what we have is effectively this spectrum of flexibility on one side where websites can ask UA to gather anything for them, what is gathered through UA - what it is they can ask for it.
... The other end of the spectrum is something fairly rigid.
... I'd prefer something flexible

<Zakim> manu, you wanted to ask that we design something generic/extensible - because that's where we're going.

<dlongley> manu: My concern is that we shoot for something fairly narrow and rigid and over time we're going to keep expanding the types of information that orgs will want from the UA and we'll end up in a position where this is a general customer data collection API.

<dlongley> manu: My preference is that we make it generic and generalized which is what AdrianHB is proposing because we'll end up in a situation where we have 10-15 things that we support over the last 5 years. To be clear, I wish this wasn't happening in the payment API and instead in another one, but I think we're setting ourselves up to collect email and coupon, and so on and so forth.

zkoch: I don't like generic - I think that part of what we're doing here is an opinionated streamlined flow. I don't think we're trying to recreate the entire buy form experience.
... We can only accommodate a certain set of use cases - if we have 15 different things you can request - we need to stop and reflect. The bar is limited to information you absolutely have to have for checkout flow... email and phone may be the bar.

<nick_tr> q

zkoch: We want to avoid massive expansion.

AdrianHB: If there are no other comments, we can move onto other issues.

<zkoch> We already have generic, it’s called a <form> :)

AdrianHB: If you want to submit an alternative proposal - please do.
... We need to understand why not to do generic. We went through this on shipping address - made checkout experience better, if anything else makes checkout experience more efficient, we need to consider it. We need to think about privacy - how easy is it to farm user data?
... What about other countries required stuff - like country-specific shipping information?
... Maybe we should dive into one or two of the other issues that impact the shape of the API - stimulate proposals to come forward.

Other issues

AdrianHB: There are four other issues that we may want to talk about - happy to do them in that order or one in particular that anyone wants to discuss.

<Zakim> manu, you wanted to ask about how this will be deployed and how that affects how much handwringing may be done.

<dlongley> manu: There's been talking about this API and implementing it in the browser, is the expectation that when this gets published (soon), will it be behind a flag?

<dlongley> manu: If collecting this information is behind a flag at first as an experiment, then I think people in the WG are much more likely to get behind it. Because if tons of people start using it then we have to keep it around.

<ShaneM> +1 to a general concern about exposing experimental features to the public

<dlongley> manu: Do you guys know how you'll do this first round of implementation, will it be behind a flag?

zkoch: We have two conflicting ideology - we want to get features out to get feedback, but we don't want to launch something that's unfinished. We have a couple of different things that we're looking to do.

<dlongley> +1 to behind a flag

zkoch: You will probably see this behind a flag at first - problem with that is that it's difficult for a developer to use - what's the impact of this on conversion - so all users should enable flag. So another thing we're looking at as well that should solve this problem - how we can solve this problem from a Chrome perspective - origin trials - send out more details - way to launch experimental features, but expire them w/ use of tokens - there is a way for us

to turn this stuff off

zkoch: If we had an experimental thing, we can always put stuff behind another flag. Don't want to lock ourselves into an API that we're unhappy with, we will work hard to avoid that.

adrianba: To echo what Zach said, we will implement this first behind a flag for the payments api - in Edge - not ready for people to experiment w/ people outside our team now. With every new feature, we have to figure out balance between stability of parts of spec and whether it's ready for people to use / experiment with - we'll definitely start behind a flag.

<zkoch> I have to run to make another meeting, but happy to chat on this topic further if there are more questions

<zkoch> Thanks, all!

adrianba: One of the things we're going to look at wrt. changes in the API - if there is something where we see a potential change or something that we might implement incrementally, if you have this whole capability - lots of different aspects to it, we may only have resources to implement one of those things... how could web developer check to see if one capability exists, but others don't.
... That's a core part of our philosophy for all APIs, want to focus on that - we don't want to lock the group to feel something is being decided w/o them.
... or break core API spec.

adamR: I don't have a position from a Mozilla perspective yet.

AdrianHB: I think that's a good perspective - I think that answered Manu's question.

<dlongley> manu: Yes, thanks

Next Week

Nick: I think we made good progress this week on browser API - would like to focus on extensibility next week - please read proposals.

<nicktr> https://github.com/w3c/webpayments/tree/gh-pages/proposals

AdrianHB: The key ones we will focus on next week are Core Messages, HTTP API, and Payment Apps.
... It may be just parts of it that we propose are browser-specific as opposed to generic payment apps thing - don't only read them, but comment on them - if you don't like them, submit a counter-proposal.
... I would love to see counter-proposals w/ differnt approaches to what's been put forward to date - There are 4 issues that are left not specific to particular PRs. Those issues impact the shape of the API some more than others.
... At least 3 of them were picked up during the TAG review - look at them, propose solutions to them, and close them out as soon as possible.
... we dont' want shape of API to change down the line. If impleemnters are happy and this is feasible, the sooner we get ther the beter.
... If people aren't happy w/ priority or labels - change them yourself or let me know.

<nicktr> please look at issues #2, #16, #19, 119

AdrianHB: Let me know what you think the priorities should be.
... I used a milestone for this week and will create milestones for next weeks calls. I would like if we have proposals to address these issues or any that affect the API.

Nick: Read those proposals before next week or comment on them. The more comments there are, the easier the discussion goes. I hope that by picking up some of the other proposals next week, we'll make the group more broadly inclusive.
... Speak with everyone next week.