15:01:27 RRSAgent has joined #apps 15:01:27 logging to http://www.w3.org/2017/02/28-apps-irc 15:01:32 zakim, bye 15:01:33 leaving. As of this point the attendees have been Ian, Andre, Frank, Jake, Adam, AdrianHB, michiel, rouslan, Conor 15:01:33 Zakim has left #apps 15:01:34 Zakim has joined #apps 15:01:41 present+ Rouslan 15:01:44 present+ Ian 15:01:46 present+ Frank 15:01:48 present+ Conor 15:01:48 alyver has joined #apps 15:01:59 Meeting: Payment Apps Task Force 15:02:01 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0081.html 15:02:04 Chair: Ian 15:02:14 present+ alyver 15:02:38 present+ 15:02:52 present+ Pascal 15:03:04 => https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0081.html 15:03:11 Topic: Running summary 15:03:18 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:03:27 pascal_bazin has joined #apps 15:03:54 present+ Mathieu 15:04:24 IJ: Any comments? 15:04:57 IJ: Any volunteers to read it? 15:05:12 I volonter 15:05:25 mathp has joined #apps 15:05:40 sure 15:05:54 Two volunteers for next week: Frank, Pascal 15:06:26 conorhwp_ has joined #apps 15:06:27 Topic: AdamR's proposal 15:06:32 https://github.com/w3c/webpayments-payment-apps-api/commit/4430d10f1b0957196576b8018a095a4b5a26eb81 15:06:44 IJ: Next steps? 15:06:53 AdamR: I haven't seen support or opposition. 15:07:08 statement of support 15:07:25 +1 15:08:11 s/americanexpress/amex 15:10:19 AdamR: My proposal does not touch the request/response object. It assumes filters are going to come in. 15:10:33 ...I do have an outstanding todo for aligning names 15:10:44 present+ AdrianHB 15:11:52 ACTION: AdamR to flesh out his proposal to put in place text around procedures for using these IDL constructs 15:12:29 AdamR: Another thing that I would like to do or see done and relocating explanatory tex to appendix. 15:12:36 ...so examples and IDL are nearer the top. 15:12:45 ACTION: Ian to move explanation to the bottom 15:13:53 Topic: Status of code writing 15:14:12 AdamR: I spoke with Marcos last week. I plan to take some of his examples (finer grain) and integrating into my proposal 15:14:14 +1 15:14:49 IJ: What is status of Marcos/Tommy/Pascal conversation? 15:14:55 Pascal: We have not made progress yet. 15:16:14 IJ: Please keep us posted; will be good to have code in the spec 15:16:26 Pascal: What kind of code do you want? 15:16:37 https://github.com/w3c/payment-request-info 15:17:03 ---- 15:17:20 * Getting permission 15:17:20 * adding, removing, updating, payment methods 15:17:20 * handling .canMakePayment(), 15:17:20 * handling POSTing for payment (without a secure window). 15:17:22 * Getting the browser to open a secure window 15:17:24 * handling PaymentRequest .abort(), .updateWith(), and whatever else 15:17:26 PaymentRequest can throw at us. 15:17:28 * creating a PaymentResponse - and showing how it coordinates between 15:17:32 the secure window and merchant. 15:17:34 * Other critical things that I can't think of right now... Please add them!!! 15:17:36 --- 15:17:48 AdrianHB's list: 15:17:49 ==== 15:17:49 - Handles multiple payment methods: 15:17:49 o Basic-card payment. 15:17:49 o Web App payment (mine and tommy’s) 15:17:50 - Rendering UI for payment confirmation or cancelation 15:17:51 - Use of the manifest to create explicit choice 15:17:53 - Management of Payment request options by the merchant 15:17:55 - Feedback of the shipping options to alter the amount 15:17:57 - Use of the payment response details by the payment app 15:18:01 - Use of the payment response details by the merchant (for display) 15:18:03 - Registration and more around the service worker control 15:18:05 15:18:07 ==== 15:18:14 Pascal:I can gather what I have in small examples 15:18:29 ...can put that in once place and let editors put the code where it goes 15:18:47 q+ 15:18:54 ACTION: Pascal to gather example code; send link to WPWG 15:19:14 ack Ad 15:19:24 (IJ: How should we do this on github?) 15:19:53 AdrianHB: The original request from Marcos was not to write working code, but rather code that showed how we would use the API to see if it makes sense 15:19:58 agenda+ Rename the spec 15:20:59 ...I had understood we would write things the way we want them to work, and then design the API accordingly 15:22:06 AdamR: .canMakePayment() is no longer relevant 15:22:43 AdamR: I believe the example for POSTing for payment means take the current example and update it 15:23:05 https://github.com/w3c/webpayments-payment-apps-api/pull/101 15:23:20 IJ: May have been fixed 15:23:25 AdamR: If so, that addresses handling POSTing 15:23:53 q+ to suggest we agree on use cases before diving into code 15:24:06 ack AdrianHB 15:24:06 AdrianHB, you wanted to suggest we agree on use cases before diving into code 15:24:25 AdrianHB: I think it would be useful to agree first on the things we need examples for. 15:25:26 Adrian: I don't just mean functions. I mean different scenarios like "one service worker per payment method" 15:25:35 ..."I have 4 options that I want to separate into wallets" 15:25:58 IJ: Is the latter part of AdamR's proposal? 15:27:42 The proposal from Tommy: https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Apps%20and%20Workers%202.md 15:27:52 AdamR: I think we probably do want to keep the WebIDL in concert with examples 15:28:07 ...otherwise it could be difficult, e.g., to write examples that are mutually consistent 15:29:10 AdamR: +1 to a place with lots of examples that we can cherry pick from for the spec 15:29:55 AdamR: examples.md 15:30:07 https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md 15:31:02 AdrianHB: This will also help with testing 15:31:34 IJ: Let's update Pascal's action to start to edit https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md 15:32:07 Pascal: We may need to differentiate code example from app example 15:32:56 pjbazin on Github 15:33:41 IJ: AdamR, do you want to put some code in there too? 15:33:48 AdamR: Don't think it's necessary but not opposed 15:34:17 AdrianHB: Let's not waste time; just put in the spec if we are happy with code....this examples.md is a scratch pad 15:34:34 AdamR: I distinguish code to illustrate the design from code to drive the design 15:35:27 topic: Issue 91: Line items and privacy 15:35:40 https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-279904374 15:38:35 IJ: Should browsers (good practice) offer a feature to let users share or not share line items with payment apps? 15:38:55 q+ 15:39:25 AdamR: It's still my position that these strings should NOT be passed through, but I understand that's not the prevailing sentiment 15:39:48 alyver: There are cases where you do want to send it through, e.g., credit cards for level 2 and level 3 requirements 15:40:43 ...specific to credit card transactions (corporate cards) 15:40:48 q+ 15:40:54 ..if there's a payment app that handles corporate purchasing 15:41:07 ...you would need additional data to get a lower interchange on that transaction 15:41:20 ack ada 15:41:36 adamR: Is this something that's possible to do based on text, or do you need structured data? 15:41:41 ack alyver 15:42:17 alyver: E.g., shopify would send this data to downstream processor 15:42:25 ..you'll have quantity, amount, tax amount, description 15:42:32 ...just treated as strings; no validation is done 15:43:07 AdamR: We probably want to collect information on this. if it's a requirement on the API, we want to make sure that what we have is adequate to satisfy those requirements 15:43:19 ..e.g., we don't have quantity indicator, etc. 15:43:27 ...these would be new requirements (on PR API, not payment apps) 15:43:33 alyver: It's really for corporate purchasing cadrs 15:44:07 q+ to ask if there are other ways to get the data? 15:44:08 Frank: Ian summarized our use cases: credit based on risk assessment and what is purchased 15:44:27 ...we also send an invoice (similar to payPal) ... payment happens at a later stage and it's useful to know what you bought 15:44:30 ack AdrianHB 15:44:30 AdrianHB, you wanted to ask if there are other ways to get the data? 15:44:37 AdrianHB: Are there other ways to get the data? 15:44:47 ..its sounds to me like this use case is potentially payment method specific. 15:45:08 q+ 15:45:11 q+ 15:45:17 ..if you are using basic card but the line items are only appropriate for certain cases, you could provide data in payment method data 15:45:20 ack fr 15:45:36 Frank: Doesn't that complicate implementation? Easier if part of standard data set 15:45:43 AdrianHB: Yes, it would. 15:46:22 q+ 15:47:04 Adrian: One idea is for merchant to say "don't pass on"; so browser displays but does not pass on to the payment app 15:47:21 ...and this could be done on a payment method specific data 15:47:26 ...payment details only passed to selected payment apps 15:47:43 ...so merchants pass on only for payment methods where they think payment apps need the data. 15:47:58 IJ: That puts control in merchants' hands rather than users' 15:47:59 ack pas 15:48:12 pascal_bazin: We have to remember that at least shipping option is included 15:48:27 ..it's potentially always sent to the payment app 15:48:30 ack frank 15:48:48 frank: If the main concern is privacy, sharing this with the browser isn't that as bad as sharing with actual payment providers? 15:49:08 Fair enough 15:49:23 q+ 15:49:45 ack alylver 15:50:17 alyver: +1 to AdrianHB's idea of a merchant being able to control whether line items are passed on to the payment app 15:50:54 q+ 15:51:04 ack ly 15:51:05 ack ad 15:51:08 ack aly 15:51:21 adamR: I would hesitate for this to be part of payment method specific data 15:51:28 ...if it's a flag that the merchant controls, I think this should be top-level 15:51:31 +1 15:51:34 +1 15:51:38 q+ 15:51:40 +0 15:51:42 ack pas 15:51:52 +1 15:52:40 IJ: Note that this is different from merchant not providing data at all, since browser does display line items in native chrome. This is just about not handing data to (1) all apps and (2) thus only selected app 15:52:42 q? 15:53:17 IJ: How is google currently managing this for native app integration? 15:53:42 rouslan: We are sending line items to native payment apps 15:54:06 ...haven't really heard any feedback. I'm open to changing this. 15:54:49 IJ: Should we address this with Pull request on PR API? 15:54:58 +1 - maybe an issue first 15:55:09 Shopify officially providing feedback to Rouslan: As a default, we do not want to share line items to downstream payment apps. 15:55:37 alyver: ack 15:55:53 ACTION: AdrianHB to raise PR API issue for discussion in the WG 15:56:09 https://github.com/w3c/webpayments-payment-apps-api/issues/91 15:57:28 Topic: Filters 15:57:34 IJ: Rouslan had some updates to do and talk to MS 15:57:40 Rouslan: We pinged MS; they have not yet replied. 15:58:03 ..in general there are mixed feelings about this particular change regarding addition of a filters field. We'd still prefer a data field 15:59:01 ...I understand that filters is a clean API...we trust Mozilla's idea. But the backwards compatibility is an issue. If MS does not implement "filters" as a key, there is less motivation 15:59:06 Topic: Next meeting 15:59:11 7 Feb 15:59:36 IJ: Ideally we have an updated spec by 16 March 15:59:53 Topic: Spec title 15:59:57 Proposed: Payment Handler API 16:00:03 I support this change. 16:00:03 +1 16:00:24 +1 from me 16:00:29 IJ: Any objections? 16:00:32 +1 16:00:40 (Let's give people one week then we'll resolve this.) 16:00:46 RRSAGENT, make minutes 16:00:46 I have made the request to generate http://www.w3.org/2017/02/28-apps-minutes.html Ian 16:00:52 RRSAgent, set logs public 17:26:22 adamR has joined #apps