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 MAGLaura: 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)
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
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?
<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.
11 July
<nicktr> thank you everyone