Web Payments Working Group

28 Jun 2018



stpeter, Ian, Rick, Simon, Ken, Manoj, Krystian, NickTR, marcosc, Jonathan, Roy, LauraT, mattdetert, vkuntz, adrianhb


<scribe> Meeting: Web Payments WG

<scribe> scribe: Ian

<nicktr> https://github.com/w3c/webpayments/wiki/Agenda-20180628

WPWG chair update

Nick: We have multiple work streams. PR API is the most advanced.
... we will cover some issues today and are mostly cranking the handle to get to Proposed Rec.
... wanted to check in with implementers and editors to see how it's going and where the group can help
... for payment handler, there is implementation by Samsung and Google in chrome...will be in Chrome 68
... but are seeking more implementation by other browser vendors
... regarding card payment related work tokenization, encryption, 3DS
... we have some draft specs now
... but that is wrapped up in the EMVCO SRC work
... my sense is that it will be hard to advance some of the work prior to SRC 1 being made public

Nick: so it feels like this work may slow down until then

stpeter: The tokenization and 3DS calls have been pretty productive and those have been making steady progress.
... Marcos has been cranking away at PR API...I think that we are making good progress especially on tokenization

marcosc: +1 to Peter. In addition, regarding implementation ... we are likely to continue to find small things to fix
... I am enthusiastic with our progress...it's really good to catch them now and fix them
... I am excited that we are getting a strong foundation on which to build payment handler


marcosc: Right now it's mostly me and Domenic doing tests and spec editing
... interns to keep things moving forward would be helpful
... I think we are going to hit some issues with our progression to Rec due to changes
... we are likely to need to do another CR phase
... so there will be some process, and then we'll need to get implementation of these changes

laura: Regarding SRC, I'd like to get a better understanding of Peter's comment regarding relation of SRC to Web Payments

stpeter: I have been reading public materials (but don't have internal access). This is my personal view based on my reading. Seems to me that we are all going in the same direction.
... I perceive it (from the outside) is that EMVCO can provide different sorts of incentives to merchants than W3C can (e.g., related to certification)
... I think that there are more incentives if both orgs work together and see this work as complementary
... I accept I may be off base, since just my own views

Laura: To share my perspective, from a merchant perspective, having the choice of going in the direction of SRC or in the direction of what W3C is trying to deliver on from a customer experience perspective, that choice is extremely important.
... and I see this as competition in some sense. I have expressed discomfort with direction of SRC. I think there is a competitive element, and some merchants may want a customer experience that is not based on SRC.
... I am happy to see progress in this forum because it offers merchants choice.

[See also Laura's presentation from this week to the WCIG: http://www.w3.org/2018/Talks/mag-wcig-20180625.pdf]

marcosc: I am still hopeful that we'll be done within 3 months with remaining CR issues
... right now there are 9 open CR issues
... for PR we may need to wait until mid-2019

<nicktr> Here's a list of all the open CR-exit issues currently open https://github.com/w3c/payment-request/labels/CR-Exit

IJ: With that length of delay we need to act. Either we remove features to finish V1 and move to V2. Or we get 2 implementations and get buy-in from all the browser implementers sooner.
... When is the next editors call?

Marcos: We are not meeting regularly.

<scribe> ACTION: NickTR to convene a browser vendor meeting to discuss implementation time scales and whether we need to cut back features to get out V1

<trackbot> Created ACTION-100 - Convene a browser vendor meeting to discuss implementation time scales and whether we need to cut back features to get out v1 [on Nick Telford-Reed - due 2018-07-05].

NickTR: This is a good conversation to be having now.
... thanks for raising this, Marcos

<Zakim> AdrianHB, you wanted to ask Laura if she thinks merchants will be faced with a choice between SRC and Web Payments?

AdrianHB: Question for Laura - I am wondering whether Laura is suggesting or whether there is a general feeling that merchants will be faced with a choice between SRC and Web Payments, implying some incompatibility.

Laura: The way we have been communicated with on this is that there will be participation in one or more programs.
... a merchant may have a proprietary program (e.g., Amazon Pay)
... merchants will have various choices
... there could be more options still (e.g., faster payments)
... W3C is focused on the transmission of data [And user experience]
... I think there will be other options for merchants
... I think merchants will want to preserve choice on their site
... depending on how the consumer wants to pay

AdrianHB: My concern is incompatibility; but perhaps we don't know enough yet.

Laura: Agree it is too early to tell; I certainly hope there isn't

NickTR: We can work on flows and data models for compatibility, giving merchants choice about where to participate.

<AdrianHB> +1 - I hope no programs are designed that make it hard to use Web Payments as part of the program

IJ: I have been encouraged by EMVCO participation in our task forces; hoping we can achieve interop this way

stpeter: I want to reinforce that; I've been impressed in discussions about tokenization and customer authentication. It's clear on those calls that the people who are heavily involved in EMVCO are dedicated to interop..that has increased my confidence that we'll see the same thing happen with the rest of the user-facing stack

PR API issues

Issue 27: Billing address collection (pending proposal from Marcos)


NickTR: Any progress from Marcos on spec text?

marcosc: There seems to be consensus but no spec text yet; I was unable to complete that action yesterday
... at a high level I am hearing that we should bring billing address into PR API
... and we reuse the same privacy model we are using on shipping address (redacting some information during tax computation)

Issue 705: Retry. Feedback so far is a preference for a single event.


marcosc: This is a fairly significant change to keep the sheet open upon error and allow the merchant to signal what needs fixing in the sheet.
... if all goes well, we might be done with retry() in the next day or so

IJ: Implementation status?

marcosc: I have a prototype implementation .... not yet in other code bases

Issue 727 Signaling payment handler details errors


marcosc: This is for errors to the user

IJ: why is this separate from retry()?

marcosc: This is part of retry(), just specified independently

NickTR: Is this error stuff to be defined in payment method specs?

Marcosc: Not necessarkly
... I don't think we are yet at a point where we can have generic errors for payment handlers

<marcosc> https://github.com/w3c/payment-request/issues/727#issuecomment-400463717

<marcosc> ^^^^

stpeter: Is this really limited to basic card?

IJ: I am understanding this to be "There's an error here, show this error message associate with this field"

Marcosc: Yes

<marcosc> stpeter, see: https://w3c.github.io/payment-request/#addresserrorfields-dictionary

TPAC 2018


NickTR: Excited to invite Berlin Group to the meeting

(Please register! https://www.w3.org/2002/09/wbs/35125/TPAC2018/)

vkuntz: Berlin Group working on 3 specs to implement PSD2 in Europe
... also STET and Open Banking UK
... we are working with them all to produce a single ISO 2022 compatible API

Kris Ketels slides on PayLater (from Monday)

<nicktr> ian: do we need a "pay later" payment method? What would the considerations be?

<nicktr> ...if that's the case, could we see a demo at TPAC?

<nicktr> vkuntz: tbc

Visual identity

<nicktr> ian: at last TPAC, we reviewed visual identity for web payments as a generic mark so users might know what to expect

<nicktr> ...the response was lukewarm

<nicktr> ...at Singapore, there was strong consensus that this would help consumer adoption

<nicktr> ...There may not be some resource available via Facebook - thanks to Roy

<nicktr> ...Google have also suggested this needs looking at

<nicktr> ...We will raise an Issue

Roy: I think it's likely we'll get resources; will keep you posted.

Next meeting

Proposed 19 JULY

NickTR: Perhaps by then we will have input from browser vendors re: CR

IJ: I will send a 1-off for 19 July. Then would we meet 26 July to get back on target?

NickTR: Let's say yes.

<AdrianHB> I am now at Coil, who are now W3C members


Summary of Action Items

[NEW] ACTION: NickTR to convene a browser vendor meeting to discuss implementation time scales and whether we need to cut back features to get out V1

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/06/28 15:35:38 $