See also: IRC log
<conorhwp> Hi Guys, have you joined the WebEx? It doesnt' allow me to join yet.
https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0119.html
roy: I read the js-api proposal a
read-over
... I am wondering what new use cases we are opening with
it
... Why this over HTTP?
adamR: Several things drove this
discussion, beyond discussion in London
... if you do service workers, doing HTTP POST is
straightforward,
... but if you take an HTTP-first approach, going to JS is
harder
... but the biggest thing that drove me down this path is that
I think that service workers will be much closer to how we will
integrate native apps
Roy: I didn't see anything
problematic wrt payment request API
... I didn't see any contradictions with my payment request API
editor hat one
IJ: Adam, do you see how the proposal should evolve based on the comments?
AdamR: I have skimmed through the
thread. One thing that I didn't see driven to ground - new
event or message passing?
... in London I argued for event over messages
<Zakim> AdrianHB, you wanted to say consensus seems to be new event
AdrianHB: At the tail end of the
thread I think the consensus is "new event". I was playing
devil's advocate to use post message, but I am hearing that
event is the way to go
... what I don't think we've come to ground on is how to do the
extension in service workers
... dave longley posted a nice snipped of code
... in it he takes the approach of defining an extension to the
service worker interface
https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-242895193
scribe: I'm not seeing a
consistent way to do things....in some cases there are new
interfaces that are children, in others, there are direct
modifications.
... but in short I'm hearing "event"
<AdrianHB> https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-242895193
adamR: Ok, so have a new method for sending the result back as well.
IJ: Are we ready for spec text?
AdamR: I will start by updating
the proposal.
... using service workers
IJ: +1 to revising and letting people know on the thread
<scribe> ACTION: AdamR to update the js api proposal to use service workers [recorded in http://www.w3.org/2016/08/31-apps-minutes.html#action01]
IJ: Do you think we might have spec text by tpac
IJ: Web App manifest - not yet consensus to go to CR...stay tuned also for Zach's proposal
IJ: What should be in the spec by pac?
by TPAC
* JS API stuff
https://github.com/w3c/webpayments-payment-apps-api/issues
IJ: Any other big edits?
(None cited)
Authenticity proposal to Zach ->
https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0112.html
Max: I did have discussion with Rouslan
IJ: Anything we can do to help?
Max: Just wait a bit
IJ: Max wrote a second proposal as well
<Max> https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown
Max: This is about the payment app user experience discussion
=> draft table of user experiences https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions
Max there are other use cases
[We review the use case]
Max proposal
- merchant should be able to query registration status for a payment app
scribe: to enable the merchant to be able to implement preference logic
- API to influence payment app order
alyver: There was concern about
merchants being able to query what the user has installed (for
privacy reasons)
... don't want to leak information to uniquely identified
customers
... Shopify would like to see it but I know there's been
pushback
... we already have the concept of "recommended payment
apps"...perhaps this is just an extension of that: "preferred
payment apps"
IJ: I don't really support
absolute control by the merchant, but I do want the merchant to
be able to express preferences
... Also, Zach/Ade have talked about queries in ways that
support privacy
... We can take this to the WG as well
Max, yes, let's do that
IJ: ON the topic of "preferred" v
"recommended" ... is "recommended in this order"
sufficient?
... another topic is "optional" v. "required" payment
methods
... I don't recall the use case exactly....
alyver: I think the primary issue
is "not having any payment methods supported"
... you don't want to send them down the path
... we have a fork in the flow - (1) if there are supported
payment methods, we use payment request API (2) otherwise
traditional flow
... I don't recall a use case of a particular match
Roy: It is quite a sacrifice for
merchants to give up the flexibility of controlling the
checkout flow
... I fear that we are trying to give back that control in a
bunch of different scenarios. Not sure if it's scalable
<AdrianHB> +1
adamR: My understanding had been - if no matches, then fail (no UI)
<AdrianHB> +1 to adamr. If there are no matching payment methods the failure is not visible to the user and the site can simply follow traditional flow
<adamR> +1 to Ian’s proposal
IJ: My view at a high level is "allow people to express prefs" and the browser can do useful things
alyver; Yes, +1 to adam's vision of flow (fail on no match)
scribe: but there's going to be a
transition period...payment method A supported in payment
request API but B only supported in legacy user
experience.
... the scenarios is "there might be only 1 match via payment
request api, but there might be multiple matches in a
traditional flow."
... and so the merchant might not want to reduce the chances of
conversion by giving users too few options.
<Zakim> AdrianHB, you wanted to suggest we should start simple and add recommended apps etc incrementally
AdrianHB: We should start simple;
we may not need recommended payment apps in v1 of the api
... I think that we'll learn a lot about user experience once
we get some deployment
... the data should inform the design
<Roy> +1
https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#design-considerations
to Conor: do you want to review the spec or the wiki?
conor: I will review the spec
7 September
IJ: Any regrets?