Web Payments Working Group

27 Jun 2019



Ian Jacobs (W3C), Nick Telford-Reed, Dean Ezra (Barclays), Laura Townsend (MAG), Rouslan Solomakhin (Google), Luis Guzman (NACHA), Danyao Wang (Google), David Benoit (Reach), Lawrence Cheng (Barclays), Alex Liu (Airbnb), Frank Hoffmann (Klarna), Roy McElmurry (Facebook), Tony England (Bank of America), Vincent Kuntz (ISO20022 RA), Jeffrey Williams (The Clearing House)
Florent Lambert (Lyra Network), Adrian Hope-Bailie (Coil)


PR API 1.0

NickTR: Welcome! Beautiful day here in Cambridge (UK)
... Ian and I were just chatting about the implementation report and getting the last tests over the line. See the Less-than-2 view.

IJ: Danyao want to characterize where we are?

Danyao: If you look at the implementation report "less than 2" the dash means obsolete test.
... so we are currently focused on red "fail" in Chrome or Safari.
... on the chrome side we have two outstanding issues
... one relates to PR API in iframe
... chrome fail today has to do with being able to change attribute once frame created
... so there's a timing issue we need to fix
... meanwhile Safari does not allow pr api in an iframe
... so if you want to see this, you should let Apple know, otherwise you won't be able to make an Apple Pay request from within an iframe
... there's a second test regarding "reject if not active"
... if a payment request is created in a document and the document becomes inactive (e.g., user navigates away from it)...then in chrome promise goes into limbo mode
... webkit has a different behavior
... and the spec may need to be updated ... but also a broader web question regarding promise management
... I am interested in how frequently this is encountered in the iframe case
... so this may relate more to the HTML spec
... from safari perspective, I think the only outstanding issue is whether one can do a payment request from a popup window.
... I think there's some ambiguity in the spec
... what happens if PR API called multiple times from different windows?
... we made a spec change in nov 2018...to allow multiple PR API calls...but implementations(e.g., Apple Pay) may not allow this for payment handler reasons
... our test does not yet align with the spec update
... we are still discussing how to fix the spec and update the test

<nicktr> ij: thanks to danyao - you are clearly on top of this

<nicktr> ...also it's great to get a window onto the implementers level of detail

<nicktr> ij: this also suggests that we have a couple of months left to run (this is my guess)

<nicktr> ...which means we should be at PR for our F2F

<nicktr> scribenick: nicktr

<Ian> See the comments from Michel Weksler (Airbnb) from May, asking some questions:

ij: 1) can we use data to create an account? We now have a pull request (869) to add a privacy note regarding data usage.
... 2) we'd like to get paid through more payment methods
... 3) we'd like Apple to support more payment handlers than ApplePay
... I think the last two points sum up the challenge we have in getting more merchants
... my question to the group is are there other things we can do to get momentum
... two recent ideas from W3C staff discussion:
... a) conduct a study (Payment request versus traditional checkouts) - do we deliver a better UX or faster or better conversion?
... b) run a hackathon/plugfest
... would welcome the thoughts of the group

<Ian> scribenick: Ian

nicktr: I would echo this..what can we do to build momentum around adoption?
... face-to-face agenda discussion would be good

Laura: If we did a 2-day workshop, what would be the desired timing? Who would be important players?
... I might have some ideas

<nicktr> ij: i think earliest would be 6 months time - so December or Jan

<nicktr> ...it would be great to have some merchants who are members to represent

<nicktr> ...also payment providers, banks, schemes - the whole gang!

<nicktr> ...what is (in practice) making this hard?

<nicktr> ...e.g. access to a particular payment method

Laura: Q4 from a merchant POV is always terrible, so prefer early 2020
... MAG are launching a tech forum in the fall
... aligned with our core MAG conference and approach to addressing member issues in payments
... dedicated primarily to talking to the audience of tech leaders within merchant orgs that deal with payments
... we are going to have a tech forum day session aligned with our conf going forward
... so in February we'll have another tech forum aligned with our conf
... so we could leverage the presence of tech leaders
... we could co-locate the workshop

Laura: The event in Feb 2020 would be in Atlanta

ACTION: Ian to follow up with Laura about the idea of a web payments hackathon/workshop in early 2020 co-located with MAG

Laura: I like the idea also of doing research

[Research interest?]

<nicktr> +1

<alex_liu> +1

<rouslan> +1 - a useful exercise

NickTR: We are interested in hearing from people who have spoken with merchants about implementing PR API....did they express any concerns?

alex_liu: We chatted with our Google colleagues this week about some of the use cases...really helpful conversation
... I am happy to share some of my notes

Danyao: That would be great, Alex.

Ian: Want to do a blog post?

<scribe> ACTION: alex_liu to compile notes into a potential blog post (or other venue)

FTF agenda

NickTR: As we close PR API 1.0, I think that we will likely turn more focus to deployment as we wrap up v 1
... My own personal experience when talking with merchants and developers, is that they are excited about payment handlers but need to get more browser interop. Reminder to register for 16-17 FTF meeting. Some resources:

NickTR: To start the meeting in Japan I look forward to starting with a retrospective ... where we are and how we got here
... SRC 1.0 now public, so we'll look more at that for sure at the FTF meeting
... payment handler progress....
... web monetization push

<nicktr> ij: coil will be talking to the assembled TPAC on the Wednesday about web monetisation

<nicktr> ...Stefan Thomas (the CTO) will be there

NickTR: For PSD2, implementation date for SCA falls on 14 September
... by then there should be some extensive experience around the table around challenges and opportunities
... this is an invitation to people who are coming to the meeting if you want to lead discussion on that. ... would be great to hear from you
... we saw new guidance from the EBA last week (some clarifications, some grenades)
... At TPAC we are likely to see some demos as well
... Lastly, if we could get someone from payments market in Japan or Asia that would be interesting
... welcome volunteers

vkuntz_: I can confirm already that SWIFT Japan colleague will join me

IJ: We welcome concrete contacts for people in Japan/Asia to invite to the meeting to share perspectives.

NickTR: if you have other topics you want to cover, please let us know

Risk assessment, privacy, and identity requirements

ij: The Web Payment Security Interest Group will have a discussion in August about risk assessment and privacy. The interest group also plans to meet Thursday and Friday of TPAC. I wanted to mention the discussion about risk assessment and privacy here to spark interest. Some specifics would be around browser/device fingerprinting, for example
... what are the privacy concerns and could anything be mitigated through standardisation?

Display items

<Ian> Issue 91

ij: there's been discussion about whether the payment handler should get line item information

rouslan: Marcos' point is that payment handlers don't need to know shopping cart contents to complete the transaction. But what we have seen is that some payment handlers DO show display items to the user
... e.g., Apple Pay does this
... we've made careful language decisions in the spec to say that these are items to be displayed to the user and should not include cart details
... but some information that could be useful might include "subtotal" or "tax" or "shipping price breakdown"
... that would be useful because, when you see an item that costs $50 and you push the button and suddenly the total is $60 you want to know why
... what we have been thinking about is to allow the merchant to opt-in: "the payment handler can see this display item; otherwise don't share"
... this would share our use case
... a variety of third party payment handlers have asked for this functionality
... so we have a proposal to add a boolean (default "false") that would allow a merchant to choose to share some information to the payment handler
... marcos and I have been going back and forth on how best to accomplish this

benoit: Regarding items in the cart, one is related to PayPal
... in PayPal people get to see cart contents.
... for something like Klarna, they use the contents in risk assessment

Frank: Yes, I concur. :)
... if I understand the proposal it is an item-level boolean

Rouslan: Yes

Frank: Having the possibility to be explicit as a merchant that you want to share would be good..but why do on item level?

Rouslan: I'd like to leave this decision tot the merchant

Frank: I will add an alternative proposal to GitHub

Laura: Concur from merchant POV it should be the merchant choice on what to share (whether line items or categories)...up to the merchant
... I do think it's a value to be able to provide the tax and shipping as a line item...helpful from a consumer perspective
... at the end of the day "merchant choice"
... we have some concerns about how data is used in the authorization phase

benoit: Merchant choice is per payment method. So a boolean per line item forces merchant to make global decision
... so may need to make this per payment method

Rouslan: Good point
... maybe we should create a list of origins instead of a boolean
... or also "*" for efficiency

<vkuntz> * some payments methods might require the line items - for regulatory reasons if linked to a loan

NickTR: Another option might be to make the preference payment method specific.

Next meeting

11 July

<nicktr> thank you everyone

Summary of Action Items

[NEW] ACTION: alex_liu to compile notes into a potential blog post (or other venue)
[NEW] ACTION: Ian to follow up with Laura about the idea of a web payments hackathon/workshop in early 2020 co-located with MAG

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/06/27 20:34:22 $