<scribe> Meeting: Web Payments WG
<scribe> scribe: Ian
<nicktr> https://github.com/w3c/webpayments/wiki/Agenda-20180628
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
(Marcos++)
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
Issue 27: Billing address collection (pending proposal from Marcos)
https://github.com/w3c/payment-request/issues/27
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.
https://github.com/w3c/payment-request/issues/705
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
https://github.com/w3c/payment-request/issues/727
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
https://github.com/w3c/webpayments/wiki/FTF-Oct2018
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
<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.
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
<AdrianHB> ** REGISTER FOR TPAC **