Web Payments Working Group Teleconference

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

Editor update

AdrianHB: Marcos Caceres will become an Editor of PR API (and associated)
... Marcos has contributed a lot via issues list; this will allow us faster progress. Thanks to Marcos!
... and thanks to the existing Editors for including him in the process.

(IJ: +1)

Payment Request API

<scribe> scribe: Ian

See pull request on detecting payment method availability: https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md

zkoch: We need one more change in the pull request, which I will explain
... we didn't have consensus from MS a couple of calls ago; we've now figured out what we want.
... we changed the name and the algorithm a bit
... last call we got consensus on the general direction
... but where I think we should get consensus is that for now there will be ambiguity about what this function means.
... there will be ambiguity
... for chrome, we see this as an active check => we want to return true if ready to make payment; edge not comfortable with "active"
... secondly there are concerns around fingerprinting.
... we think that it's "difficult enough" and not easy to do.
... every merchant we've spoken to (more than 50) has asked for this
... this API remains one of the compromises; note that the function returns a boolean, and we can modify the meaning of the function over time

<pascal_bazin> sorry

zkoch: I'd like wg to voice support for the function; we still need to update the pull request to reflect the fact of the ambiguity

<Zakim> manu, you wanted to discuss proposal from Dave Longley that addresses privacy concerns...

<manu> https://github.com/w3c/browser-payment-api/pull/316

manu: Dave Longley has a proposal

<manu> https://github.com/w3c/browser-payment-api/pull/316#issuecomment-265218908

manu: Dave asks whether we need the function at all.
... we could modify the call to show() so that the merchant provides a URL for their checkout flow
... so if the user does not have any payment instruments set up, they can always just click with "pay with *Pay" button
... this approach has fewer privacy downsides
... the merchant is not asking "can the API be used" but the question is whether "do I need to take them to my flow or will the browser handle it for me"

zkoch: I actually don't agree that that's what merchants want (from speaking with them).
... many merchants don't want to put people through flows unless they are confident that there is a payment method available ready to go
... I do think that the proposal would solve one problem but not the core problem.
... there is also a branding issue.
... some merchants will use a button that says something like "quick checkout"
... they only want to show that if they are confident that a user has something available
... see the list of problems/merchant requests in the explainer
... we had thought of one option where in the payment request API of declaring whether to include a "manual add" flow, but that wasn't fundamentally what merchants wanted.

<AdrianHB> Ian: q about the ambiguity

<manu> Ian: Is it possible to be more explicit in the call so that merchants know what they're going to get back.

<AdrianHB> ... is it possible to be more explicit in the API call so that merchants know what they're going to get back

<manu> Ian: Is there some way for merchants to have more certainty of what will happen independently of the implementation details. Can you get rid of the ambiguity by being more explicit?

AdrianHB: I don't think we are at a position to say "this is ready to go" but it's fair for zach to make this a last call for issue

zkoch: the last call was last week

(IJ agrees with zach)

zkoch: I am looking for consensus for the pull request as-is (in what it is proposing) but with some editorial changes (and addition of mention of ambiguity)

<Zakim> manu, you wanted to ask if anyone else has asked merchants about the flow if we have a "forward to checkout page" approach? Shopify? WorldPay?

Manu: To clarify the flow in Dave's proposal: you would see sheet and if user doesn't have the support the merchants want, there would be one button to take them to the merchant traditional checkout flow
... I'd like to hear from Worldpay or Shopify whether this would be interesting

MattS: one of my colleagues (Matt Devaney) has commented on the thread...Matt is talking about one of our particular flows.
... I don't disagree with Zach about some merchant requests
... but the particular PR request problems I have are (1) doesn't allow Dave longley flow and (2) 30-minute window challenge
... I think that Dave's proposal is viable, but not viable for all merchants

<zkoch> I don’t think the PR says anything about 30 min

adrianhb: I think that Dave's proposal could still be added in the future as a feature

<zkoch> +1, I agree this could be a feature

adrianhb: so that PR API provides a way to get to the page

<zkoch> “Checkout w/ traditional merchant flow"

AdrianHB: I think we could add this

alyver: I agree that Dave's proposal is a nice feature, especially where we don't have payment apps for lots of payment methods
... I think there's a need for the user to be able to exit gracefully to a legacy checkout flow
... I still agree with zach that there is a use case for knowing "user can make a payment right now" to place a quick checkout button on a product page
... I think Dave's proposal is a useful feature but that canMakePayment() is still needed

<manu> Ian: There may be some editorial changes, which is fine.

<manu> Ian: We may live with the ambiguity, but if we can do better and reduce ambiguity, we can do that.

AdrianHB: Is anyone opposed to the PR given that (1) there may be some editorial changes and (2) at worst it will be ambiguous (and documented as such) but if we can make it better we will
... I want to avoid browser sniffing

zkoch: I wish I had a clearer answer. Safari supports "active" with ApplePay. Chrome views this as "Active". I don't know about Firefox. Edge is not ready to treat it as "active"
... merchants are telling me they have to have it
... mainly because Apple has set precedent

<manu> Ian: To remove the ambiguity, all we have to do is tell the merchants what we know. One answer is "Yes, and I'm sure", or "No, and I'm sure", and the last one is "I don't know".

<manu> Ian: Then the merchant can decide what to do based on "I don't know"...

<AdrianHB> Assuming "i don't know" also means "I won't say"

<manu> Ian: There are ways where smart people can reduce ambiguity which seems to be the main solveable problem. The privacy issues are not solveable.

<manu> Ian: If we can get a provisional yes for the proposal if we can address ambiguity.

AdrianHB: +1 to Ian...I would prefer that we have definitive answers to the function
... browsers can return "I know yes/no" and Edge can still be compliant by saying "I don't know" (at least for now)
... as a merchant I know what to expect from the query
... and can make my own choice
... so to me that's more desirable

rouslan: +1 to "I don't know " option
... we have something similar when canMakePayment() when exists with quota exceeded error
... so we could so something similar when browser is not sure
... another thing that we can do is stay that a browser does not support this functionality because of platform restrictions can not expose that function on the request
... and so the web developer can check whether the feature is available and use only if available.

AdrianHB: Also a a fair proposal.

<zkoch> When is our next meeting?

<manu> Ian: Can we move forward by saying we can reduce ambiguity, there are two proposals on the table, let's get editors to update proposal to include that.

<manu> Ian: There is canMakePayment() and Dave Longley's proposal. Let's distinguish those.

<manu> Ian: There are remaining questions aroudn privacy, are we okay with those?

zkoch: I think the two proposals are Dave Longleys...we could thing of this as an independent proposal.
... having an escape hatch is a nice idea
... the other idea here is to remove ambiguity by introducing a new option (or rouslan's proposal).
... the "i'm unwilling to say" is a privacy escape hatch

AdrianHB: I like the idea that it aligns with "exceeded quota" approach

zkoch: That seems fine to me
... we have to figure out whether throwing is the right thing to do here
... I'll talk to DominicD
... so the general idea is yes/no/otherstate
... Here's my proposal:

1) WG meets next week

2) We agree that Dave Longley's proposal is worth its own pull request

<AdrianHB> +1 for a PR to explore Dave's idea

(the escape hatch to the traditional flow)

<adrianba> +1 - we've been exploring that idea too

zkoch: good idea to do separately
... let's look at that as a core feature to add...

Manu: I will let dave know

3) The editors will go back to look at reducing ambiguity

4) The other issue I'm hearing is from Matt Saxon which is about limitation...

scribe: note that you are not required to canMakePayment()

<adrianba> i don't think the "i don't know" will reduce ambiguity - i think it increases it

zkoch: We vote next Thursday

adrianba: I think we should accept the proposal
... that is CURRENTLY on the table
... we can add "I don't know" if there is consensus for that

PROPOSAL:

1) Accept the current PR (which implies editorial changes and ambiguity)

2) Editors will work to see if they get agreement on how to reduce ambiguity but the answer may be they can't

3) They will report back on their changes on the 15 dec call

<zkoch> Yes

rouslan: Regarding JS snippets, there were some issues cited by Matt. It's a viable proposal but it might not serve some interests.

MattS: Rouslan made the point I was going to make.
... we have many merchants. There are thousands of small merchants like this. The more difficult it is to integrate, the more risk it will not be adopted
... if we have to go out to 1000s of changes and require them to make page changes upstream

<Zakim> manu, you wanted to ask if WorldPay's problem would be address by Longley's proposal? If not, whitelist?

Manu: Are browsers open to whitelisting to allow some companies to call the API as many times as they want?

zkoch: We tend to frown upon whitelists in Chrome
... to understand that I know the use case - user is on 2 sites with hosted web pages...within 30 minutes they try to make a purchase on both sites

AdrianHB: Is there any wording in the proposal about "30 mins" or is it up to the browser?

zkoch: it's up to the browser; there are no hard requirements
... the general idea here is to start conservatively ... we have flexibility to adjust over time

AdrianHB: I think that discussion is (or should) be independent of adopting the proposal
... since there's no specific wording that is creating the concern that Worldpay expressed
... so we can continue to work on that

MattS: The longer the window, the easier for fraudsters. But the shorter the more difficult for payment providers
... I am ok to accept the PR but don't want to close the issue
... I think Dave Longley's proposal could solve, or white list could solve. I don't want to take a step backwards.
... this issue still needs to be resolved.

<adrianba> i think we should adopt the current proposal recognizing that we're converging but there is still discussion to be had

<AdrianHB> PROPOSAL:

<AdrianHB> 1) Accept the current PR (which implies editorial changes and ambiguity)

<AdrianHB> 2) Editors will work to see if they get agreement on how to reduce ambiguity but the answer may be they can't

<AdrianHB> 3) They will report back on their changes on the 15 dec call

<AdrianHB> 4) The specific mechanism for limiting access to the API is still up for discussion

<adrianba> and that we'll have concrete text to modify

<manu> +1

+1

<rouslan> +1

<AdrianHB> +1

<zkoch> +1

<alyver> +1

SO RESOLVED

<ShaneM> +1

<pascal_bazin> +1

<MattS> +1

Push payments

https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469

Pull request for transaction id => https://github.com/w3c/browser-payment-api/pull/292/files

<ShaneM> +1 to this PR

https://w3c.github.io/webpayments/proposals/method-practice/#network

<oyiptong_> +1 to transaction id

https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469

PROPOSED:

1) Adopt the paymentRequestID PR

olivier: I'd like to speak about this ID
... allows us to keep conversation with user in the face of exception
... doesn't matter if merchant-provided or user agent generated; it will help us maintain a streamlined experience (even after paymentRequest API)

IJ: Can we hear from AdrianB and Zach on the user-agent generated part of this?

AdrianBA: I don't object to adding this to the spec; may not appear in our first implementation

zkoch: I don't object to this; I suspect we'll get some interesting discussion about the shape of the ID...but ok to insert as is

<AdrianHB> +1

AdrianHB: Support for the proposal?

<ShaneM> +1

<rouslan> +0

+1

<adrianba> +0

<manu> +1

<oyiptong_> +1

<zkoch> +0

<zkoch> _0

0-- !

<manu> \)/

SO RESOLVED

next meeting

15 December

scribe: then 5 January

Telecofn proposal:

https://github.com/w3c/webpayments/wiki/Meeting-Proposal-20161128

Autopublishing:

https://lists.w3.org/Archives/Public/public-payments-wg/2016Dec/0011.html

FTF meeting

tentative: Chicago 23-24 March

week before the IETF meeting in Chicago

AdrianHB: Thanks all!