13:59:16 RRSAgent has joined #apps 13:59:16 logging to http://www.w3.org/2017/06/06-apps-irc 13:59:23 Meeting: Payment Apps Task Force 13:59:27 Chair: Ian 13:59:39 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0000.html 14:03:53 Ken has joined #apps 14:04:56 regrets+ AdrianHB 14:05:02 present+ 14:05:05 rouslan has joined #apps 14:05:05 present+ alyver 14:05:07 present+ Ken 14:05:08 present+ 14:05:29 -> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0000.html Agenda 14:05:43 Topic: Recent changes 14:05:44 https://github.com/w3c/payment-handler/commit/624cb43deb81db326523b9afa6836f34c8871f95 14:06:55 rouslan: Makes sense 14:07:03 Topic: Issue 163 14:07:07 https://github.com/w3c/payment-handler/issues/163 14:07:19 q+ 14:07:30 ack rouslan 14:07:46 rouslan: client.OpenWindow can return null window if the SW tries to open a URL that is from a different origin 14:08:00 ...e.g., PayPal could not open a mastercard.com page 14:08:27 ...this is not an issue because we have defined our open window backend to be restricted to the origin of the service worker 14:08:38 ..the service worker gets a security error instead of a null value 14:08:42 ...so the user never sees a window 14:08:58 ...we noticed this discrepancy and wondered what to do with the spec 14:09:17 ...the problem in the spec is that there is some text that talks about returning null and checking the origin; seems like a copy/paste error for the SW spec 14:09:28 ...so we have someone from samsung to do a PR to clean up the spec 14:09:43 ...so that it's clear everywhere that SW from origin A can only open pages to the user that also come from origin A 14:10:41 ..note that our openWindow algo is not exactly same (by design) as the SW algo 14:13:52 ...my expectation is that Samsung engineers are working on this for Blink 14:14:14 Topic: Implementer updates 14:14:15 q+ 14:14:18 ack rouslan 14:14:23 rouslan: Going great! 14:14:34 chrome://flags/#enable-experimental-web-platform-features and 14:14:34 chrome://flags/#service_worker_payment_apps flags 14:14:35 ...we have implemented openWindow in Chrome behind 2 flags 14:15:00 ..in the next Canary (day or two) on Android you should be able to flip the 2 flags and get the full flow of payment handler 14:15:05 ...a few things are still missing - icons 14:15:15 ...still figuring out caching, icon sizes, etc. 14:15:33 ...once the spec is finalized we'll update the implementation based on the spec before shipping to the public 14:15:43 https://w3c.github.io/payment-handler/ 14:15:50 https://play.google.com/store/apps/details?id=com.chrome.canary&hl=en 14:16:03 IJ: How is display of wallet granularity going? 14:16:18 rouslan: We are striving to show one line per app in Chrome on Android 14:16:26 ..have not yet figured out how to do this on desktop 14:16:44 ...we are working to ship PR API in milestone 60 on desktop 14:16:52 ...we are not yet at the stage of implementing payment handler on desktop 14:17:12 https://github.com/w3c/payment-handler/issues/129 14:19:47 IJ: Have you seen maplike in the wild? 14:20:11 Rouslan: I have not. I understand Marcos' point that it will be easier for spec authors to reference those objects, but I'm not aware of any impelmentations. 14:20:40 ...from the standpoint of web developers, nothing should change payment handler API functionality 14:20:42 IJ: Agreed. 14:21:07 topic: issue 168 14:21:07 https://github.com/w3c/payment-handler/issues/168 14:21:19 q+ 14:21:22 ack rouslan 14:21:40 rouslan: +1 to that comment....gogerald is the implementer who is building this 14:21:51 ...found a bug in the spec 14:24:15 topic: Issue 166 (editorial) 14:24:15 https://github.com/w3c/payment-handler/issues/166 14:24:50 ACTION: Ian to do a pull request to remove out of date URL from the example 14:24:55 IJ: the out of date URL is https://w3c.github.io/webpayments-payment-apps-api/#sec-app-response 14:25:12 Topic: Issue 169 14:25:12 https://github.com/w3c/payment-handler/issues/169 14:25:14 q+ 14:25:38 IJ: This is in section 8 14:25:40 ack rous 14:26:03 rouslan: I think that the engineers who fix up the open window algo text will also encounter this and should incorporate this in the algo 14:27:10 topic: Issue 117 14:27:10 https://github.com/w3c/payment-handler/issues/117 14:27:37 https://github.com/w3c/payment-handler/issues/117#issuecomment-289162845 14:28:12 IJ: summary - pass on an abort() event from the merchant to the payment app, to be handled as appropriate for the payment method and status 14:28:18 q+ 14:29:35 ack rous 14:29:42 IJ: I wanted to review Matt's comment here 14:30:02 rouslan: Let's not introduce new states that are payment app specific. They are private to the payment app and may not align with the browser's state machine 14:30:36 ..I think the simplest / cleanest API would be to give the abort event to the payment app service worker, that replies true or false and it's up to the service worker implementation to decide whether true or false 14:30:39 q+ 14:30:46 ack me 14:31:45 IJ: IS there a place for a status code or message? 14:31:57 q+ 14:32:05 ..e.g., "payment has already been processed" 14:32:06 ack sly 14:32:08 ack aly 14:32:25 alyver: How far do we want to go with this? I agree with Rouslan that the response should be true/false 14:32:53 ...what about case where payment method is push, and the payment app immediately refunds the transaction 14:33:04 ...user might see a "pending" thing that has not yet been resolved. 14:33:23 ..so there MIGHT be a case for a message, but it feels like an edge case, and I think that a simple true/false is sufficient for most use cases 14:33:43 rouslan: I think true/false is sufficient; no need for code. 14:33:57 ...it wouldn't make sense from the user interaction standpoint 14:34:15 ..if the site tries to abort a payment request in progress (e.g., because concert tickets no longer available) 14:35:14 ...I don't think more information from the payment app will be useful from the user interaction standpoint. 14:36:07 q+ 14:36:11 IJ: What does true mean? 14:36:12 ack rouslan 14:36:22 rouslan: It means that the payment has been ABORTED as requested by the web site 14:36:34 ...that means that the show() promise will not be resolved 14:36:49 ...whereas false means the payment was not aborted (per the site's wishes) for some unknown reason 14:37:29 IJ: Are there any changes to PR API required if we support abort() in payment handler? 14:37:32 rouslan: No. 14:38:26 IJ: Does this user experience happen in the world today in any transactions? 14:39:11 ...can this happen on the web today? 14:40:15 alyver: This concept of abort doesn't really exist on the web today 14:41:44 ...or maybe the equivalent is during a redirect to something like paypal 14:43:06 IJ: Could we highlight a new benefit of payment apps like "can do immediate refunds"? 14:43:15 alyver: I'm not sure we should recommend that functionality. 14:44:37 ...the goal of payment request is making capture easier...but not focused on voids and refunds 14:45:01 ...if a transaction has already been done, there are other implications to the merchant that they would need to be aware of 14:45:25 ...e.g., there might be fees charged on the transaction..opens up a can of worms 14:46:09 q? 14:46:42 IJ: Rouslan, would you be interested in adding an abort() event to the spec in a pull request 14:46:58 rouslan: I think it should be optional; don't want to initiate the pull request. Happy to review it. 14:48:06 RRSAGENT, make minutes 14:48:06 I have made the request to generate http://www.w3.org/2017/06/06-apps-minutes.html Ian 14:48:09 RRSAGENT, set logs public 14:48:43 q+ 14:48:52 ack rouslan 14:49:10 Topic: Experimentation 14:49:29 rouslan: Canary on Android will be available soon with near full functionality and so please experiment and get back to us! 14:49:30 Thanks Rouslan - will try to get the team here to experiment. 14:49:47 ACTION: Ian to alert the WPWG to this and try to muster some implementation experience 14:50:16 Topic: Issue 157 14:50:17 https://github.com/w3c/payment-handler/issues/157 14:50:49 IJ: Is that part of your implementation experience? 14:50:56 rouslan: Not yet...we need to clear up in the spec first 14:51:30 Rouslan: I will do a PR for this 14:52:16 IJ: What is your expectation about implementing before putting text in the spec? 14:54:13 IJ: what if you do a pull request and then say you are going to implement and may update the PR (and not to merge until you have)? 14:54:16 rouslan: +1 14:55:01 For each resulting payment handler, if payment method specific capabilities supplied by the payment handler match those provided by data, the payment handler matches. 14:57:49 topic: Next meeting 14:58:09 Proposed 20 June 14:58:16 rouslan: +1 14:58:20 IJ: Any regrets? 14:58:29 RESOLVED: Next meeting 20 June 14:58:39 RRSAgent, make minutes 14:58:39 I have made the request to generate http://www.w3.org/2017/06/06-apps-minutes.html Ian 14:58:49 RRSAgent, set logs public 15:14:26 alyver has joined #apps 15:19:40 alyver has joined #apps 15:33:38 alyver has left #apps 17:09:55 Zakim has left #apps 17:53:51 cweiss has joined #apps