13:01:15 RRSAgent has joined #apps 13:01:15 logging to http://www.w3.org/2016/07/20-apps-irc 13:01:17 Zakim has joined #apps 13:02:52 Max has joined #apps 13:03:38 present+ Andre 13:03:40 present+ Ian 13:03:44 present+ Kapeng 13:03:46 present+ Dapeng 13:03:48 present+ Jason 13:03:53 present+ Conor 13:04:02 present+ Mahesh 13:04:10 conorh_wp has joined #apps 13:04:17 alyver has joined #apps 13:05:02 Kepeng has joined #apps 13:05:23 topic: New time 13:05:25 this is it! 13:05:30 maheshkk has joined #apps 13:06:28 topic: FTF feedback or impressions? 13:07:10 IJ: Any thoughts on the meeting? Key topics? 13:07:37 [No speakers] 13:08:10 topic: Issues 13:08:17 New repo -> https://github.com/w3c/webpayments-payment-apps-api 13:08:25 https://github.com/w3c/webpayments-payment-apps-api/issues 13:08:28 +q 13:08:36 ack conor 13:08:54 conor: I also sent comments / issues 13:08:59 ...is email sufficient? 13:11:38 Topic: #1 Should merchants be able to limit matching to trusted apps? 13:11:47 https://github.com/w3c/webpayments-payment-apps-api/issues/1 13:12:05 present+ JasonYoung 13:14:55 IJ: Any initial reactions? 13:15:17 q+ 13:15:18 Andre: Merchants want to know exactly what the experience will be like otherwise they will bypass the mechanism. 13:15:36 q+ 13:15:47 ...users may have a hard time knowing even what a payment app is, so the experience has to be good 13:15:50 ack Max 13:16:14 Max: I think I agree with the point. Nowadays, merchants who work with Aliababa...we have a trust relationships with them 13:16:32 ...as you mentioned, for card payments, it's not sure how to establish the trust relationship 13:16:37 ...so I think it's a valid concern 13:16:52 lol 13:17:41 Andre: Echoing what Jason said, there is concern about ensuring the checkout experience though payment apps is as good as it can be 13:18:07 ...from a merchant perspective, question is "is a customer going to install an app from a third party"? 13:18:45 q+ 13:18:45 ...it's not clear how people will know that a payment app (e.g., from some payment service provider) has to be installed in order to check out with a merchant 13:19:27 ack jno 13:19:30 ack aly 13:19:59 jnormore: Merchants want to increase conversion...the more options customers have, conversion drops 13:20:12 agree 13:20:12 ...the option to install multiple payment apps for the same type of payment will lower conversion 13:20:19 ...in particular for first-time experience 13:20:38 ..it's a huge deal for smaller merchants who don't have as many returning customers 13:20:50 q? 13:22:24 IJ: Should we just have merchant preferences that might affect ordering or should we have merchant preferences that affect filtering? 13:22:41 q+ 13:22:45 ack mach 13:22:47 ack mah 13:23:08 maheshkk: For the merchant, whether they recommend or prefer an app, it still doesn't tell me that the user has an app 13:23:28 ...if none are available, it's still no good for the merchant 13:23:36 ...merchant may still want a discovery mechanism 13:24:07 q+ to talk about related topic of query API 13:24:50 ..I still come back to the same question asked previously - should merchants have a way to discover whether a payment app is available? 13:25:28 ack me 13:25:28 Ian, you wanted to talk about related topic of query API 13:25:29 https://github.com/w3c/webpayments/issues/159 13:26:43 Also this issue: https://github.com/w3c/browser-payment-api/issues/155 13:28:06 The coding looks like this: 13:28:12 * Browser support API? If no then fail 13:28:17 * User have any apps? If no then fail 13:28:28 * payment request API? If no then fail, otherwise user select 13:30:49 (Related: displaying recommended apps, and how installed recommended apps v. uninstalled are displayed)? 13:31:16 IJ: Do we need a flow diagram? 13:31:32 +q 13:32:13 Mahesh: I would also like to be able to answer the question "Can they pay with my app?" with privacy protection. That would be useful. 13:32:15 ack cono 13:32:22 conorh_wp: Yes, I think the picture is coming together. 13:32:29 ...I think a flow diagram would definitely be useful. 13:32:48 ...The concept of a payment app is alien to consumers. Have we addressed that at all? 13:33:02 ...I think users may not care about payment apps...they just want to use credit cards in their wallet. 13:33:03 q+ 13:33:03 q+ 13:33:08 ack jno 13:33:33 jnormore: I have had the same thought. From a customer perspective, they want to choose the payment method (card, paypal, slippery, etc.) 13:33:37 s/slippery/alipay 13:34:15 ...so we show "pay with credit card" and then send users off to a page 13:34:21 ...we also show user-friendly brands 13:34:27 ...so is the registration model even necessary? 13:34:45 ..if it's up to the merchants to control what payment apps are visible, is the registration model hurting us? 13:35:37 IJ: Good topic - how to make registration as smooth as possible (near automatic)? 13:35:49 ack me 13:37:29 q? 13:38:20 IJ: Anyone want to work on a flow diagram? 13:38:29 (of how user selects payment apps, and possible queries?) 13:38:46 topic: Issue 2 - What portion of the PaymentRequest is sent to the payment app? 13:40:06 Jason has joined #apps 13:40:25 +q 13:40:47 IJ: Proposed that we only send the subset of payment request data that is relevant to the payment app 13:40:49 ack conor 13:41:04 conorh_wp: Would merchants ever send transaction-specific data for the processor? 13:41:10 (via tha payment app) 13:41:23 https://www.w3.org/TR/2016/WD-payment-request-20160705/#paymentrequest-constructor 13:43:18 IJ: You can send data, but if the data is not "standardized" you don't interop 13:45:05 IJ: Proposed that we only send the subset of payment request data that is relevant to the select payment app 13:45:14 +1 13:45:25 +1 13:45:29 +1 13:45:37 ACTION: Ian to report back to the issues list that there were no objections to the proposal 13:45:53 Topic: Conor's email 13:45:57 https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/0048.html 13:48:09 IJ: From merchant perspective, might have a range from "origin only" to "url to identify specific version" 13:48:18 IJ: From payment app perspective, that can be left to the payment app 13:48:33 ...if you allow payment app to query registration information 13:49:00 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes 13:50:46 IJ: the more we have merchants wanting to specify app preferences, the more some might want versioning 13:50:52 conor: but that increases coupling which we may not want 13:51:11 https://github.com/w3c/webpayments-payment-apps-api/issues/1 13:51:14 could add a note there 13:52:11 For suggestions, please do pull requests against the spec 13:53:07 Is there a reason .unregister(“request_url”) has not been proposed? => pull request please 13:53:09 +1 unregister() 13:57:09 [On registration and launch of native app] 13:57:26 IJ: Can have standard registration approach (using web) but launching may just be about good practice documentation 14:00:01 Topic: Requirements 14:00:08 topic: Design principles 14:03:48 q+ to ask what these are for payment request, an example would help 14:04:23 IJ: I mean something like "A user should be able to use any payment app for a given payment method" 14:04:27 ack AdrianHB 14:04:28 AdrianHB, you wanted to ask what these are for payment request, an example would help 14:04:34 AdrianHB: Did we do that for payment request API? 14:05:14 https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016-Requirements 14:06:11 IJ: We did that for PMIs. Not for payment request API AFAIK 14:06:17 ..it was used for PMIs and I think useful 14:07:36 +1 for sincere engagement 14:08:20 I Propose to take a stab at this for our meeting next week 14:09:00 ..to clarify, I don't want the task force to stop working on the spec 14:09:35 AdrianHB: I want to avoid going around in circles 14:10:27 IJ: I am looking for new ways to engage others and volunteering time 14:10:31 AdrianHB: Cool 14:10:51 AdrianHB: But we need also to be in fora where key players are...we need to hear from browser vendors directly, for example. 14:11:30 AdrianHB concrete proposal: 14:11:39 - our communication of this task force happens on the main list 14:11:44 q+ 14:11:48 ...so the meeting invitation and minutes go on the main list 14:11:50 +1 14:11:52 +1 14:11:58 +1 14:12:10 +1 14:12:22 ack andre 14:12:31 andre: I agree with AHB 14:12:33 +1 14:12:45 RESOLVED: Send agendas and minutes of these calls to the main WG list 14:12:56 q+ 14:12:57 ack aly 14:13:00 ack 14:13:02 ack me 14:15:08 alyver has left #apps 14:15:20 ACTION: Ian to announce the minutes of this call to the WG and plan to send agendas and minutes to that list 14:15:24 Topic: Next call 14:15:33 27 July at 2pm UTC (9am ET) 14:16:10 So sorry :( 14:16:22 The UTC time is pm UTC 14:16:25 The UTC time is 1pm UTC 14:16:49 I APOLOGIZE 14:17:33 rrrsagent, make minutes 14:17:36 rrsagent, set logs public 14:18:29 rrsagent, set logs public 14:18:36 rrsagent, make minutes 14:18:36 I have made the request to generate http://www.w3.org/2016/07/20-apps-minutes.html Ian 14:18:37 rrsagent, set logs public 14:43:00 jnormore has joined #apps 14:59:25 zakim, bye 14:59:25 leaving. As of this point the attendees have been Andre, Ian, Kapeng, Dapeng, Jason, Conor, Mahesh, JasonYoung 14:59:25 Zakim has left #apps 14:59:27 rrsagent, bye 14:59:27 I see 2 open action items saved in http://www.w3.org/2016/07/20-apps-actions.rdf : 14:59:27 ACTION: Ian to report back to the issues list that there were no objections to the proposal [1] 14:59:27 recorded in http://www.w3.org/2016/07/20-apps-irc#T13-45-37 14:59:27 ACTION: Ian to announce the minutes of this call to the WG and plan to send agendas and minutes to that list [2] 14:59:27 recorded in http://www.w3.org/2016/07/20-apps-irc#T14-15-20