ian: Good discussion on use cases
on last call
... check in on actions today
<Ian> previously: Ian to discuss with the WPSIG chairs moving identity topic to that agenda
ian: raised by David. Taken to chairs and raised on WPSIG call. I think it will be pursued there.
<Ian> https://github.com/w3c/payment-request/wiki
ian: second action on me was
<benoit> boarding a plane... sorry. is leaving early
<Ian> Done: Ean to add to the wiki the general topic of returning to a payment handler after PR API complete()
ian: to review wiki and is done
<Ian> https://github.com/w3c/payment-request/wiki#merchant--customer-relationship-lifecycle
ian: what came from last call was
that there is a spectrum of ? use cases
... I've reframed this as steps in merchant and user
relationship
... this has manifested as edits to the wiki
... (i.e. rouslan's action item is done)
... are Danny and David satisfied with edits
<Ian> Danny: Did not see edits; I might have been swamped
danny: haven't reviewed yet
<Ian> https://github.com/w3c/payment-request/wiki#merchant--customer-relationship-lifecycle
david: notes not shared yet
... will share
ian: have others reviewed use
cases in last 2 weeks and if so have additions/comments?
... I haven't worked on this since
... doc still needs work, following which we can start planning
further work
<Ian> Airbnb questions
ian: will hand to Alex to walk through email questions
<Ian> scribenick: Ian
<AdrianHB> Alex: we are doing a re-write for mobile. Keen to leverage PR API for collection of payment info (and management)
alex: Today at airbnb when you go through booking you need an account before collecting payment information
<AdrianHB> ... esp for users that aren't users on airbnb yet
alex: question is whether we can delay user signup and collect payment information prior to creating account
<AdrianHB> scribeassist: ian
alex: so we'd like to get some
data, and only at the end of the flow, after agreement, we use
the information both for payment and account creation
... as part of that, Airbnb also uses a lot of different
payment handlers, e.g., Paypal, basic card, but also Alipay,
WeChat pay
... so a question is what is the best practice to account for
other payment providers
... should we create all the handlers ourselves?
... for users who use iOS/Safari ... it only supports ApplePay
through PR API...for the other payment methods, how do we
support that as well?
rouslan: I saw the NY Times do
something similar..open sheet to ask for $0 if user wants to
update details
... so that "seems ok"
... in your use case, I think you characterized it better
here...you said you are collecting payment information in step
1 but only charging in step 3
... I think that's fine. I understand that in the complete
method there is an enum value specifically for this case:
"unknown" completion status
... this indicates to the browser that the sheet should
close
... in essence your use case is one long transaction.
... however, are you saying you just want the name without the
payment information?
... We also have autofill for some data collection, and
previous discussions about API for some other data collection
(that have not been implemented)
... regarding Paypal not being a payment handler, I would love
to see that.
... I think it would be unlikely that the browser would
integrate directly with a specific payment provider
<AdrianHB> For those that haven't seen it: https://www.w3.org/blog/wpwg/2019/05/16/the-next-innovation-in-payment-handler-distribution/
rouslan: we look forward to payment handler API support in more browsers moving forward
<AdrianHB> Many more reasons to write oayment handlers
<AdrianHB> And implement support
rouslan: If we created a PH API
polyfill, would that be useful?
... or if we took an existing payment method and converted it
to something that makes it work inside the browser sheet in
Chrome, or fell back to the original intention of the payment
method in other browsers, would that be useful?
<Zakim> AdrianHB, you wanted to mention orthogonal terms here
AdrianHB: There's an interesting
issue raised here - some payment methods have usage terms
... if you use apple pay or google pay, then information that
is returned from that process, the terms of the payment method
say what you can do with the data.
... that's orthogonal to PR API
<benoit_> dropping off
AdrianHB: I'm not sure if the WG needs to do anything regarding how payment method owners define terms
<Zakim> danyao, you wanted to opine about "unknown" return code and $0 price
danyao: I want to talk about
using PR API to collect signup and complete a transaction
later
... when the payment sheet closes, the transaction has not
happened yet
... a component of this proposal may have a fake price..my
concern would be the fake price...
... I may put forward a distinct proposal...can you structure
the flow where payment request is used for guest checkout
... and then you redirect the user to a signup flow
... I think it would be better than mislabeling a button and
may confuse the user
alex_liu: I think we will
probably be able to show you a real price when the sheet pops
up
... you provide some info to airbnb to pick a play to stay,
then you would click an "add a payment method" button and we'd
call PR API having been explicit that we are collecting
information, with the correct price since the user has been
through everything
... we don't want to have to create the account before learning
about the payment methods available on the platform
... we want to give all the info to the user without
necessarily requiring account creation yet...only after the
user has committed, at the end
... e.g., reviewing the details, then add payment method +
apply coupon, review and pay button
... then we'd be able to tokenize, invoke the instrument, and
then use that information to create an account for the user
danyao: Addresses my concerns, thanks
alex: Some Airbnb users might
have instruments in their account (e.g., credit card)
... what are thoughts about consolidation of instruments on
site and those known to payment request.
<Zakim> rouslan, you wanted to make a suggestion that AirBnB shows PaymentRequest flow at the time of booking, in context, and sign up the user at that time.
rouslan: I think that current
implementations require the merchant to show cards on file or
other instruments outside the sheet....PR API does not have
access to instruments
... though that is an interesting idea, and aligns with Apple
Pay's ability to show merchant's stored addresses
... so maybe we should consider presentation of other
information stored in the sheet
https://github.com/w3c/payment-request/issues/653
Ian: Alex, please add your use case to that issue
Alex: Ok
rouslan: I heard agreement that
showing the sheet "in context" could avoid confusing the
user
... One other question that was raised in email was "What
happens today for payment methods than cannot be shown in the
sheet?"
... the workaround is to show them as branded buttons on the
page
... that's suboptimal...I would more payment method support via
PR API
alex_liu: Thanks for answers; I will take back discussion internally
https://github.com/w3c/payment-request/issues/653
<AdrianHB> ian: as you know we're in the last throes of work on PR API v1
https://w3c.github.io/test-results/payment-request/all.html
<dannywp> apologies have to jump off
<AdrianHB> ... we have latest data from Chrome and Samsung Internet
https://w3c.github.io/test-results/payment-request/less-than-2.html
<AdrianHB> ... bug in Safari picked up by tests and waiting on data in that regard
<AdrianHB> ... 20ish tests that don't pass
<AdrianHB> ... some not relevant to CR
<AdrianHB> ... others being investigated
<AdrianHB> ... close to passing all tests on at least 2 impls at which point we can go to PR
<AdrianHB> ... no timeline as yet but browsers are keen to get wrapped up
<scribe> scribenick: Ian
AdrianHB: At April FTF I
presented Web Monetization to the WPWG
... we are attempting to standardize an API that web sites can
use to request micropayments from the user
... currently we proposed a declarative interface: a web site
puts metadata in page header; this instructs the browser where
payments can be sent, then the browser (through a provider of
micropayments) sets up a flow between the provider of payments
to the site wallet. The browser fires events in the merchant
page when money is received
... there are ongoing conversations about a different
architecture that works more with payment request
... for example a web monetization payment method, where the
provider is basically a payment handler, and the merchant
receives an object through payment request
... to achieve this would require some changes to APIs because
the APIs are 1-offs today
... whereas web monetization requires the ability to stream,
rather than just a 1-off response
... Coil will be promoting this work for the next few months
and we will organize sessions at TPAC 2019 for those
interested
... we have implemented this in the form of a browser extension
currently
... Coil subscribers install an extension...in the future the
goal is for browsers to do this natively
... we'd like to bring the specification to W3C for
standardization
... so the question I have for the group, is: should we develop
this in the WPWG?
... it's a new set of use cases with new capability
requirements
... these are lower risk (small) payments so different security
requirements
... also, recurring
<AdrianHB> https://interledger.org/rfcs/0028-web-monetization/
AdrianHB: My intention is to start conversations in the Web Platform Incubator CG
https://www.w3.org/community/wicg/
AdrianHB: Should I publish this spec in that CG first (before WPWG) or start in the WPWG?
<Zakim> rouslan, you wanted to opinionate
rouslan: I am excited about
supporting this use case
... I don't know enough of W3C process to know where this
should go
AdrianHB: I don't want people to
be surprised if the work is published in the Community
Group
... I am happy to do this work in the WG, but I do want
feedback from outside the WG as well
rouslan: Sounds like the CG is an
excellent home for this work and I hope you get the TAG
review
... send the WG regular updates
... and raise issues in the WG on PR API or PH API
<AdrianHB> ian: the W3C process is setup to allow for various scenarios
<AdrianHB> ... if this was worked on elsewhere and brought new reqs to our work then that would be fine
<AdrianHB> ... if you want the work to go through formal standards then it would need to come to WG
<AdrianHB> ... it sounds like we should capture this in the use cases of the WG now though
<AdrianHB> ... so we can capture how this would impact PR API and PH APi now
<AdrianHB> ... is what you want achievable today? Can it be done independant of PR API?
AdrianHB: I am hearing:
- Put spec together
- Develop in the CG
- Keep the WG apprised of progress
- Raise issues on PR API and PH API
- Document use case in WPWG wiki (via link to issue)
AdrianHB: My goal would be for TPAC to be a decision point whether there is sufficient interest in the WG to take this up as a formal deliverable
AdrianHB: SCA not so easy for
subscription.
... suppose the merchant wants to debit my account next month
for my subscription. How does that work?
... how do PSD2 regulations govern recurring payments?
https://stripe.com/guides/strong-customer-authentication
"Strong Customer Authentication will apply to “customer-initiated” online payments within Europe. As a result, most card payments and all bank transfers will require SCA. Recurring direct debits on the other hand are considered “merchant-initiated” and will not require strong authentication. With the exception of contactless payments, in-person card payments are also not impacted by the new regulation."
Ken: I can try to get an answer if you send me a detailed email.
https://www.adyen.com/blog/psd2-understanding-strong-customer-authentication
"Subscription or recurring transactions with a fixed amount will be exempt from the second transaction onwards. Only the initial transaction will require SCA. If the amount changes, 3D Secure will be required for every new amount."
Dean: I think it's more complex than that..there are other risk-based considerations
Merchants offering a subscription billing model will be able to take advantage of the recurring transactions exemption, but only after applying SCA to the first transaction, and only if the amount and recipient of the payment are the same.
Alex: We are also working on SCA at Airbnb. Braintree also told us merchant-initiated transactions don't follow under the same scope. But if you find out otherwise, we are interested in understanding that, and relation to PR API
See discussion from Lyon: https://www.w3.org/2018/10/23-wpwg-minutes#risk
13 June