13:59:28 RRSAgent has joined #apps 13:59:28 logging to http://www.w3.org/2017/05/23-apps-irc 13:59:54 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017May/0055.html 14:00:03 Meeting: Payment Apps Task Force 14:01:08 Chair: Ian 14:01:36 rouslan__ has joined #apps 14:01:45 alyver has joined #apps 14:02:15 Scribe: Ian 14:02:18 present+ Frank 14:02:19 present+ 14:02:41 present+ Andre 14:03:23 frank has joined #apps 14:03:27 present+ rouslan 14:04:43 present+ Christian 14:04:55 present+ 14:04:56 Ken has joined #apps 14:05:08 present+ Danil 14:05:11 AdrianHB has joined #apps 14:05:12 present+ Chris(MC) 14:05:40 regrets+ AdrianHB 14:05:49 Topic: Payment Handler FPWD 14:05:50 https://www.w3.org/blog/wpwg/2017/05/18/payment-handler-api-first-public-working-draft-published/ 14:06:56 Topic: Implementations 14:07:32 q+ 14:07:41 IJ: Upcoming implementation plans or ideas? 14:07:42 ack rouslan 14:08:09 rouslan__: In Chrome...we are developing the API for Android and Desktop. Our desktop PR API implementation has not yet shipped, so we are focused on Android for now. 14:08:25 ...we are looking into how to properly open the window 14:08:35 ..so that it looks good for the payment app that is a website (on android) 14:09:07 ...we have some ideas for that 14:09:20 ..on desktop, we haven't shipped PR API yet but are close to doing so; showed at Google I/O 14:10:05 ..we are having UX discussions about how to best present payment apps on desktop. What was mentioned in Chicago still stands I think - the payment app web page will be shown in a dialog window where the user would do the payment 14:12:21 IJ: Any word on desktop implementation availability? 14:12:30 rouslan: Look for it in stable release in Aug/Sep 14:13:51 q+ 14:14:26 IJ: Would be great to hear other plans 14:14:50 frank: We are happy to start experimentation as soon as there is support in the browser for web-based payment apps, which sounds like it is coming soon. 14:15:58 q+ 14:16:00 ack frank 14:16:02 ack rouslan__ 14:16:17 IJ: Any critical path features that we need to deal with to do experiments? 14:16:29 rouslan__: We need to automate web platform tests that involve user interactions 14:17:00 ...Marcos has a proposal that involves a payment method specific to testing environment. 14:17:19 ..that way we can test conformance of browsers. 14:17:41 ...there seems to be consensus on this approach for PR API; perhaps we can do something similar for Payment Handler 14:17:52 ...e.g., reserved payment method for a testing environment that could be used for automation testing. 14:19:20 IJ: Anything that could be usefully done to prepare for implementation testing? 14:19:55 Topic: Issue 129 Add .clear() to map-likes 14:20:07 IJ: I am in touch with people suggested by Marcos 14:20:39 ....Ali Alabbas, Joshua Bell 14:20:54 ...meet with them later today 14:21:11 ...perhaps need an asyncmaplike 14:22:07 https://heycam.github.io/webidl/#idl-maplike 14:23:08 https://github.com/w3c/payment-handler/issues 14:23:31 IJ: Any ones people want to look at in particular? 14:23:48 Topic: Issue 157 - filtering and matching 14:24:07 https://github.com/w3c/payment-handler/issues/157 14:25:04 q+ 14:25:37 ack rous 14:26:58 rouslan__: I think that what implementers want is to keep PR API shape as-is and use the algo text to define how exactly filtering happens. 14:27:45 q+ 14:28:36 IJ: It's one thing to say "the algo says this" and another to say "where does it really happen -UA or payment app?" 14:28:42 rouslan: I think jury is still out. 14:28:52 ...weigh privacy v. capabilities of payment handlers 14:29:23 ...I think that payment handler API will be more specific than just "filtering happens here". 14:31:32 q+ 14:31:34 ...but ack rous 14:31:55 IJ: Are we prepared for a canMakePayment() type approach for payment apps (which we said "no" to previously)? 14:32:19 rouslan__: I think we are going to compare details...don't think we will call any functions 14:32:38 ...having said that, we are still in the early stages of experimentation with Payment Handler API and payment app writers 14:32:58 IJ: Should people on this call talk to you about those experiments? 14:33:01 rouslan__: Please do 14:33:28 IJ: Please contact Rouslan to help address this issue through implementation experience. 14:34:06 Topic: Issue 128 examples 14:34:06 https://github.com/w3c/payment-handler/issues/128 14:35:23 (Maybe those are issues 2 and 3 now) 14:35:39 Topic: Issue 123 Share user data with Payment App 14:36:00 IJ: Any updates from implementers since the FTF? 14:36:09 q+ 14:36:24 ack rouslan 14:36:43 rouslan__: We've not heard from other app providers besides Klarna on this use case. 14:36:50 ...but leave open 14:37:23 Topic: Issue 74 - recommended payment apps 14:37:24 https://github.com/w3c/payment-handler/issues/74 14:37:41 https://github.com/w3c/payment-handler/issues/74#issuecomment-291548795 14:38:37 q+ 14:39:07 IJ: What are plans for browser-assisted support for recommendations of mobile payment apps? 14:39:24 rouslan: Have had some discussions but not implemented... 14:39:41 ...we think that recommended payment apps could work better on web than native mobile 14:39:54 ...loading a payment app would be useful to a user 14:40:09 ...so we think that recommend payment apps might be useful ... the spec may not need to change to support it 14:40:22 ...but we haven't really designed or implemented of this; just some ideas for now 14:40:54 topic: Issue 117: Support for Abort() being delegated to Payment Handler 14:41:02 q+ 14:41:05 ack rouslan__ 14:41:10 IJ: Has this come up? 14:41:23 rouslan__: We keep hearing this might be a requirement. We might be adding this to the native android payment app spec 14:41:31 ...not sure yet, though 14:42:02 q+ 14:42:08 ...I would not be opposed to adding an abort() event to payment handler...some nativepayment app developers have asked for this 14:42:11 ack aly 14:42:21 q+ 14:42:35 alyver: Beyond a certain point, abort may not always be successful. is the expectation that payment apps be able to handle abort() or do a refund for example? 14:42:36 ack rou 14:43:03 rouslan__: I think the expectation is that the event is fired into the payment app if the merchant site requests an abort (e.g., timeout or no more tickets available) 14:43:36 ..so payment app could do different things depending on the user's activity...e.g., if user is just starting to type info 14:43:52 ..but if payment app is processing or has completed transaction...hten the payment app can signal that the abort failed. 14:44:03 ..this gives the merchant site some idea of whether their abort request went through. 14:44:50 IJ: +1 to basically saying this is a signal, rather than having conformance requirements specifically for payment apps 14:45:43 IJ: Should we wait for rouslan mobile experience before spec'ing out? 14:45:53 +1 to it being useful 14:46:25 https://github.com/w3c/payment-handler/issues/117#issuecomment-291522464 14:48:04 Topic: Next Meeting 14:48:34 IJ: Rouslan, anything we can do to help you out? 14:48:50 Rouslan: Await further updates! 14:49:12 +1 14:49:15 +1 14:49:16 Proposed two weeks - 6 June 14:49:21 Next meeting: 6 June 14:49:29 RRSAgent, make minutes 14:49:29 I have made the request to generate http://www.w3.org/2017/05/23-apps-minutes.html Ian 14:49:36 RRSAgent, set logs public 14:49:42 alyver has left #apps 14:56:34 cweiss has joined #apps 15:31:53 alyver has joined #apps 15:32:19 alyver has left #apps 16:57:19 Zakim has left #apps 17:05:14 cweiss has joined #apps 17:49:34 cweiss has joined #apps 17:55:34 cweiss has joined #apps 19:07:36 cweiss has joined #apps 19:13:51 cweiss has joined #apps 20:47:14 cweiss has joined #apps 22:06:58 cweiss has joined #apps 22:56:26 cweiss has joined #apps 23:55:47 cweiss has joined #apps