13:58:04 RRSAgent has joined #wpwg 13:58:04 logging to http://www.w3.org/2016/09/08-wpwg-irc 13:58:06 RRSAgent, make logs public 13:58:08 Zakim, this will be 13:58:08 I don't understand 'this will be', trackbot 13:58:09 Meeting: Web Payments Working Group Teleconference 13:58:09 Date: 08 September 2016 13:58:23 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160908 13:58:37 Ian has changed the topic to: http://www.w3.org/Payments/WG/ 13:59:00 Regrets+ AdrianHB 13:59:17 present+ Ian 13:59:19 present+ Pascal 14:00:25 present+ nicktr 14:00:39 present+ Roy 14:00:49 present AdamR 14:00:53 present+ AdamR 14:01:32 q? 14:02:11 present+ ShaneM 14:02:50 Max has joined #wpwg 14:03:03 zkoch has joined #wpwg 14:03:13 present+ zkoch 14:03:20 present+ Jean-Yves 14:03:25 present+ dlongley 14:03:27 Present+ Manu 14:04:35 Present+ jyr 14:04:42 regrets+ AdrianB 14:04:54 I have made the request to generate http://www.w3.org/2016/09/08-wpwg-minutes.html Ian 14:05:06 agenda => https://github.com/w3c/webpayments/wiki/Agenda-20160908 14:05:21 Topic: Decision to publish HTTP API and core message specifications 14:05:27 Decision email => https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0035.html 14:05:54 nicktr: Thanks to all who prepared the documents and those who reviewed them. 14:06:05 ...chairs and team contacts have been discussing the feedback and concerns as well 14:06:22 rouslan has joined #wpwg 14:06:26 ...there was broad support in the group to publish 14:06:29 present+ 14:06:38 ...but also statements regarding implementation ("not planning to") 14:06:44 q+ to offer next steps / plan 14:06:46 ...we will want to ensure we have implementers in the group 14:06:49 ack manu 14:06:49 manu, you wanted to offer next steps / plan 14:06:56 ack manu 14:07:07 Thanks for getting this moving! 14:07:20 Manu: The Editors chatted briefly before this call. Our plan is to change the title of Core Messages, update the prose to match that, and we are wondering if there are other changes people want us to make to finalize the specs for publication 14:07:27 nicktr: I don't recall seeing seeing others 14:07:44 IJ: Any interest in combining the specs? 14:07:50 Manu: I think we would like to keep them separate for now. 14:08:03 ...distinguish protocol from messaging 14:08:23 ...at TPAC we will put forward a plan to address some of the concerns that were raised, such as getting implementers in the group. 14:08:37 ...having the FPWD out there will help us in discussions with other PSPs and sites that want to expose the API 14:08:42 q? 14:09:40 IJ: I am happy to draft the transition request. Anybody other than chairs want to see it? 14:09:42 [No answers] 14:09:49 IJ: I will draft that today for the Chairs. 14:10:42 The editors will have FPWD-ready specs by next Monday. 14:10:48 ...Hope to have approval by Monday 14:11:44 topic: Payment apps discussion on merchant control of display order 14:11:51 present+ Max 14:12:08 present+ Ken 14:12:44 present+ Rouslan 14:13:08 Max: We had a brief discussion in the payment apps task force about merchant control of app ordering 14:13:15 ...decided to bring the discussion here 14:13:41 https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown 14:13:51 [Max wrote a proposal for discussion 14:14:15 pascal has joined #wpwg 14:14:29 Max: The use case is that a merchant may want to highlight a particular payment method (e.g., because there is some period of time when that payment method is subject to a promotion) 14:14:35 === 14:14:35 The merchant website supports aPay and bPay. 14:14:35 The user browser has only registered bPay. 14:14:35 There is a commercial promotion campaign cooperation between merchant website and aPay. 14:14:36 The merchant want the user browser to display both aPay and bPay during the promotion cooperation period. It is preferred to display aPay in a higher priority. 14:14:37 === 14:15:27 Roy has joined #wpwg 14:15:27 q+ to wonder if this is the thing that drove the card brands out of the room at our F2F meeting? 14:15:28 q+ 14:15:31 Max: Merchant needs an API to influence the payment app display order 14:15:35 q+ 14:15:41 q? 14:15:45 q? 14:15:46 ack Manu 14:15:47 manu, you wanted to wonder if this is the thing that drove the card brands out of the room at our F2F meeting? 14:16:07 ack manu 14:16:36 Manu: Right now we have payment method order from merchant. 14:17:01 ...are you suggesting an API instead? 14:17:24 Max: I am not sure what the mechanism should be...API is just an example. Other mechanisms to achieve the same goal of merchant-specified order are ok 14:17:56 q+ 14:18:02 q+ to give some framing 14:18:14 q? 14:18:20 ack rouslan 14:18:23 ack rouslan 14:18:32 rouslan: I would like to hear perspectives from Amex. 14:18:38 ...it would be good to get back to us on that 14:18:51 ack Roy 14:19:03 +1 rouslan - this should be /one/ of the signals that a browser takes. 14:19:06 ...I think that we should enable the merchant to send preferences, but leave to the browser (using other data as well such as user prefs) to choose the final order 14:19:18 ack roy 14:19:28 also, fwiw - +1 to declarative approach (in JSON) vs. imperative approach (API) 14:19:45 Roy: I definitely see the use case for this and why it is valuable. I get concerned about "going down the rabbit hole" of allowing the merchant to have final control over display 14:20:40 q+ to perhaps clarify Roy's point? 14:20:40 +1 merchants can implement this on their own by communicating with the payment app in some way 14:21:02 ...what is the value proposition of a merchant to use the API instead of implementing their own checkout flow, especially if they have a limited number of payment methods, and they have a desire to strongly control the ordering. 14:21:05 ack rouslan 14:21:05 rouslan, you wanted to perhaps clarify Roy's point? 14:21:05 q? 14:21:41 rouslan: to clarify Roy's point further - the browser provides value to the merchant by bringing in more signals like "which payment methods were used on other sites" which the merchant would not know. This is a value-add for the merchant. 14:21:50 ...if the merchant controls everything there are no signals from the browser. 14:21:53 ack me 14:21:53 Ian, you wanted to give some framing 14:22:11 IJ: Signals we have 14:22:12 Ian: Sounds like we're going to talk about signals, some of these signals include: 14:22:28 Ian: The first one is payment method order through the Payment Request API. 14:22:32 pirouz has joined #wpwg 14:22:35 Ian: The second one is recommended payment apps 14:23:20 q+ 14:23:26 Ian: Some of the scenarios we can imagine are - if you are on a website, and merchant recommends their own app, they can decide if one of them is same origin and display that at the top. Browser may have other configs that are helpful to the user, though. The question is a choice between the merchant having enough channels to express their preferences where browser takes those signals into account. 14:24:03 Ian: or, browser has a definitive list - Roy/Rouslan said that if you want to take over the flow totally, then using the API doesn't help that much. 14:24:06 q? 14:24:15 ack Max 14:25:09 Max: Responding to Roy/Rouslan...merchant doesn't want full control...just some options to influence the ordering of the payment app. The benefit is that some merchants are more likely to adopt the payment request API if there is more flexibility to meet their needs. 14:25:24 ...we would rather have them using the API then falling back to "the current way" of implementing their own checkout flow. 14:25:40 q+ 14:26:08 ...my opinion (to clarify) is not to give the merchant total control of display order, just a mechanism to give the merchant some flexibility to influence the display order 14:26:09 ack zkoch 14:26:35 zkoch: Two quick thoughts - ...(Chromium 53 rolled out yesterday)....we have talked with a lot of merchants 14:26:57 ....as you know we are only supporting cards + android pay..it's not been a blocker for merchants to accept the API..it's limiting yes, but not a big blocker. 14:27:12 ...in the end the merchants want to know whether the API has a positive effect on convergence 14:27:29 ...I don't think we need all uses covered for merchants to adopt the API 14:27:46 ....I will say that we have heard that there are use cases where the merchant would like to guarantee definitively that a payment app is available 14:27:50 ...e.g., PayPal 14:28:10 ...merchants would like, for example, not only to influence ordering, but to guarantee that a particular app is available 14:28:19 ...so that's another "I need to guarantee" requirement 14:28:27 q+ 14:28:57 nicktr: Max, are you looking for there to be a new mechanism beyond payment method order and recommended apps? 14:29:16 Max: For me, I haven't spent a lot of time thinking about solutions yet. 14:29:26 q? 14:29:31 ...I think we need more discussion to see whether the current mechanism is sufficient to cover the use case 14:29:35 ack Ian 14:29:46 Ian: On the topic that Zach raised about guaranteeing a particular payment method... 14:30:44 Ian: I think we discussed this at some point, Zach, don't know if you put this idea of splitting accepted payment methods into two bundles - "must have support for these payment methods" and "I also accept these other ones". The merchant could get a signal back from "none of the required payment methods are registered". 14:31:03 Ian: Can you clarify, Zach? 14:31:06 zkoch: I made two contradictory points - you don't have to solve all problems and "sometimes there are must-haves" 14:31:28 ...if we want to solve the nascar problem and have a single "buy" button, then we need to solve this "must show" problem. 14:32:03 ...meanwhile, back to the question about required v. also-supported payment methods, we've chatted a bit about it...AdrianB is looking into how we could potentially address this requirement. 14:33:35 Ian: Then the merchant can set preferred order if required instruments are there? I don't know what browsers are going to provide - going out on a limb, Max, do you think knowing that required thing is there and being able to specify order is sufficient? 14:33:45 Ian: Max, does having those two things meet your use case? 14:33:45 Max: Maybe...but need more time to work on it 14:34:01 NickTR: Sounds like it would be useful to have an issue to track against 14:34:37 IJ: I think we have an issue on this ...maybe we need to reopen if already closed to include this use case 14:34:37 Ian: I think we have an issue on this, will look into it later. 14:34:43 q? 14:35:18 Topic: Any updates to PMI proposal 14:35:33 zkoch: No updates yet 14:36:03 topic: Issue 244 - remove careOf? 14:36:08 https://github.com/w3c/browser-payment-api/issues/244 14:36:19 zkoch: Google's I18N team raised this issue 14:36:35 q+ 14:36:43 ack Ad 14:37:19 adamR: The rationale for putting it there in the first place (and why I would like to keep it)...is that it has semantic importance at least in the US. 14:37:34 ...I cite some references to legal postal code where these things have legal force 14:37:45 ...and it's semantically appropriate to include these in addresses 14:38:15 +1 priority of constituencies (easier for users) 14:38:24 q? 14:38:25 ...by not having this, we either force users to put information in a place where it's not convenient or obvious, or we make libraries more complicated to deal with this 14:38:26 q+ 14:38:41 ...priority of constituencies suggests we make the user's experience easier 14:38:49 nicktr: I've not seen careOf in other APIs, FWIW 14:38:54 ack zkoch 14:39:35 zkoch: There is a cost to support this. While I agree with AdamR's point about preferring the user experience, there are ways to address this. 14:39:50 ...the browser could have a careOf field and put into the recipient of the response...we do that already 14:40:23 ...if you want to put a CareOf field, you need to figure out as an implementer where to put it 14:40:37 ....I do agree with Andy who raised the issue that there's not a lot of evidence of this in use out there. 14:40:59 q+ to mention that there are interop requriments with other standards like ISO 20022 14:41:24 ack ShaneM 14:41:24 ShaneM, you wanted to mention that there are interop requriments with other standards like ISO 20022 14:41:26 ack ShaneM 14:41:46 ShaneM: We may also want to consider interop with ISO20022 14:41:52 q+ 14:41:57 ack ad 14:42:02 is "care of" just a "special delivery instructions" field? 14:42:16 dlongley: See the references I put on the issue 14:42:23 nicktr: I don't think I've seen careOf in a card protocol; I also don't recall (but it may exist) careOf in a payment protocol 14:42:38 adamR: We are still going to have to have these fields, it's just a question of whether the user is doing it or software. 14:43:01 q? 14:43:56 Ian: We have an upcoming face-to-face meeting where we've been talking about whether browser vendors want to see if their code bases could use better harmonization. Wonder if Zach and AdrianB might discuss how this could be managed/addressed. 14:44:13 Ian: So, punting to face-time so we can look at user experiences. 14:44:14 IJ: Can we punt to face time at TPAC to look at user experiences? 14:44:19 Might be useful to query the interest group 14:44:35 zkoch: I'm ok to punt to pac...also allows additional time for responses on github 14:44:46 https://www.iso20022.org/standardsrepository/public/wqt/Content/mx/dico/bc/_FN9rs8TGEeChad0JzLk7QA_-1512507243 14:44:47 zkoch: Is there more evidence than USPS..if so, would be good to highlight that? 14:45:15 (Nick observes ISO 20022 doesn't have careOf) 14:45:27 Nick: I will take an action to work with Kris/Vincent to look at careOf in ISO20022 14:45:51 ACTION: Nick to check with Kris/Vincent on support for careOf in ISO20022 14:45:51 'Nick' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., nshearer, ntelford). 14:46:00 topic: TPAC agenda check 14:46:09 https://github.com/w3c/webpayments/wiki/FTF-Sep2016 14:46:16 https://github.com/w3c/webpayments/wiki/FTF-Sep2016 14:46:41 Ian: In the last call, we asked for some people to sign up for some sessions. Just an update. Rouslan and I talked about implementation experience and demos. 14:47:10 Ian: The goals of that session are now going to be to have implementers ask us questions based on their implementation experience, showing us demos, address issues, etc. 14:47:53 Ian: For folks doing testing, share some of their observations on the specs. I distinguish that on the test suite. What we've learned through testing that might affect the APIs, I know Mike found some ambiguities / inadequate level of details when writing tests. This is an opportunity to discuss that. 14:48:26 Ian: The decision on HTTP API, Manu will present something there. 14:48:49 -> https://w3c.github.io/webpayments/proposals/method-practice/ 14:49:05 Ian: For Payment methods, we could have breakout sessions on day 2 to make progress on payment method specs. Max started a draft, I made some edits to it. Part of the payment methods agenda item. We don't have updates to SEPA, don't yet know if someone wants to sign up to lead a discussion on that. 14:49:30 q+ 14:49:35 Ian: That requires preparation - what question do editor's want feedback from group on. We'll have to meet on day 2 and make progress, unless someone wants to do a SEPA update for the group. 14:49:38 ack jyr 14:49:40 ack jyr 14:51:18 Ian: We have a draft SEPA Credit Transfer specification that Cyril started to work on. 14:51:22 http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ 14:51:32 Ian: Unfortunately, Cyril won't be at TPAC. 14:52:14 Ian: I started discussion w/ editors and Matt trying to figure out what we need to do to get it updated so we have a fresh draft for the group/get it updated. I haven't heard how we're going to do that. No updates to specification in time for TPAC. For those that are interested in spec, like in London, we can meet and make progress. 14:52:31 Ian: Capturing inputs/outputs for credit transfer - don't know what we need to do to get that into a FPWD. 14:54:26 Ian: Credit Transfer is close to push payments, so we have a first step to go through which is to establish some common vocabulary and understanding of what we're talking about, which is Direct Debit and Credit Transfer. Cyril created a UML diagram on credit transfer and some bits on direct debit, just a first draft. Various use cases inside Direct Debit. The point I'm making is that I do think that we need to not be so specific as SEPA. There is a recurring 14:54:26 impression wrt. what are push payments. I think it would be very useful to define, during TPAC, the common understanding of what we're talking about. Payments for push payments / pull payments should not be specifically European question. 14:54:28 jyr: Maybe we need to group this under "push payment" discussion 14:54:46 Ian: Maybe we do a break-out session where we talk about push-payments 14:54:48 +100 14:54:55 q+ to say we should dump the Bitcoin folks into that discussion. 14:54:58 +1 14:55:08 (super interested in push payments!) 14:55:19 +1 14:55:21 +1 14:55:44 +1 14:56:08 q+ 14:56:46 q- 14:56:50 ack Roy 14:56:50 ack Roy 14:57:33 How do we know when we are done? 14:57:43 q- 14:57:45 IJ: Roy will lead the push payment session and start by documenting his idea of goals for the session 14:58:35 Ian: We may have discussion on recurring payments, etc. led by Andrew Betts in IG 14:58:58 Ian: Points that we need to get through to get specs to CR, Zach, you're going to do stuff in that slot? 14:59:00 Zach: Yes 14:59:33 Ian: You mentioned two other specs that might appear by TPAC - cash on delivery and invoice specs. 14:59:56 Zach: Yes, I'll see if we can bring some of that stuff up at TPAC. Those are payment method specs. 15:00:35 NickTR: If there are other things you want to see on the Agenda, put them on there. 15:00:43 Topic: Next meeting 15:00:49 15 September 15:00:55 rrsagent, make minutes 15:00:55 I have made the request to generate http://www.w3.org/2016/09/08-wpwg-minutes.html Ian 15:01:02 rrsagent, set logs public 16:03:35 zkoch has joined #wpwg 16:12:02 adamR_ has joined #wpwg 16:15:41 adamR__ has joined #wpwg 16:37:50 adamR_ has joined #wpwg 16:40:29 adamR__ has joined #wpwg 16:44:06 adamR__ has joined #wpwg 16:48:04 Manu? 16:48:28 Shane? 16:54:46 Adam__ has joined #wpwg 17:26:33 I am here 17:26:40 (sorry - in ARIA meeting) 17:35:14 zkoch has joined #wpwg 18:54:30 Adam__ has joined #wpwg 19:10:45 shepazu_ has joined #wpwg 19:35:20 Ian, hey - what's up? 19:35:31 hi there! 19:35:35 see email re naming and shortnames 19:35:58 that's all...I'll look for email reply 19:37:09 tx! 19:53:52 zkoch has joined #wpwg 20:00:01 zkoch has joined #wpwg 20:09:57 zkoch has joined #wpwg 20:30:04 zkoch has joined #wpwg 20:35:48 zkoch has joined #wpwg 21:17:10 zkoch has joined #wpwg 21:22:10 zkoch has joined #wpwg 21:48:28 adamR has joined #wpwg 21:48:34 davidillsley_ has joined #wpwg 21:48:43 shepazu has joined #wpwg 21:48:44 mkwst has joined #wpwg 21:48:53 adrianba has joined #wpwg 21:48:57 emschwartz has joined #wpwg 21:50:07 zkoch has joined #wpwg 21:52:06 nicktr has joined #wpwg 21:52:07 AdrianHB has joined #wpwg 21:52:43 Dongwoo has joined #wpwg 21:52:58 slightlyoff has joined #wpwg 22:52:44 zkoch has joined #wpwg 23:02:58 zkoch has joined #wpwg 23:05:29 zkoch has joined #wpwg 23:22:04 zkoch has joined #wpwg