14:00:08 RRSAgent has joined #apps 14:00:08 logging to http://www.w3.org/2017/08/29-apps-irc 14:00:14 Chair: Ian 14:00:18 Meeting: Payment Apps Task Force 14:00:40 alyver has joined #apps 14:00:57 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Aug/0019.html 14:01:24 present+ 14:01:29 present+ MattDeGanon 14:01:42 Topic: Introduction 14:02:24 rouslan has joined #apps 14:02:30 present+ Rouslan 14:02:42 present+ AdrianHB 14:02:44 present+ Frank 14:03:30 frank has joined #apps 14:04:20 deganon has joined #apps 14:04:39 IJ: Welcome Matt de Ganon, Capital One 14:05:09 Topic: Spec editing 14:05:38 https://w3c.github.io/payment-handler/ 14:05:51 present+ Ken 14:06:01 present+ alyver 14:07:14 PROPOSAL 14:07:14 PROPOSED: 14:07:14 * Pull out intro material into an explainer. 14:07:14 * Examples good 14:07:14 * Pull out algorithms and put them in branches; merge 14:07:15 them as there is consensus and tests. 14:07:17 Link to them via issues. 14:07:19 * Leave in modeling / interfaces (which editors can 14:07:21 evolve rapidly as needed, and which stabilizes naturally 14:07:23 over time.) 14:07:25 * Move dependencies toward the end (as in PR API now) 14:10:02 q+ 14:10:24 ack rouslan 14:10:29 rouslan: I think these are all good points. 14:10:43 ...they will make our life easier in the long term even if more difficult in the short term 14:11:43 ...I would prefer that we wait until Marcos is more fully onboard in this spec before we adopt those fully. 14:11:46 AdrianHB: +1 14:14:05 IJ: I am comfortable with this proposal (and also waiting for Marcos to be more involved) 14:14:23 AdrianHB: I am strongly opposed to removing some explanation from the text. 14:15:03 https://github.com/w3c/payment-handler/pulls 14:16:10 IJ: How should we proceed with existing pull requests? 14:16:28 AdrianHB: I think we should merge the ones we've been working on for a while and are comfortable with. We can make changes later 14:16:42 ...and as soon as Marcos is more involved, we will welcome the test writing expertise. 14:18:00 IJ: Should we pull out algos? 14:18:13 AdrianHB: Let's instead put issues in where they do not yet have tests. 14:18:17 +1 for markers 14:18:48 (IJ is likely to do a PR to move dependencies down) 14:18:56 Summarize: 14:19:08 * We look forward to marcos getting actively involved in this spec 14:19:17 * When he does we are open to making more changes to the spec and editorial process 14:19:38 * In the meantime, we would like to add issues to the spec where algorithms are not tested (rather than remove them) 14:19:45 * Ian plans to move dependencies down the page 14:20:00 * AdrianHB has expressed a strong preference to leave explanatory material in the overview 14:20:37 * We want to start the payment handler test repo and link to it from the spec 14:20:38 https://w3c.github.io/payment-request/ 14:21:00 ACTION: Rouslan to create https://w3c.github.io/payment-handler/ 14:21:12 ACTION: Ian to add test suite link to the respec 14:21:49 topic: AbortPaymentEvent 14:22:23 +1 14:22:25 https://github.com/w3c/payment-handler/pull/207 14:23:07 IJ: Is this implemented? 14:23:12 rouslan: We are currently implementing 14:23:20 ...so far no issues yet found in the algorithm. 14:23:52 IJ: Would you mind adding a note to the PR not to merge until you've reported on implementation experience 14:24:10 Topic: canMakePaymentEvent 14:25:21 q+ 14:25:34 IJ: How is the socialization of "static registration" going in Google? 14:25:37 Rouslan: So far no love 14:25:53 ...in order to resolve the issue, we've reached out to some others 14:26:14 ...regarding "static" v. "canMakePaymentEvent" 14:26:25 ..so It think we should not decide yet until we have more input. 14:26:51 IJ: AdrianHB has some thoughts on this 14:27:21 (Ian channels Adrian) 14:30:16 q+ 14:30:24 IJ: One thought is to not do filtering on capabilities by payment apps. This would let them, e.g., show up in the UI and allow users to add cards 14:30:27 ack rouslan 14:31:23 rouslan: For payment apps that support basic card, it makes sense to not show instruments that would otherwise be displayed (e.g., mozilla might do this) 14:31:35 ...I expect all payment apps will support adding instruments 14:32:24 ...regarding "abuse" it's not clear to me that it's a big deal because for URL-based payment methods, the manifest will enforce the relationship between app and URL. 14:34:41 adrianhb: I have to credit dave longley...if you are a payment app you want to appear as much as possible. So most payment apps are unlikely to opt out. 14:35:19 IJ: Frank, is that something you would validate? 14:35:23 Frank: Yes, probably we would not opt out 14:36:00 I agree with that statement as well. They will not want to filter themselves out unnecessarily. 14:37:01 MattDG: It's hard for me to conceive of a situation that applies directly to us, but considering the partnerships that are forming between a variety of players, there's so much calculus here, that to filter seems like it would be hard to anticipate what could be applied based on what the merchant accepts 14:38:43 q+ 14:38:56 IJ: I am hearing two points (1) whether a payment app CAN do something and (2) whether a payment app is INCLINED to do something 14:39:18 alyver: A merchant might be frustrated by a payment app that says it can do everything but that can't actually do it. 14:40:33 q+ 14:40:37 ack alyver 14:41:09 IJ: Payment app still gets merchant supplied capability to be able to do the right thing. Not sure how to avoid potential for frustration 100%. 14:41:35 q+ 14:41:39 q+ 14:41:41 alyver: It is still possible for a payment app to get data to do a debit payment even if merchant says they only accept credit. 14:41:43 ack rous 14:41:59 rouslan: I think for that use case, if the merchant has a preference for payment methods, they can use discounts. 14:42:06 Ken_ has joined #apps 14:42:38 ..on the topic of preventing bad behavior, we have found that dumb algorithms behave well if you have a lot of data. 14:43:48 ... I think that if the payment app misbehaves (e.g., sending something to the merchant that they have not asked for), the merchant will call paymentResponse.complete with FAIL flag, which will tell the user agent that the payment app has failed. This can be stored in a user profile, and if failures increase over time, I could imagine scenario where a user agent might be discouraged from showing constantly failing payment apps. These market mechanisms can help miti 14:43:48 gate the problem. 14:43:52 ack fr 14:44:32 frank: To Andre's scenario of just supporting debit card....the payment app would return card data, and the processing would not happen on the backend; that's not a payment app issue 14:44:42 AdrianHB has joined #apps 14:44:49 alyver: correct; I was thinking of other payment methods 14:44:56 ack m 14:44:59 ack de 14:45:37 MattDG: Agree with Frank re Andre's scenario; decline would happen 14:46:05 IJ: And that type of failure would not be capturable the way Rouslan described. 14:46:53 ...how fast are those things processed? 14:47:04 Rouslan: It could be fast enough in light of new APIs (re: processing) 14:47:17 rouslan: Merchant might authorize a transaction but not complete it for a day or two 14:47:29 q+ 14:47:33 ack deg 14:48:11 deganon: I can't think of a scenario where a payment instrument would be sent to merchant, initial auth goes to processor, either merchant or acquirer looks at the bin or the processing and detect incompatibility; that would happen within milliseconds 14:49:24 IJ: Let's keep thinking/discussing and leave this open for a couple of weeks and come back to it 14:49:36 Topic: Issue 173 14:49:49 https://github.com/w3c/payment-handler/issues/173 14:50:23 https://github.com/w3c/payment-handler/pull/206 14:53:40 https://github.com/w3c/payment-handler/pull/206/files 14:54:23 [IJ explains] 14:54:29 q+ 14:54:32 ack rouslan 14:54:55 rouslan: +1 to userHint; makes sense and solves our use case. 14:55:13 ...but Dave Longley has pointed out that this would not be useful when all instruments are shown 14:56:48 ...another approach is to enable user agents to compute a hint 14:57:32 ...Dave has proposed an ordering in the list of instruments. 14:57:36 ...I'm split between these two solutions 14:58:10 ...should the payment handler specify an order of instruments, or just a user hint? 14:59:09 q+ 14:59:34 IJ: Browser-determined hint does not satisfy "payment handler wants to provide the hint" 14:59:41 AdrianHB: I support payment handler determined hint 14:59:52 IJ: Also, calculating order is much more of a hammer. 15:00:12 AdrianHB: I am supportive any clarification about when the hint is used 15:00:14 ack rouslan 15:00:17 +1 15:00:23 +1 15:00:24 rouslan: I am convinced to go with userHint 15:01:21 q? 15:01:25 topic: next meeting 15:01:57 IJ: I will not be available 12 Sep 15:02:04 5th 15:02:05 No preference 15:02:12 Next meeting: 5 September 15:02:16 ..no meeting 12 September 15:02:21 RRSAGENT, make minutesw 15:02:21 I'm logging. I don't understand 'make minutesw', Ian. Try /msg RRSAgent help 15:02:22 RRSAGENT, make minutes 15:02:22 I have made the request to generate http://www.w3.org/2017/08/29-apps-minutes.html Ian 15:02:30 RRSAGENT, set logs public 15:06:03 alyver has joined #apps 15:10:38 cweiss has joined #apps 15:18:32 alyver has joined #apps 15:43:18 alyver has joined #apps 16:16:35 alyver has joined #apps 16:28:08 zakim, bye 16:28:08 leaving. As of this point the attendees have been Ian, MattDeGanon, Rouslan, AdrianHB, Frank, Ken, alyver 16:28:08 Zakim has left #apps 16:28:12 RRSAGENT, bye 16:28:12 I see 2 open action items saved in http://www.w3.org/2017/08/29-apps-actions.rdf : 16:28:12 ACTION: Rouslan to create https://w3c.github.io/payment-handler/ [1] 16:28:12 recorded in http://www.w3.org/2017/08/29-apps-irc#T14-21-00 16:28:12 ACTION: Ian to add test suite link to the respec [2] 16:28:12 recorded in http://www.w3.org/2017/08/29-apps-irc#T14-21-12