12:53:21 RRSAgent has joined #apps 12:53:21 logging to http://www.w3.org/2016/08/31-apps-irc 12:53:59 Meeting: Payment Apps Task Force 12:54:01 Chair: Ian 12:54:03 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0119.html 12:54:13 agenda+ spec update 12:54:18 agenda+ invocation 12:54:21 agenda+ display 12:54:36 agenda+ user experience 12:54:48 agenda? 12:54:55 zakim, clear agenda 12:54:55 agenda cleared 12:54:58 agenda+ spec update 12:55:01 agenda+ invocation 12:55:06 agenda+ display and user experience 12:55:19 agenda+ design considerations 12:55:34 Ian has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0119.html 12:56:05 conorhwp has joined #apps 12:56:39 Hi Guys, have you joined the WebEx? It doesnt' allow me to join yet. 12:58:51 TommyT has joined #apps 13:00:36 present+ Ian 13:00:39 regrets+ Jason 13:00:53 present+ Andre 13:00:55 present+ Roy 13:00:56 present+ Tommy 13:02:47 present+ Conor 13:03:16 present+ Adam 13:03:27 zakim, who's here? 13:03:27 Present: adamR, Ian, AdrianHB, Tommy, Max, jnormore, Mahesh, Andre, Roy, Conor 13:03:30 On IRC I see TommyT, conorhwp, RRSAgent, AdrianHB, Zakim, Dongwoo, Ian 13:03:39 alyver has joined #apps 13:03:41 present- Mahesh 13:03:44 present- Maax 13:03:46 present- Max 13:03:48 zakim, who's here? 13:03:48 Present: adamR, Ian, AdrianHB, Tommy, jnormore, Andre, Roy, Conor 13:03:50 On IRC I see alyver, TommyT, conorhwp, RRSAgent, AdrianHB, Zakim, Dongwoo, Ian 13:03:50 adamR has joined #apps 13:03:54 present- jnormore 13:04:00 present- AdrianHB 13:04:08 https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0119.html 13:04:30 zakim, take up item 2 13:04:30 agendum 2. "invocation" taken up [from Ian] 13:04:43 Roy has joined #apps 13:04:54 q+ 13:05:09 present+ Laurent 13:05:11 ack Roy 13:05:18 roy: I read the js-api proposal a read-over 13:05:25 ...I am wondering what new use cases we are opening with it 13:06:01 present+ AdrianHB 13:06:22 q+ 13:06:27 ack adamr 13:06:33 roy: Why this over HTTP? 13:06:44 adamR: Several things drove this discussion, beyond discussion in London 13:07:05 ...if you do service workers, doing HTTP POST is straightforward, 13:07:13 ...but if you take an HTTP-first approach, going to JS is harder 13:07:53 ..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 13:08:07 Roy: I didn't see anything problematic wrt payment request API 13:08:22 ...I didn't see any contradictions with my payment request API editor hat one 13:08:23 q? 13:08:46 Max has joined #apps 13:09:44 IJ: Adam, do you see how the proposal should evolve based on the comments? 13:10:07 AdamR: I have skimmed through the thread. One thing that I didn't see driven to ground - new event or message passing? 13:10:14 q+ to say consensus seems to be new event 13:10:18 ...in London I argued for event over messages 13:10:20 ack Ad 13:10:20 AdrianHB, you wanted to say consensus seems to be new event 13:11:11 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 13:11:23 ...what I don't think we've come to ground on is how to do the extension in service workers 13:11:29 ...dave longley posted a nice snipped of code 13:11:45 ..in it he takes the approach of defining an extension to the service worker interface 13:11:56 https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-242895193 13:12:18 ...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. 13:12:33 ...but in short I'm hearing "event" 13:12:42 https://github.com/w3c/webpayments-payment-apps-api/issues/33#issuecomment-242895193 13:12:46 adamR: Ok, so have a new method for sending the result back as well. 13:13:39 IJ: Are we ready for spec text? 13:13:46 AdamR: I will start by updating the proposal. 13:13:58 ..using service workers 13:14:22 IJ: +1 to revising and letting people know on the thread 13:14:38 ACTION: AdamR to update the js api proposal to use service workers 13:15:15 IJ: Do you think we might have spec text by tpac 13:17:05 topic: Manifests 13:19:56 Laurent_ has joined #apps 13:21:00 IJ: Web App manifest - not yet consensus to go to CR...stay tuned also for Zach's proposal 13:21:13 zakim, take up item 1 13:21:13 agendum 1. "spec update" taken up [from Ian] 13:21:46 IJ: What should be in the spec by pac? 13:21:49 by TPAC 13:21:54 * JS API stuff 13:22:10 https://github.com/w3c/webpayments-payment-apps-api/issues 13:22:30 IJ: Any other big edits? 13:22:36 (None cited) 13:22:50 zakim, take up item 3 13:22:50 agendum 3. "display and user experience" taken up [from Ian] 13:23:09 Authenticity proposal to Zach -> 13:23:09 https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0112.html 13:24:33 Max: I did have discussion with Rouslan 13:24:57 IJ: Anything we can do to help? 13:24:59 Max: Just wait a bit 13:25:14 IJ: Max wrote a second proposal as well 13:25:31 https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown 13:25:56 Max: This is about the payment app user experience discussion 13:26:26 => draft table of user experiences https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions 13:26:40 Max there are other use cases 13:27:36 [We review the use case] 13:30:44 Max proposal 13:31:00 - merchant should be able to query registration status for a payment app 13:31:20 ...to enable the merchant to be able to implement preference logic 13:31:45 - API to influence payment app order 13:31:46 q+ 13:31:54 q+ 13:31:59 ack alyver 13:32:23 alyver: There was concern about merchants being able to query what the user has installed (for privacy reasons) 13:32:41 ...don't want to leak information to uniquely identified customers 13:32:55 ...Shopify would like to see it but I know there's been pushback 13:33:29 ...we already have the concept of "recommended payment apps"...perhaps this is just an extension of that: "preferred payment apps" 13:33:32 ack me 13:34:43 q+ 13:35:13 q- 13:36:42 IJ: I don't really support absolute control by the merchant, but I do want the merchant to be able to express preferences 13:38:57 IJ: Also, Zach/Ade have talked about queries in ways that support privacy 13:39:35 IJ: We can take this to the WG as well 13:39:39 Max, yes, let's do that 13:41:34 IJ: ON the topic of "preferred" v "recommended" ... is "recommended in this order" sufficient? 13:42:57 IJ: another topic is "optional" v. "required" payment methods 13:44:12 IJ: I don't recall the use case exactly.... 13:45:19 q+ 13:45:24 q+ 13:45:26 ack aly 13:45:37 alyver: I think the primary issue is "not having any payment methods supported" 13:45:45 ...you don't want to send them down the path 13:46:16 q+ 13:46:24 ...we have a fork in the flow - (1) if there are supported payment methods, we use payment request API (2) otherwise traditional flow 13:46:38 alyver: I don't recall a use case of a particular match 13:46:40 ack Roy 13:47:07 Roy: It is quite a sacrifice for merchants to give up the flexibility of controlling the checkout flow 13:47:24 ...I fear that we are trying to give back that control in a bunch of different scenarios. Not sure if it's scalable 13:47:25 q+ 13:47:36 +1 13:47:45 ack adamR 13:48:26 adamR: My understanding had been - if no matches, then fail (no UI) 13:48:46 +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 13:49:21 q? 13:49:37 ack me 13:50:10 q+ 13:50:10 +1 to Ian’s proposal 13:50:57 IJ: My view at a high level is "allow people to express prefs" and the browser can do useful things 13:51:15 alyver; Yes, +1 to adam's vision of flow (fail on no match) 13:51:41 ...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. 13:52:34 ...the scenarios is "there might be only 1 match via payment request api, but there might be multiple matches in a traditional flow." 13:52:47 q+ to suggest we should start simple and add recommended apps etc incrementally 13:52:53 ...and so the merchant might not want to reduce the chances of conversion by giving users too few options. 13:53:38 ack Adr 13:53:38 AdrianHB, you wanted to suggest we should start simple and add recommended apps etc incrementally 13:55:06 AdrianHB: We should start simple; we may not need recommended payment apps in v1 of the api 13:55:21 ...I think that we'll learn a lot about user experience once we get some deployment 13:55:27 ..the data should inform the design 13:55:40 +1 13:55:43 q? 13:55:48 ack aly 13:56:11 Topic: Design considerations 13:56:12 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#design-considerations 13:56:35 to Conor: do you want to review the spec or the wiki? 13:56:58 conor: I will review the spec 13:57:17 Topic: Next meeting 13:57:23 7 Setpember 13:57:32 IJ: Any regrets? 13:57:36 I have made the request to generate http://www.w3.org/2016/08/31-apps-minutes.html Ian 13:57:47 rrsagent, set logs public 14:01:57 alyver has joined #apps 14:05:54 alyver has left #apps 15:03:56 Max has joined #apps 15:53:06 Max has joined #apps