14:58:45 RRSAgent has joined #apps 14:58:45 logging to http://www.w3.org/2017/02/07-apps-irc 14:59:25 Meeting: Payment Apps Task Force 14:59:27 pascal_bazin has joined #apps 14:59:27 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0006.html 14:59:31 Chair: Ian 14:59:33 Scribe: Ian 14:59:40 Ian has changed the topic to: 7 Feb agenda => https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0006.html 15:00:50 regrets+ alyver 15:00:53 present+ 15:01:24 jnormore has joined #apps 15:01:57 present+ 15:02:01 present+ Pascal 15:02:46 rouslan has joined #apps 15:02:53 present+ 15:02:54 present+ jnormore 15:03:36 conorhwp has joined #apps 15:03:38 present+ rouslan 15:03:42 Apologies for late arrival. 15:04:02 present+ Conor 15:06:32 present+ adrianhb 15:06:43 => https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0006.html 15:06:53 "Proposal" => https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:08:38 IJ: Any status update from Andre on his action? 15:08:47 jnormore: No; I'll ask him. 15:08:55 AdrianHB: I plan to work with Andre on this this week. 15:09:17 There is some useful discussion here: https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-277813048 15:13:22 IJ: anything strike anybody wrong or incomplete? 15:13:24 [Silence] 15:13:47 Topic: Issue 99 15:15:03 AdamR: Some info in the payment request data is specific to payment apps and not from the payment request (e.g., optionID option selected by the user, and perhaps merchant origin) 15:15:24 ...so the data we send to the payment app is not strictly a subset. 15:16:22 q+ 15:16:30 IJ: Any implementation experience? 15:16:31 ack Adr 15:17:44 AdrianHB: We discussed reusing payment request back in SFO ftf meeting 15:18:31 ...I think that right now purchase and payment information are tightly coupled 15:18:54 q+ 15:19:43 AdrianHB: If we reuse the payment request object in the payment app we want two things: 15:19:56 a) Strip out data to only those payment methods supported. 15:20:03 ..that's doable by the user agent 15:20:29 b) There is also information relevant to the payment app that is not relevant to the merchant. 15:20:41 ack ad 15:21:14 adamR: I don't think that teasing apart purchase from payment would make this any easier. It would be dangerous to have information populated by the merchant (e.g., origin) 15:22:03 ...Marcos' comments relate to reusing form fill (regarding data collection) 15:22:26 ...I am pushing back against that part of the proposal because I think it is inadequate to the task 15:22:55 AdrianHB: We could change the shape of payment request (on the PR API side) to make it more reusable. 15:23:03 ..with merchant-specific parts and app-specific parts, but reusable 15:23:14 ...regarding reuse of form fill; I am not getting into that debate. 15:23:38 ...the group has already resolved to gather data in the way that PR API currently does 15:25:35 adamR: What may be useful here is a statement from the chairs that the way that data is gathered has been defined. 15:26:32 ACTION: AdrianHB to reread the issue, consolidate the topics, and report on the state of relevant decisions by the group. 15:29:03 IJ: PR API does not talk about payment apps, so even though we could modify PR API 15:29:23 ...to include data specific to payment apps, that would break that wall 15:29:45 adamR: Should we, in PR API, add an ORIGIN field to the payment request object to convey the origin to the payment app. 15:30:01 ...but that would not be available to the merchant (so may be awkward) 15:30:13 rouslan: It's true that payment request object should not have an origin on it 15:30:21 q+ 15:30:39 ...second, I think we can still pass the payment request data structure unadulterated to the payment app if we use composition 15:30:55 ..we can have a payment request container object that has original payment request object and payment app specific data 15:31:02 adamR: That would be fine. 15:31:21 AdrianHB: But we still need to strip out some information (e.g., "requestShipping" flag) 15:31:45 IJ: How complex to strip out the data? 15:31:47 q- 15:32:00 Rouslan: Currently what we do with payment apps: 15:32:17 * We take the payment request object that has payment method data, modifiers, shipping options, and transaction details. 15:32:58 * We take part of that data and send to the payment app: method names supported by the payment app and merchant accepted + their method-specific data + shopping cart details including modifiers relevant to the payment method intersection 15:33:05 ...so we do strip information out 15:34:14 ...it would be great to reuse the payment request object with irrelevant data stripped, composed with other data from the user agent specific for the payment (e.g., origin, option id) 15:34:38 q+ to note that the PaymentRequest inteferface is completely inappropriate for sending to apps 15:35:05 https://w3c.github.io/browser-payment-api/#paymentrequest-interface 15:35:25 ...that's not the cleanest approach in that many fields of the object will be empty. 15:35:38 ...so I think I would favor a new type of object 15:35:55 adamR: That's what I would think 15:36:07 ack AdrianHB 15:36:07 AdrianHB, you wanted to note that the PaymentRequest inteferface is completely inappropriate for sending to apps 15:36:28 AdrianHB: I agree. If you look at the payment request interface...it's the wrong thing to send to a payment app. 15:36:50 ..the only way we could make this worth is if PR API changed 15:37:51 ...e.g., if you passed the API a container object... 15:38:21 AdrianHB: I have a proposal! 15:38:59 q+ 15:39:07 AdrianHB: ...we don't think we can reuse payment request object unless PR API changes. He may disagree with that. 15:39:22 ..but if he agrees, then he may need to convince people to change how PR API works 15:39:37 rouslan: I'm not sure how much we would change to make payment request object more usable. 15:39:43 ...I think this is unlikely 15:39:51 ack rou 15:39:59 present+ Ken 15:40:58 ACTION: AdrianHB to propose to Marcos that we go forward with the "new object" approach, with rationale, and follow the discussion. 15:41:29 IJ: Are people still open to reusing the object if it can be done in a way with minimal disruption to PR API AND without a lot of empty data fields? 15:41:30 +1 15:41:53 IJ: I don't hear anybody saying "reuse is bad" only...we think there's a cost to revamping PR API. 15:42:05 ..and as-is doesn't seem to lend itself easily to reuse in payment apps 15:42:27 q? 15:42:36 Topic: Opening Windows 15:42:55 https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0008.html 15:42:58 IJ wrote: 15:43:00 q+ 15:43:02 It seems that we need: 15:43:02 * To define the openClientWindow() method (somewhere; maybe in 10.4) 15:43:02 * To review the text in section 10.4. Some of the cautionary statements there could be deleted if we have 15:43:02 a method that is known to do the right thing on a variety of devices. 15:43:03 * Review example 3 which mentions clients.OpenWindow (but see below regarding Example 3) 15:43:16 IJ: and Marcos volunteered; and I suggested he work with Tommy (he said cool) 15:43:20 ack Adam 15:43:38 adamR: +1 to that path forward. I agree with the approach being proposed. 15:43:45 q? 15:43:46 +1 to openClientWindow method on event. Yay! 15:44:01 Ian: Great, I will return to this topic in a couple of weeks to check in on their proposal 15:44:45 https://github.com/w3c/webpayments-payment-apps-api/issues/97 15:44:51 is probabaly best issue 15:45:19 topic: Recommended payment apps 15:46:41 q+ to mention how permissions API could be used by merchants to test for app with cooperation of payment app 15:47:19 q+ to talk about native 15:47:24 q? 15:47:41 IJ: Question - what should we support (e.g., from "nothing" to "merchant expressed preference as a list of IDs") 15:47:50 rouslan: Origin is sufficient for both web and native apps. 15:48:04 ...so if we do this, can be a list of origins 15:48:33 q+ 15:50:15 rouslan: I am ok with limiting what the merchant provides to be a list of payment app identifiers..and those identifiers should have the same form for both native and web 15:50:21 ack rou 15:50:21 rouslan, you wanted to talk about native 15:50:27 ack AdrianHB 15:50:27 AdrianHB, you wanted to mention how permissions API could be used by merchants to test for app with cooperation of payment app 15:50:38 AdrianHB: I think we are still figuring out whether the identifiers are origins or something else 15:51:19 ..my argument against recommended payment apps in v1 is that we can achieve much of what we want via the permissions model 15:51:36 q+ 15:52:23 AdrianHB: Merchants and payment app providers can work together to detect where permissions have been granted 15:52:53 ...and payment apps can communicate information to the parent merchant, allowing the merchant to tailor the user experience 15:52:54 ack adamR 15:53:41 adamR: What AHB described may be ok for a workaround. But I think recommended payment apps serve a couple of purposes (1) merchant promotion of payment types in the flow....I don't think this is critical for v1 of the API (2) Building out the ecosystem, which I think we cannot forego in version 1 15:53:54 ....so I think we need something to help bootstrap the ecosystem 15:54:13 q+ to talk about plausibility 15:54:15 ...if we can demonstrate that permissions suffice and are easy enough to use for merchants, that's fine 15:54:38 q+ to say that recommended apps can be added later easily 15:54:50 ...but I'm afraid that it probably won't be and we need something to raise awareness about payment apps 15:55:01 ...some affordance, even if they don't appear alongside registered things 15:55:08 ack jnor 15:55:13 jnormore: Three things! 15:55:33 (1) From a merchant perspective I'd rather have support for recommendations with less power than no recommendations at all 15:56:16 (2) What's important is when no payment apps are installed. (Prioritization of payment apps is not a priority issue; I agree with AdamR) 15:56:32 (3) Agree that the approach AHB cites is conceivable but also complex and may make life hard for smaller m erchants 15:56:39 q? 15:56:42 ack rous 15:56:42 rouslan, you wanted to talk about plausibility 15:56:43 Jason said something important that I didn’t: the key thing we need to avoid here is a no-match situation. Even if we invoke the installation only in these cases, it helps the situation a lot. 15:56:45 zakim, close the queue 15:56:45 ok, Ian, the speaker queue is closed 15:57:04 rouslan: In our chats with payment app distributors, they said they have relationships with merchants, and they put iframes in pages. 15:57:21 ...payment app providers want to give users a very easy way to install a payment app 15:57:41 ..so they want support for bootstrapping 15:57:53 q? 15:58:17 IJ: If bootstrapping is important, then it seems that "highlighting registered" is not an important thing 15:58:19 ack AdrianHB 15:58:19 AdrianHB, you wanted to say that recommended apps can be added later easily 15:58:32 AdrianHB: I think we have a lot of assumptions about market dynamics where we are speculating. 15:58:45 ...I think recommended payment apps is a feature we can easily add without breaking the API 15:58:53 ...it's an additive feature to payment request 15:59:30 ...I would encourage us to take a step back and I think bootstrapping will not be as big a problem as we think 15:59:56 ...if our concern is bootstrapping third party payment apps, i think that's different 16:00:06 Topic: next meeting 16:00:08 14 Feb 16:00:24 Regrets for next week due to travel. 16:01:18 IJ: Any interest in whitelisting payment apps? We may not want that and browser vendors may have no interest 16:01:43 RRSAgent, make minutes 16:01:43 I have made the request to generate http://www.w3.org/2017/02/07-apps-minutes.html Ian 16:01:53 RRSAgent, set logs public 16:02:17 AdrianHB: It may also be possible to do this declaratively, outside of the API 16:02:20 RRSAgent, make minutes 16:02:20 I have made the request to generate http://www.w3.org/2017/02/07-apps-minutes.html Ian 16:03:39 RRSAgent, set logs public