02:55:21 Max has joined #WPWG 03:20:25 RRSAgent, make minutes 03:20:25 I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian 03:20:33 RRSAgent, bye 03:20:33 I see no action items 13:37:36 RRSAgent has joined #wpwg 13:37:36 logging to http://www.w3.org/2017/03/24-wpwg-irc 13:37:38 RRSAgent, make logs public 13:37:38 Zakim has joined #wpwg 13:37:40 Zakim, this will be 13:37:40 I don't understand 'this will be', trackbot 13:37:41 Meeting: Web Payments Working Group Teleconference 13:37:41 Date: 24 March 2017 13:37:57 Agenda: https://github.com/w3c/webpayments/wiki/FTF-March2017 13:37:58 Chair: Nick 13:39:06 :-) 13:39:56 present+ 13:40:28 present+ 13:41:23 Present+ Katie_Haritos-Shea 13:42:03 present+ 13:43:25 present+ 13:43:26 nicks has joined #wpwg 13:46:28 m_and_m has joined #wpwg 13:46:57 Li_lin has joined #wpwg 13:50:04 Tommy has joined #wpwg 13:52:12 mweksler has joined #wpwg 13:53:09 mweksler has joined #wpwg 13:53:30 todd_a has joined #wpwg 13:53:38 present + 13:53:45 present+ 13:53:46 rouslan has joined #wpwg 13:53:58 dezell has joined #wpwg 13:55:09 present+ AdrianHb 13:55:17 scribe: AdrianHB 13:55:21 present+ 13:55:21 present+ 13:55:22 pierre has joined #wpwg 13:55:23 zkoch has joined #wpwg 13:55:26 mathp has joined #wpwg 13:55:32 marcosc has joined #wpwg 13:55:41 MattPi has joined #wpwg 13:55:41 topic: Payment Handler Spec Issues 13:55:48 [Ian slides] 13:55:51 pascal_bazin has joined #wpwg 13:56:06 https://www.w3.org/2017/Talks/ij_apps_201703/ij-apps-wpwg-201703.pdf 13:56:28 ian: going to go through main issues and look for WG attention 13:56:37 ... 4 keys themes 13:56:48 ... 1. Reuse web tech 13:57:05 ... 2. Impact of Payment Req spec 13:57:33 rrsagent, draft minutes 13:57:33 I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html manu 13:57:43 ... 3. Data exchange with PR API 13:57:55 Manash_MC has joined #WPWG 13:57:56 fdold has joined #wpwg 13:58:00 q? 13:58:06 ... 4. Merchant preferences 13:58:12 present+ manu 13:58:28 present+ 13:58:32 zakim, who is here? 13:58:32 Present: Ian, schuki, Katie_Haritos-Shea, michel_cc, nicktr, mweksler, AdrianHb, m_and_m, rouslan, manu, zkoch 13:58:35 On IRC I see fdold, Manash_MC, pascal_bazin, MattPi, marcosc, mathp, zkoch, pierre, dezell, rouslan, todd_a, mweksler, Tommy, Li_lin, m_and_m, nicks, Zakim, RRSAgent, Ryladog, 13:58:35 ... AdrianHB, dick, alyver, Max, michel_cc, cweiss, pea13, canton_, MikeSmith, DavidM_GSMA, hober, schuki, dlehn, trackbot, dlongley, Ian, manu, mkwst, ShaneM, slightlyoff, nicktr, 13:58:35 ... adrianba, oyiptong, JakeA, emschwartz, Dongwoo, davidillsley_ 13:58:43 present+ 13:58:45 present+ 13:58:50 present+ 14:00:34 present+ 14:00:52 pressent+ 14:01:25 [ian talking through latest proposals - see slide 5] 14:02:12 jean-yves has joined #wpwg 14:02:18 CyrilV has joined #wpwg 14:02:22 present+ jean-yves 14:02:24 frank has joined #wpwg 14:02:25 present+ 14:02:27 q? 14:03:01 zkoch: there's a few aspects to the options discussion. It's fundamentally a UX thing so we can't have normative reqs 14:03:09 present+ 14:03:11 ... why don't I like it in practice: 14:03:23 ... 1. space limited on mobile 14:04:06 ... 2. consistency in display of same instruments (cards shown differntly by diff apps) 14:04:06 ... 3. high likelihod of duplicates 14:04:30 ... 4. not convinced by benefit if you still have to end up in the application 14:05:11 q? 14:05:15 q+ 14:05:16 ... chrome has strict design rules and others have other rules we should let everyone deal with this themselves (including apps) 14:05:44 q+ 14:05:44 ian: if you can see detail and click directly there may be a faster path (forgot to mention in presentation) 14:05:52 ack zkoch 14:06:00 adamR has joined #wpwg 14:06:26 rouslan: i often hear argument that the browser can decide if it displays options or not but I think that is poor as apps will need to define two handlers 14:06:33 q? 14:06:52 MattS has joined #wpwg 14:07:01 q? 14:07:05 ack rouslan 14:07:29 mike_mastercard has joined #wpwg 14:07:34 ack Tommy 14:07:43 zkoch: you'll usually find the ecosystem settling on lowest common denominator so if one browser doesn't support then none will 14:08:11 q? 14:08:15 AlanSamsungPay has joined #wpwg 14:08:21 ken has joined #wpwg 14:08:22 tommy: I disagree with zkoch on point 4 above. If the user has configured the app for optimized flow then the app may never even need to show UI. 14:08:23 present+ 14:08:23 q+ 14:08:43 zkoch: agree this is possible but don't see this being used in the real world. 14:08:45 q+ 14:08:46 q+ 14:09:07 tommy: for low sums (micropayments) then I see this happening 14:10:30 zkoch: this is an optimization. I see the challenge of simply getting the apps into the selections screen as hard enough. lets do that first 14:10:34 TYPE FASTER ADRIANHB! 14:11:03 adamR: this is a checkout flow and clicks increase abandonment. we don't want this to be worse than the current web experience. 14:11:11 ack AdrianHB 14:11:24 ack adamR 14:11:26 +manash 14:11:30 dick: +1 to adamR 14:11:32 ack dick 14:12:04 q+ 14:12:06 ... user experience where options are surfaced early is v important 14:12:22 ... the options the user has are hidden which is also problematic 14:12:37 q? 14:13:53 +1, I foresee UX problems if each payment app can show, say 3-4 instruments inside the browser UI 14:13:58 q+ manash 14:14:06 zkoch: this pushes the UX problems onto the browser. The app can have defaults set at registration so that the user doesn't need to choose an instrument. 14:14:22 betehess has joined #wpwg 14:15:02 zkoch: payment apps still need to solve UX problems at registration 14:15:43 dick: issue is that the user may not understand what options they have available if they pick the payment app (they don't remember what instruments they registered) 14:15:51 zakim, close queue 14:15:51 ok, AdrianHB, the speaker queue is closed 14:16:11 vkuntz has joined #wpwg 14:16:31 present+ 14:16:41 present+ 14:16:46 present+ 14:16:56 cyril: this seems like the discussion is about the merchant concerns (i.e. cart abandonment) whereas for financial service providers we care about the user's concerns like consent of the payment 14:16:57 present+ 14:17:03 present+ 14:17:05 present + 14:17:35 ... it is important that we don't forget that the user always consents to a payment 14:17:45 q? 14:17:49 ack CyrilV 14:17:50 present+ Frank 14:17:53 ack Manash_MC 14:18:03 ack Manash 14:18:38 manash: stats on conversions show that card on file converts 40% whereas for example PayPal 1-touch has 80% conversion so there is evidence that conversion is impacted by clicks 14:19:23 zkoch: when a PayPal user pays with PayPal they just pick PayPal. They seldom care what the underlying instrument is. 14:19:43 ... this optimized checkout flow is still possible. 14:20:16 ian: we have in the spec a definition of a data structure and no UX reqs. We have 3 options to go forward: 14:20:26 ... 1. drop this data structure 14:20:52 ... 2. provide the data to browsers but they choose what depth of display they implement 14:21:45 ... 3. put display reqs in the spec that force borwsers to display all instruments and details the app registers 14:22:13 [ian takes a strawpoll on the WG feeling aboyut these options] 14:22:28 alan: could option 2 include guidance on display? 14:23:33 alan: there is a power shift from merchant to browser. We are giving browsers more control than they have today. 14:23:39 CyrilV has joined #wpwg 14:24:06 12 votes for option 1 14:24:17 12 votes for option 2 14:24:29 4 votes for option 3 14:24:33 I would have voted option 1 (repeal) if I thought there would be a replace, so i went with 2. 14:24:58 q+ 14:25:00 q+ to ask if this is mostly an implementation complexity concern among option 1 14:25:11 zakim, open the queue 14:25:11 ok, AdrianHB, the speaker queue is open 14:25:17 q+ to ask if this is mostly an implementation complexity concern among option 1 14:25:41 q? 14:25:44 q+ 14:25:48 ack manu 14:25:48 manu, you wanted to ask if this is mostly an implementation complexity concern among option 1 14:25:57 q+ 14:26:04 q+ 14:26:11 q+ 14:26:11 manu: for those in favour of option 1, is the primary concern implementation complexity? 14:26:26 ian: I heard many concerns (beyond that) 14:26:37 I'd like to point out an inconsistency in the existing implementations - essentially "basic card" handler is extra privileged because it displays all the instruments, whereas the other handlers (bobpay, androidpay as examples) only display origin/handler name 14:26:49 q? 14:27:01 marcos: my experience is that we are trying to do too much too fast. We should be more incremental. 14:27:30 ... we have good infra in place. We still have many things to solve so let's start with option 1 14:28:05 ack rouslan 14:28:08 zakim, close queue 14:28:08 ok, nicktr, the speaker queue is closed 14:28:24 rouslan: +1 to marcos. primary concern is complexity. Let's do 1 first then expand to 2 14:28:38 ... also UX concern on mobile 14:29:08 q+ to ask if basic card expansion might go away fi there are apps? 14:29:31 ... in chrome we prefer to not use basic card so they get pushed to the bottom fi there are other options 14:29:38 ack dezell 14:30:30 notes (in response to Adrian's question) that this does seem to be another example of the basic card fudge getting in the way (see also short names, filters...) 14:30:32 dezell: most money spent on payment apps (traditional) is spent on preventing user deception 14:30:43 ack adamR 14:31:16 q+ 14:31:18 adamr: I don;t thing 1 is backwards compatible with 2 or 3 14:31:21 finnneee 14:32:14 ack mike_mastercard 14:32:15 ... i think 3 is the way this shoudl work but I have sympathy for implementers. I see option 1 as deviation from the correct order of constituencies 14:32:35 mike_mastercard: I can sympathize with both sides of this 14:32:51 ... apps in market today have their own experiences that differentiate them 14:33:24 ... so I am inclined to say 1 but I also sympathize with the desire to have an equal positioning with basic card 14:34:06 ... there is always a learning process the first time you do something so we should not neglect the opportunity to optimize that 14:34:10 ian: propose the TF will take this input and come back with updates 14:34:38 ian: [discusses new issue - 116 which we'll not cover now] 14:35:44 ian: another new issue which needs to be logged relates to syncing of state between payment app window and payment app service worker 14:35:50 zakim, open the queue 14:35:50 ok, nicktr, the speaker queue is open 14:36:45 marcos: there are many other issues we need to still figure out like additional permissions and other overlay windows etc. 14:36:57 ian: yes, so let's pick this up in the TF 14:37:22 ian: big issue to discuss is impact of payment handler on PR before PR can go to CR 14:37:50 [back to slides - do we have what we need?] 14:38:06 ^^ yes 14:38:22 MC: should also mention memory issues on mobile with running 2 browser windows at the same time each running a service worker 14:38:26 (adding to minutes) 14:38:54 May I suggest (I know everybody knows about this ) https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf especially focusing on A10, A8, and maybe A3. 14:39:24 mweksler has joined #wpwg 14:39:55 q? 14:39:58 q+ 14:40:06 ian: have those that have done payment app testing got feedback on PR? 14:40:20 rouslan: no problems for us. no changes needed to PR API required 14:40:31 ack rouslan 14:41:36 q+ to waaait 14:41:41 ian: confidence in PR has gone up since Lisbom 14:41:52 s/Lisbom/Lisbon/ 14:42:02 q+ to ask whether we're actually going to discuss that last item. 14:42:15 [next slide on PR API data to be passed to Payment Apps] 14:42:32 ack manu 14:42:32 manu, you wanted to waaait and to ask whether we're actually going to discuss that last item. 14:42:39 nicktr: we will discuss later 14:44:11 ian: propose that PR API spec removes mention of using line items for details of products 14:44:27 zkoch: okay but had assumed that is just Google's position 14:45:01 marcos: people will use this for product items 14:45:37 q+ to mention that I thought we WERE going to use this for product details. 14:45:59 ack manu 14:45:59 manu, you wanted to mention that I thought we WERE going to use this for product details. 14:46:22 manu: this is why we objected to this before 14:46:39 q+ 14:47:10 nicktr: implementors are saying that if it exists people will use it but the WG wants to give strong guidance on how to use it 14:47:23 ack nicks 14:48:06 PROPOSAL: Drop the mention of "products" in the displayItems definition 14:48:12 [filed as issue 477] 14:48:49 q+ 14:49:14 q+ 14:49:29 ack nicks 14:49:33 q+ 14:49:35 ian: can the payment app get permission to get user data like email and shipping from the browser 14:49:36 q+ to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this group. 14:49:49 marcos: this is already available through autofill 14:50:51 nicks: sometimes this data is not just auto-fill data. eg: current location 14:50:54 ack 14:50:57 ack rouslan 14:51:01 q+ to note that this isn't a critical part of checkout flow 14:51:26 rouslan: I have heard more important than shipping is email. This allows payment app to optimize user experience 14:51:29 ack frank 14:51:53 q? 14:52:06 frank: I disagree that autofill is enough. If the user chose an address already then why make them choose it again in the payment app 14:52:50 zkoch: a) very difficult to reason about privacy consent b) why is that critical information? 14:53:05 frank: b) we use it for real time credit? 14:53:26 zkoch: a) the privacy consent messaging sees very hard to figure out 14:53:47 q+ 14:54:06 marcos: there are ways to hack around this anyway 14:54:09 zakim, close queue 14:54:09 ok, nicktr, the speaker queue is closed 14:54:28 ack manu 14:54:28 manu, you wanted to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this 14:54:31 ... group. and to note that this isn't a critical part of checkout flow 14:54:51 manu: there are not core use cases that require this 14:55:17 ack adamR 14:55:17 .. and it feels like we could push it off 'til later 14:55:40 q+ 14:55:52 adamr: for things that don't change often it's likely that the app will already have this info 14:56:34 notes that as push payment use cases increase, the requirement to do fraud screening against things like shipping address will increase on the payment app side. In other words, more use cases like Klarna... 14:56:35 ... second, this is not trusted info so we shouldn't treat it as such 14:57:02 q+ 14:57:30 AdrianHB: We’re taking first world, card-centric view of this whole thing. Real time credit is a reality of developing world. Becoing a big industry 14:57:45 … every scrap of data increases chance of credit. Making this more difficult is just making it more difficult to give people credit 14:57:50 AdrianHB: I think we're taking a very first world, client-centric view of this. Realtime credit is a big thing in the developing world, it's important that a provider can get any scrap of data they can get to. Making it difficult for them to collect that data is going to make it difficult for them to provide credit. 14:57:58 see, this is why i don’t try to help 14:58:00 dick has joined #wpwg 14:58:42 ::hand breaks:: 14:58:56 +1 to adrianHB's point - this is another example of the inherent skew to cards in the spec 14:59:23 frank: we still do verification. we don't assume the data is trusted 14:59:41 adamr: this sounds like an optimization 14:59:51 frank: yes, but so is a lot of what we are discussing 15:00:06 nicktr: are there implications for PR 15:00:26 ian: no, this would all be spec'd in Payment Handler spec 15:00:57 mweksler has joined #wpwg 15:01:03 q+ 15:01:16 zakim, open the queue 15:01:16 ok, AdrianHB, the speaker queue is open 15:01:36 ian: [discussing merchant recommendations - back to slides] 15:01:44 q+ 15:02:46 ian: point has been made that merchant ordering of payment methods may be sufficient 15:03:28 ack AlanSamsungPay 15:03:40 ... also there is a complex layering of preferences between methods, apps and browser preferences (e.g. rouslan has has that Chrome deprioritizes basic card) 15:05:08 alan: Use case: Merchant wants the user to use the merchant issued instrument. Also express that a 3rd party app should use that instrument. 15:06:10 ... also notion of instant credit may be available for specific merchants 15:06:20 1. express pref as an app 15:06:35 2. express pref for instrument within 3rd party app 15:07:00 3. express pref for payment method from specific app 15:07:49 q? 15:08:30 ian: browser can try to match app and request based on origin and merchants can also define their own payment method and have their own app that is the only app supporting that method 15:09:00 nicktr: there is a way to order by method but not by app/handler or instrument 15:09:50 q+ 15:10:10 q- 15:10:43 ian: observation, on the question of do we have what we need to take PR to CR, let's have that chat later 15:10:46 +1 15:11:12 manu: we want to deploy this using web apps and we don't see a clear path to doing so. 15:11:30 ... so the question is are we interested in doing a polyfill 15:12:06 ian: I think this is out of scope because our job is to write a spec not code 15:12:18 q+ 15:12:35 manu: I'm not suggesting that. There is a tradition in W3C that we give a polyfill to people so they can experiment. 15:13:35 I think it easier to go to CR if the group knows there is a polyfill for handlers being developed in parallel 15:14:12 ian: I think we may learn more from the polyfill but not in time to impact a decision about going to CR 15:14:36 manu: is anyone else interested in working on a polyfill? 15:16:06 marcos: I agree with manu but don't have the same conclusions. There are payment apps already working using PR API so I like the idea of a polyfill but not as a means to help learn more about PR API 15:16:25 manu: not enough web based payment apps and those being done are all on Tommy's fork 15:16:54 zkoch has joined #wpwg 15:17:39 ian: experience we'll get from hacking is critical but we have buy in from implementors on PR API and we have been working hard to get it ready for CR. We have addressed what we can ito impact of payment handler. 15:17:52 q? 15:18:04 ack nicks 15:18:06 ack nicks 15:18:48 nicks: I am wary of tying PR and payment handlers together because of dependencies on Service Worker in payment handlers and not in PR 15:19:33 q+ to clarify that his position has softened. 15:19:33 q? 15:19:36 nicktr: any other strong feelings about readiness of payment handler impacting PR readiness for CR 15:20:07 ... my sense is thag the handler spec is much more mature and the general confidence in it is sufficient 15:20:13 ... to take PR to CR 15:20:20 q? 15:20:32 q+ 15:20:50 ian: is the PR spec better since Sept? 15:21:05 marcos: yes but it could still change a lot. CR doesn't mean it won't 15:22:06 ian: testing is not on the agenda but we have made a small amount of progress on it. there are companies that can help with this if any members want to sponsor this. 15:22:19 marcos: remember we can't leave CR without a full test suite 15:23:01 q? 15:23:55 ack adamR 15:24:01 ack manu 15:24:01 manu, you wanted to clarify that his position has softened. 15:24:10 adamr: if we go with option 1 (earlier) then we have a lot of revisions to make to PH spec 15:24:45 manu: I am not saying we can't go to CR without a polyfill. We should set realistic expectations about how long we might be in CR 15:26:06 ... this impacts merchant merchant adoption 15:26:25 ... how easy we can show devs that this works 15:26:40 ian: do WG publish "official" polyfills? 15:26:55 marcos: some do. WhatWG has a great streams polyfill 15:27:25 https://github.com/whatwg/streams/tree/master/reference-implementation 15:27:34 so good 15:27:37 ian: alan raised issue yesterday about apps exposing functions they have to browser 15:27:49 alan: happy to take that into TF dicussions 15:28:06 break for coffee 15:28:07 s/coffee/vodka/ 16:00:38 MattPi has joined #wpwg 16:02:04 marcosc_ has joined #wpwg 16:04:18 Tommy has joined #wpwg 16:07:09 alyver has joined #wpwg 16:07:17 MattS has joined #wpwg 16:07:38 scribe: Ian 16:07:44 CyrilV has joined #wpwg 16:07:44 mathp has joined #wpwg 16:07:44 RRSAgent, make minutes 16:07:44 I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian 16:07:47 present+ 16:07:48 zkoch has joined #wpwg 16:07:55 RRSAGent, set logs public 16:07:56 Max has joined #WPWG 16:08:11 Topic: Credit Transfer Payment Method 16:08:17 Spec -> http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ 16:08:45 vkuntz: Here's how we came up with the data fields => Common global implementation market practice group (CGI-MP) did this work 16:09:46 dick has joined #wpwg 16:09:46 [Vincent reviews a bit of the history of the CGI-MP; will defer to slides once available] 16:10:49 CGI-MP is driven by customer demand for multi bank coordination of implementation tations 16:10:50 q? 16:11:43 vkuntz: We validated the previous SEPA draft against CGI and found only a small number of discrepancies that we addressed 16:12:08 mweksler has joined #wpwg 16:13:36 vkuntz: CGI-MP has produced templates for ACH payments, for cross-border payments, etc. 16:14:39 mike_mastercard has joined #wpwg 16:15:24 vkuntz: For me a recurring payment is a direct debit 16:15:28 q? 16:15:35 nicktr: I would say rather that a direct debit is a kind of recurring payment 16:16:07 Ian: I'd like us to have sufficient understanding of credit transfer spec. 16:16:23 vkuntz: Who are likely implementers of the credit transfer spec 16:16:31 s/vkuntz/adrianhb 16:16:33 nick notes that the credit transfer spec is actually called "webpayments-methods-credit-transfer-direct-debit" 16:16:53 cyril: Companies in europe are developing APIs to initiate credit transfer 16:17:06 q+ 16:17:07 q+ 16:17:17 q+ to say "no" to whatever zkoch says 16:17:50 cyril: The timing is good to share with European companies this work since they are working on this sort of thing 16:18:32 adrianHB: We need to validate the payment method with Atos or Sofort or Ideal or a bank 16:18:47 q+ Frank 16:18:55 CyrilV: BPCE will consider implementing this 16:19:10 q+ 16:19:13 vkuntz: 30% of payments in Belgium on the internet today are done through transfer 16:19:39 zkoch: Looking at the spec, does it make sense to have a generic credit transfer spec, or should there be scheme specific specs? 16:20:54 zkoch: I am not sure how IBAN is required in practtice 16:21:06 vkuntz: What is required is account number. 16:22:03 (Vincent shows the ACH documentation and mappings to CGI-MP) 16:22:43 MattS: We want to get to FPWD to get feedback from ACH and BACS and SEPA and other schemes. 16:23:09 ...we have sense that there's commonality; need to verify this 16:23:22 q+ 16:23:28 zkoch: We support credit transfer and want to publish this....I am happy to advocate getting feedback 16:23:32 ack zkoch 16:23:49 q+ to say that example requests per scheme may be easier than actual implementations as a start 16:23:56 Ian: Zach had mentioned, "can you find a common data set"? 16:24:07 ack ian: 16:24:38 Ian: We had the word of Cyril and Vincent, but that's what led to the NACHA outreach, that's what led to Todd getting this document to us. I think FPWD would help us to raise awareness. It would also help wrt. other Credit Transfer systems. 16:24:43 q? 16:24:50 ack Ian 16:24:50 Ian, you wanted to say "no" to whatever zkoch says 16:24:50