14:00:54 RRSAgent has joined #apps 14:00:54 logging to http://www.w3.org/2017/09/19-apps-irc 14:00:59 Meeting: Payment Apps Task Force 14:01:02 Chair: Ian 14:01:19 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0033.html 14:02:14 present+ DannyRussell 14:03:50 rouslan has joined #apps 14:03:55 present+ 14:03:56 present+ Rouslan 14:04:40 alyver has joined #apps 14:05:31 present+ alyver 14:05:52 topic: Disband the task force 14:06:52 Proposed: End regular TF calls; use this slot as needed for editors 14:06:54 +1 14:06:58 +1 14:07:39 Danny_Wp has joined #apps 14:08:09 RESOLVED to end regular TF call and move topics to WG agenda 14:08:20 Topic: Implementation updates 14:08:33 q+ 14:08:38 ack rous 14:08:58 rouslan: We've been implementing on desktop and recently landed a change that allows service worker to open a window to prompt the user for input 14:09:09 ...we've not styled it yet....it's going to be "smaller" than a full size window 14:09:20 https://www.w3.org/2017/Talks/ij_uspayments_20170912/w3c.pdf 14:10:13 q+ to ask Rouslan whether this is in canary? 14:11:01 Rouslan: An issue we ran into - how to ensure the user does not think that the payment app window is NOT part of the web site 14:11:21 ....we've decided that it will look like a pop-up window but that the user cannot resize or move it. 14:11:58 IJ: Heads up on accessibility issues. 14:12:09 Rouslan: It's just an HTML page; you can change font size, print it, etc. 14:12:23 ..if you navigate to a new origin, it will probably open a new tab 14:12:34 Ken has joined #apps 14:12:38 present+ Ken 14:12:53 Rouslan: On cross-platform side, we have been experimenting with canMakePayment()...have not settled on it yet 14:13:29 ...we think maybe there is a middle ground approach where service workers that use standardized W3C payment methods will be filtered by the browser because, when the merchant says "I accept basic card" they don't have as much controle 14:14:02 ...for URL-based PMIs, and where the URLs are validated through manifests, we think firing canMakePayment event would be better. 14:14:20 IJ: If I understand: 14:14:29 1) For standard payment methods, static filtering 14:14:45 (static = browser-based in my mind) 14:15:01 2) For URL-based PMIs, fire an event (=payment app does capability matching) 14:15:23 Danny: What is the performance impact / user experience impact of firing an event? 14:15:48 Rouslan: Good question. In the original implementation we made canMakePayment required and we used a timeout 14:16:20 ....currently, however, canMakePayment event is not required, so if your service worker is not registered for the event, you will not be penalized in terms of performance 14:16:58 ...performance is definitely important....we have been creating the payment request object before the user clicks the checkout button 14:17:09 ..when the user clicks the Buy button, we call show() 14:17:26 ...that's because creation of payment request object initiates query of canMakePayment 14:17:37 ..if you are on a slower device, it might take up to 2 seconds (in my experience) to query payment apps 14:17:41 good tip! 14:17:50 ...because of that we've been recommending creating payment request object and call show() only later. 14:18:04 https://github.com/w3c/payment-request-info/wiki/CodeExamples 14:18:14 IJ: Should we add that performance-friendly note there? 14:18:55 Rouslan: It's not called out, but it's shown in the first example 14:19:04 ...what happens on click event is request.show() 14:19:08 ack alyver 14:19:08 alyver, you wanted to ask Rouslan whether this is in canary? 14:19:21 alyver: Is the openWindow in Canary? 14:19:37 rouslan: I think it's landing now, should be there within a couple of days 14:19:49 sorry i probably spoke out of turn 14:20:08 rouslan: We are also implementing payment method manifest; should be in Canary within 3-4 days 14:20:36 ...if your service worker accepts basic card or inter ledger you're fine...if your service worker accepts a payment method of the same origin you are fine.... 14:21:46 ....if your payment app has a different origin than the payment method origin, then we download the payment method manifest and we check the supported origins field 14:21:51 ...if the origins field is "*" anyone can use it 14:21:59 ..if the supported origins field is a list of origins then we check against that list 14:22:06 present+ adrianHB 14:22:16 ...otherwise service worker not displayed to the uesr 14:22:59 q+ 14:23:02 ack rous 14:23:15 IJ: Shouldn't expect it to never change (the spec) since not yet at FPWD, but good work! 14:23:21 Rouslan: Maybe we should write some tests. 14:23:30 IJ: Anyone want to help rouslan write tests for that? 14:23:37 [Crickets] 14:24:23 Topic: Pull request review 14:24:23 https://github.com/w3c/payment-handler/pulls 14:24:48 https://github.com/w3c/payment-handler/pull/194 14:24:48 q+ 14:24:52 ack aly 14:25:48 https://github.com/w3c/payment-handler/pull/170 14:25:56 Rouslan: We are experimenting, balancing privacy and user experience 14:26:42 ...mozilla folks are wrapping up work on payment request and then we should be able to work with them to get consensus 14:26:57 https://github.com/w3c/payment-handler/pull/194 14:28:23 https://github.com/w3c/payment-handler/pull/207 14:28:50 Rouslan: We are implementing it; we've not gotten any payment apps to experiment with this. 14:29:06 Danny: I can work with Rouslan on this. 14:29:35 AdrianHB has joined #apps 14:31:28 IJ: Maybe include Frank Hoffman in experiments as well 14:31:38 https://github.com/w3c/payment-handler/pull/209 14:32:38 IJ: How is the text? 14:32:52 Rouslan: I will integrate your suggestion and upload the patch; I don't think we need a test for that. 14:33:08 https://github.com/w3c/payment-handler/pull/213 14:33:49 IJ: Adrian or Rouslan; please review the deletion 14:34:06 https://github.com/w3c/payment-handler/pull/214 14:35:34 q+ 14:36:16 q+ 14:36:16 AdrianHB: Do you think browsers should do something to help developers understand why a payment app was excluded? 14:36:17 ack AdrianHB 14:36:19 ack rouslan 14:36:23 rouslan: +1 14:36:34 ...suggest printing console messages when something like this happens 14:36:48 ...from our experience with app integration and manifest we've been quite silent with logging 14:36:52 +1 14:36:55 ...and this has confused develoeprs 14:37:06 ...it's better when the code tells you what mistake you mde 14:37:29 do we need to say something in the spec? 14:38:07 IJ: What do devs want and what do browsers typically say? 14:39:06 Danny: +1 to good practices for logo sizes as well 14:39:10 ...for payment apps 14:39:30 https://github.com/w3c/payment-request-info/wiki/PaymentAppPractice 14:40:24 q+ 14:40:46 rouslan: Icon guidance is a very good idea 14:40:48 ack rous 14:40:57 ...we are working on our icon selection algo right now 14:41:01 ...where there are multiple sizes 14:41:24 ...I think best approach is for devs to let us know their issues on logging messages in the issue tracker 14:41:59 q+ 14:42:18 IJ: Should we add something like "and should inform developers of the rationale for the exclusion" 14:42:29 q+ 14:42:35 ack me 14:43:47 IJ :What user experience is there in the case where browser is not showing an app (e.g., manifest-based or error) is there a user experience explaining why? 14:43:49 ack D 14:44:22 Danny: One issue I've had in implementation is "what's the messaging that we have for users and merchants for the methods that the merchant supports that the user may not have installed, and the ones that the user has installed but are not accepted?" 14:44:28 Don't think we can have a normative req on UI but could put a SHOULD "indicate to users any apps that have been excluded and why"? 14:44:41 q+ 14:44:55 Danny: Should we have a standard UI for understanding who has what? 14:45:01 ack rouslan 14:45:38 rouslan: Our hope is that there will be a single Buy button and that the button works by calling PR API with all of the merchant's supported payment methods, then the merchant falls back to a legacy payment flow 14:45:44 q+ 14:46:09 ...but pr api is not powerful enough yet to support all the payment methods the merchant might accept 14:46:27 ....the solution that we are trying to propagate right now is to come up with a graphic and phrasing to share with the world that 14:46:35 ...we would recommend be used when payment request is invoked 14:46:43 q+ to talk about mark 14:46:57 perfect. this would be similar to the contactless logo 14:47:10 ack aly 14:50:04 q? 14:50:06 ack me 14:50:06 Ian, you wanted to talk about mark 14:50:34 IJ: I am hearing: 14:50:47 1) Console logging is appreciated and messages to developers could be added to this pull request 14:50:55 2) What is the user experience in a couple of cases: 14:51:01 a) Exclusion of a payment app 14:51:08 b) Querying available payment methods 14:52:05 IJ: Is there any work going on in recommended payment apps (by the browser)/ 14:52:18 rouslan: We are thinking about ways to suggest payment apps that have not yet been installed 14:52:40 ...these would be shown "below" installed one 14:52:44 installed ones 14:53:04 ...we might show some recommended payment apps and do just-in-time registration 14:53:28 ....and immediately fire PR API event for that service worker 14:53:37 +1 14:54:13 IJ: Anything needed in the spec? 14:54:20 Rouslan: Don't think so; feels like user experience optimization 14:55:50 IJ: Should we spend more time on "informing the user of exclusions" 14:55:59 Rouslan: Ok to leave it in as "should" or "may" 14:56:30 Topic: Next meeting 14:56:36 None! We'll move to the WG 14:57:08 IJ: Thank you all very much! 14:57:20 RRSAGENT, make minutes 14:57:20 I have made the request to generate http://www.w3.org/2017/09/19-apps-minutes.html Ian 14:57:20 Thanks Ian for chairing this 14:57:24 RRSAGENT, set logs public 15:29:27 zakim, bye 15:29:27 leaving. As of this point the attendees have been DannyRussell, Ian, Rouslan, alyver, Ken, adrianHB 15:29:27 Zakim has left #apps 15:29:35 RRSAGENT, bye 15:29:35 I see no action items