14:14:47 RRSAgent has joined #apps 14:14:47 logging to http://www.w3.org/2017/02/14-apps-irc 14:57:37 frank has joined #apps 15:00:35 Meeting: Payment Apps Task Force 15:00:37 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0024.html 15:00:39 Chair: Ian 15:01:24 present+ 15:02:18 pascal_bazin has joined #apps 15:02:40 present+ Frank 15:02:44 present+ Mathieu 15:02:47 present+ Pascal 15:03:34 present+ 15:04:08 alyver has joined #apps 15:04:19 mathp has joined #apps 15:04:22 rouslan has joined #apps 15:04:30 present+ 15:04:51 present+ alyver 15:05:02 agenda => https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0024.html 15:05:19 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:05:54 topic: Issue 99 - reuse payment request objects or create new ones? 15:06:00 IJ: Consensus to use new request/response objects for payment apps 15:06:10 https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0016.html 15:06:50 IJ: Are we close to payment request response? Do we need to make changes? 15:07:07 adamr: I haven't looked specifically to see where variations are. 15:07:33 IJ: Opportunities for better alignmetn? 15:07:37 present+ Rouslan 15:08:27 rouslan: I think Marcos prefers dictionaries over interfaces 15:08:33 ..and dictionaries are composable 15:08:51 ...so I think the payment app dictionary should include the relevant PR fields 15:08:57 ....(and not things like "options") 15:09:05 ...and in addition, we will need some things not in payment request like origin 15:09:27 https://w3c.github.io/webpayments-payment-apps-api/#sec-app-request 15:09:56 (1) Add “paymentRequestId”; (2) change “total” to “details” 15:10:23 PROPOSED: Close issue 99 by keeping a new object in payment app API 15:10:44 adamR: We need to add paymentRequestID and we need to copy the details 15:10:59 q+ to say total should still be there, but line items should be added 15:11:04 ack rouslan 15:11:04 rouslan, you wanted to say total should still be there, but line items should be added 15:11:20 rouslan: Total should still be there, add line items 15:11:34 ...I think it's useful for the payment app to know both 15:11:51 https://w3c.github.io/browser-payment-api/#dom-paymentdetails 15:11:52 adamR: The current structure of payment details includes total 15:12:01 ...I don't think we should factor out the total 15:12:09 rouslan: +1 15:12:51 ACTION: AdamR to write a pull request to align the payment app spec with payment request objects 15:14:04 AdamR: While we could make some cases by refactoring some things in Payment Request API, I think that's overkill 15:14:14 ...so let's reuse structures and names 15:14:41 (Seeking support for proposed resolution to 99) 15:15:16 +1 15:15:32 topic: Opening Windows (73, 97( 15:15:50 I have no updates on action from Marcos/Tommy 15:16:07 Ian: I will follow up on the time frame for that. 15:16:21 ...but I think we have consensus 15:16:28 topic: Filters/capabilities 15:16:38 See IJ proposal 15:16:38 https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278754087 15:17:50 q+ to talk about the proposals 15:17:56 q+ 15:18:29 ack rouslan 15:18:29 rouslan, you wanted to talk about the proposals 15:18:56 rouslan: I think that Adam's proposal has some good properties; I suggest we just use that. 15:19:30 ...let's talk about Marcos' comments about web apps having same power as native apps 15:20:04 adamr: The one diff between Rouslan/my proposal was how missing properties are handled; but otherwise the proposals were identical 15:21:32 IJ: There are several things to write up: 15:21:36 The capability syntax and a matching algorithm. 15:21:36 How the constructor changes to allow the merchant 15:21:36 to provide capability matching data. 15:21:36 Where in the algorithms to mention application of the 15:21:36 capability matching algorithm 15:21:41 * How payment apps provide the data 15:23:14 ACTION: AdamR to incorporate capabilities in his pull request on granular data get/set 15:23:25 ACTION: Rouslan to work on text that would go in payment request API regarding capabilities 15:23:39 https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278851432 15:25:36 q+ 15:26:59 q- 15:27:36 ack adam 15:27:55 adamR: canHandle() is gone since we are no longer doing in-app filtering 15:28:28 ...we also should not revisit canMakePayment decision that "up to browser" 15:28:49 ...also +1 to proposal from IJ that says "simple checking before app launched; powerful checking after app launched" 15:29:21 IJ: I suggest then that: 15:29:37 1) PROPOSED: Adopt https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278754087 15:30:30 +1 15:30:52 +1 15:31:07 +1 15:31:09 (No objections) 15:31:11 SO RESOLVED 15:31:22 2) Ian will update the issue with pointers to what happens next (ACTIONS, etc.) 15:31:38 Topic: issue 95 - setting payment information 15:31:59 (We resolved early) 15:32:19 Topic: Recommended payment apps (74, 79) 15:32:29 Proposal from IJ 15:32:30 https://github.com/w3c/webpayments-payment-apps-api/issues/74#issuecomment-278340715 15:33:15 q+ 15:33:28 IJ: Proposal is basically (1) remove from payment app API and (2) continue to work on either as good practice or as a separate layer (or both) 15:33:43 alyver: Shopify would like the group to continue to work on payment apps 15:33:57 ...there are two situations to look at: 15:34:02 ...recommenation of an app already registered 15:34:16 (e.g., where merchant preference can be reflected) 15:34:22 ...recommendation of an app not yet registered 15:34:30 (where bootstrapping the ecosystem is valuable) 15:34:50 ...so there are at least two topics (1) expression of merchant preferences (2) bootstrapping the ecosystem 15:35:18 alyver: One suggestion in the proposal was to leave for later discussion...but I have concerns about the impact on payment API, and if we leave too long there will be implementations that are difficult to change 15:35:27 q? 15:35:29 ack al 15:38:32 [IJ summarizes state of discussions around problem statements of bootstrapping the ecosystem, and expression of merchant prefs] 15:39:30 (No takers on actions) 15:39:50 adamR: I haven't heard anyone describe what the user experience will be when someone recommends an app that has not been installed. 15:39:59 ...it would help if someone wrote down that user experience. 15:40:16 q+ 15:41:38 Ken: Relationships with card members, merchants are very important to us 15:42:45 ..this is an important/sensitive topic that demands caution. 15:42:48 ack alyver 15:43:28 alyver: Regarding user experience, the original expectation for recommended (unregistered) payment apps was on-the-fly registration 15:43:37 ...or at least take the user to a site to install/register the payment app 15:43:57 ...there were security concerns raised about sending customers to malicious sites 15:44:34 ...Tommy's proposal ( https://github.com/w3c/webpayments-payment-apps-api/issues/74#issuecomment-278941318 ) is also interesting in that apps are recommended only when payment request API has failed 15:44:36 q+ 15:44:46 ...but that doesn't address the merchant preference piece 15:44:56 q+ Ken 15:45:00 ack ada 15:45:10 adamR: Regarding Tommy's proposal, that does not need API support 15:46:27 ...we should tease apart the two experiences of "preference" and "recovery" 15:46:29 ack k 15:46:45 Ken: Here are two use cases to consider 15:47:14 1) Merchant does not accept card payments and has no existing contractual relationship regarding recommendations; I can see this feature as valuable to merchants 15:48:18 2) Merchant has contractual obligations and recommendations might present a conflict 15:48:44 q+ 15:49:48 ack aly 15:50:02 alyver: Merchants choose (or not) to surface recommendations. 15:51:39 I would be happy to discuss offline to understand your use cases further 15:51:42 Ken: I can do some more work to outline scenarios that would likely not create conflicts. 15:53:14 ...in physical stores a scenario that is analogous that is not desirable from our perspective is merchant guidance to use alternative payment methods. 15:54:39 (let's move on) 15:55:49 topic: Issue 95 - setting/getting information 15:55:55 damR to write a proposal for setting payment method information at finer grain than setManifest. 15:56:01 ...The proposal will take into account Mathieu's desire for easy reset. 15:56:30 Adamr: It will look a lot like what I proposed already, but I want to do some thinking about how to fit in something like a "wallet" between app and instrument levels 15:56:38 ...I intend to roll that layer into the proposal 15:56:41 IJ: Time frame? 15:56:48 AdamR: This week (I hope); put on agenda next week 15:57:12 ..related is the issue of 69/70/90 15:57:19 ....we will need to give names to options 15:57:31 ...I've heard that payment apps want to render card art for cards 15:57:38 ...this means we'll need icons as well 15:58:05 ...the app manifest files are overkill for our payment option level needs 15:58:30 ...using app manifest for credit card art is overkill since there is so much else that does not apply in those manifest files 15:58:50 ...we can discuss that in light of the forthcoming pull request 15:59:06 topic: Marcos seeking partner for writing up code 16:00:21 +q 16:00:24 ack pas 16:00:35 pascal_bazin: I am happy to work with Marcos on the coding 16:00:41 \o/ 16:00:57 ACTION: Ian to write to marcos, pascal, and tommy to see if three of them can get to work on that coding portion 16:01:06 Topic: next meeting 16:01:12 21 Feb 16:01:20 alyver has left #apps 16:01:30 RRSAgent, make minutes 16:01:30 I have made the request to generate http://www.w3.org/2017/02/14-apps-minutes.html Ian 16:01:34 RRSAgent, set logs public 17:47:01 rouslan has left #apps 18:16:42 Zakim has left #apps