14:00:37 RRSAgent has joined #apps 14:00:37 logging to http://www.w3.org/2017/07/25-apps-irc 14:01:05 Meeting: Payment Apps Task Force 14:01:08 Chair: Ian 14:01:10 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0049.html 14:03:31 present+ Ian 14:03:32 present+ Ken 14:03:41 cweiss has joined #apps 14:04:16 Ken has joined #apps 14:09:47 rouslan has joined #apps 14:10:29 present+ Rouslan 14:10:50 Topic: Next meeting: 8 August 14:11:08 => https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0049.html 14:11:43 Topic: Removing wallets proposal 14:11:47 IJ: I reviewed, Marcos reviewed 14:11:53 Rouslan: I have not reviewed 14:16:50 present+ Ganggui 14:16:55 ganggui has joined #apps 14:17:29 q+ 14:17:57 IJ: Not clear to me that we should pursue this if there are no implementations of containers 14:17:59 ack rouslan 14:18:07 rouslan: Here's how we are rendering service workers todya. 14:18:19 ..a payment app can have multiple service workers. We would show each one. 14:18:34 ...so technically we would support multiple containers (through multiple service workers) 14:18:53 ...technically our API supports these containers inherently. 14:19:31 IJ: In the case of multiple service workers, how do you handle events? 14:20:03 ...how does it work? Does the spec need to say anything? 14:20:11 rouslan: I think that is out of scope for the spec. 14:20:33 ..the browser has a list of service workers and sends the events to each, collects the responses, and shows UI. 14:22:46 IJ: In the case of multiple service workers, does only one get the event on user selection? 14:22:53 Rouslan: Yes. 14:23:21 ..there may be some internal code that needs to figure things out based on the data received 14:27:04 IJ: Should we add a Note like "Some payment app providers may wish to offer users multiple "wallets" for the same domain. This specification does not define features to do so, but developers may use subdomains or multiple service worker scopes." 14:27:17 s/domain/web origin/ 14:27:24 +1 14:28:03 IJ: Anyone else want to review the PR?> 14:28:05 [Silence] 14:28:28 Proposed: To merge AHB's pull request ( https://github.com/w3c/payment-handler/pull/188 ) then add a sentence about achieving wallets through other means. 14:28:32 +1 14:29:06 SO RESOLVED 14:29:36 ACTION: Ian to write a PR to add a sentence about wallets 14:29:44 Topic: Default Instrument 14:29:54 Adrian wrote a proposal: 14:29:54 https://github.com/w3c/payment-handler/issues/173#issuecomment-316978011 14:29:54 Adrian and I discussed, then I fleshed out the user scenarios and how they work 14:29:54 with the proposal: 14:29:54 https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373 14:29:55 This also relates to issue 178, and where information comes from for icons and labels: 14:29:57 https://github.com/w3c/payment-handler/issues/178 14:29:59 \ 14:30:07 IJ: Did anyone review AHB's proposal? 14:31:04 https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373 14:32:24 q+ 14:32:56 ack rouslan 14:33:12 IJ: I think AHB wanted to ensure the payment app has context and selected instruments. 14:33:31 rouslan: I have some concerns about sending displayed instruments to the payment app 14:33:41 present+ MattS 14:34:14 MattS has joined #apps 14:34:28 https://github.com/w3c/payment-handler/issues/173#issuecomment-316978011 14:34:59 https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373 14:36:52 IJ: AHB's proposal also talks about defaults, and needs more work on interaction between browser and payment app defaults 14:37:10 rouslan: I think the proposal needs more work; I don't think passing displayed instruments will be valuable. I suggest we take to github 14:37:30 IJ: +1 that we need more input on github 14:37:48 topic: Pull request 170 (re: canMakePaymentEvent and abortPaymentEvent). Are we ready to merge? 14:37:53 https://github.com/w3c/payment-handler/pull/170 14:38:03 q+ 14:38:06 IJ: Are we ready to merge this? 14:38:08 ack rouslan 14:38:56 Rouslan: I am satisfied with the proposal except it needs to be tidied and links fixed. 14:39:23 ...other than that, I think the patch looks good. We have started implementation and have defined the 2 events 14:39:39 https://github.com/w3c/payment-handler/blob/gh-pages/tidyconfig.txt 14:39:56 IJ: In a directory with index.html you would do this: tidy -config tidyconfig.txt -o index.html index.html 14:40:11 (I am using tidy 5.4.0) 14:41:03 rouslan: I will work on this on Friday 14:41:40 IJ: Once merged I think that lets us close issues 157, 117 14:41:55 https://github.com/w3c/payment-handler/issues/157 14:42:13 https://github.com/w3c/payment-handler/issues/117 14:42:24 IJ: Is the "turning off" feature implemented as well? 14:42:33 rouslan: Yes, for android payment apps. 14:42:41 ...we plan to implement for web apps 14:43:03 IJ: You have a picture of the user experience? 14:43:26 rouslan: In Chrome's incognito (private browsing) mode, the payment events don't go to the apps, they immediately return TRUE 14:43:58 ...once user confirms payment, before going into the payment app, we show a standard chrome dialog that says "by invoking this payment app you are exiting private browsing mode, please confirm this action" 14:44:34 ...this is the same way we handle launch of, say, youtube app, when invoked from incognito mode 14:45:23 Topic: Issue 116 14:45:47 https://github.com/w3c/payment-handler/issues/116#issuecomment-292183832 14:45:52 https://github.com/w3c/payment-handler/issues/116#issuecomment-316971765 14:46:53 ( The user agent MUST favor user-side order preferences (based on user configuration or behavior) over any other order preferences. 14:47:48 Second proposal: "The user agent MUST display matching payment handlers that correspond to the supported payment methods provided by the payee." 14:48:17 IJ: "display" is too strong 14:48:26 ...previously we said something like "make available" 14:49:21 +1 14:49:25 IJ: counter proposal is: "The user agent MUST make available to the user matching payment handlers that correspond to the supported payment methods provided by the payee. 14:49:54 q+ 14:49:59 IJ: What can the user do today? 14:50:03 ack rouslan 14:50:16 rouslan: Currently we respect user preferences and the user preferences are based on behavior 14:50:27 ...we sort payment apps by how recently the payment app was used or installed 14:50:44 ...and how many times the payment app has been used. We combine the two bits of information ("frecency") 14:51:03 ..beyond that, we don't really take merchant-preferred ordering into account, except when it comes to basic card 14:51:32 ..when the user needs to add a new card (through our UI) we show a list of icons of networks, and that list we show in the order specified by the merchant since we have no other signals of user preferences 14:52:12 ..we also take into account the "quality" of the payment app, e.g., if the payment app does not have an icon, we sort it lower 14:52:36 ..in the case of service-worker based payment apps, we must display the origin of the service worker (the only reliable way to identify where web-based payment apps come from) 14:53:10 ...we have made a decision that if a payment app does not have a label or icon, we will (1) sort it lower and (2) display the app's origin 14:53:50 ...in case of Android apps, they don't inherently have an origin 14:54:00 ...nobody on mobile devices knows package names of apps 14:54:21 ...indeed, if you look at package names of widely used payment apps, you would see they are not well-suited for display to the user 14:54:55 ..what we do for those apps, we allow "no icon", but if there is also "no label" then we don't show the app at all. That might contradict the three bullets 14:55:19 https://w3c.github.io/payment-handler/#instrument-display-ordering 14:56:28 IJ: I thought we had language saying that security issues could affect the display 14:57:01 IJ: I don't see it and think it needs to be added back. 14:57:04 +1 14:57:13 ...that the user agent has some flexibility to take into account security. 14:57:23 ...but should inform the user 14:58:12 ...should the security check mostly happen "at registration" or could it be relevant at any time? 14:58:39 rouslan: I wouldn't overly restrict since we don't know 14:58:57 Summary: 14:59:07 - Adopt mostly Ken's proposal 14:59:13 - But change "display" to "make available" 14:59:19 - Add back security mention. 14:59:39 IJ: I will add proposal to the GitHub list 14:59:46 Ken: Please add to next agenda 14:59:49 IJ: That's in 2 weeks 14:59:59 q+ 15:00:33 q- 15:00:39 q+ to ask about how this wording gets 15:00:44 ack MattS 15:00:44 MattS, you wanted to ask about how this wording gets 15:01:00 MattS: My question is not related to the wording but to the placement of the wording in the spec. 15:01:21 ...at the moment this is going into the payment handler spec...but it doesn't tell the user agent what to do around payment methods 15:01:40 ...my understanding about the chrome implementation is that they have a situation where the Android Pay application appears at the top of the list 15:01:49 ...that's not strictly speaking a "payment handler" 15:02:04 ...I think the intention of our wording is that it be at the level of payment request API (not payment handler) 15:02:21 q? 15:02:29 q+ 15:02:37 IJ: Please add that to the issue => https://github.com/w3c/payment-handler/issues/116 15:02:38 ack rouslan 15:03:25 rouslan: I agree with Matt's observation 15:03:44 ...I note that Android pay is "before" browser-stored cards (for security reasons) 15:03:50 cweiss has joined #apps 15:04:34 mattS: Is that true, even if user always chooses card? 15:05:00 rouslan: Yes, good point. We have several categories of sorting preference. We essentially prioritize them. We prioritize security more than repeated usage of a repeated payment method 15:05:35 MattS: I can see a rationale for that between card payments ... but when we have more payment methods trying to distinguish themselves on security, I think we won't necessarily have the same obvious situation 15:05:53 frecency 15:06:03 https://en.wikipedia.org/wiki/Frecency 15:06:22 https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Frecency_algorithm 15:06:30 Ian has left #apps 15:06:34 Ian has joined #apps 15:06:57 RRSAGENT, make minutes 15:06:57 I have made the request to generate http://www.w3.org/2017/07/25-apps-minutes.html Ian 15:07:00 RRSAGENT, set logs public 15:28:33 RRSAGENT, bye 15:28:33 I see 1 open action item saved in http://www.w3.org/2017/07/25-apps-actions.rdf : 15:28:33 ACTION: Ian to write a PR to add a sentence about wallets [1] 15:28:33 recorded in http://www.w3.org/2017/07/25-apps-irc#T14-29-36 15:28:34 zakim, bye 15:28:34 leaving. As of this point the attendees have been Ian, Ken, Rouslan, Ganggui, MattS 15:28:34 Zakim has left #apps