13:47:34 RRSAgent has joined #wpwg 13:47:34 logging to http://www.w3.org/2017/03/23-wpwg-irc 13:47:37 present+ nicks 13:47:40 Meeting: Web Payments WG FTF 13:47:44 Chair: Nick 13:47:46 present+ 13:47:50 present+ Rouslan 13:47:52 present+ nicktr 13:47:54 present+ jeff 13:47:59 present+ AdrianHB 13:48:00 present+ padler 13:48:05 present+ manu 13:48:06 present+ nickS 13:48:32 MattPi has joined #wpwg 13:48:35 alyver has joined #wpwg 13:48:47 Roy has joined #wpwg 13:48:49 mike_mastercard has joined #wpwg 13:49:16 zkoch has joined #wpwg 13:49:20 present+ 13:49:24 mathp has joined #wpwg 13:49:25 frank has joined #wpwg 13:49:28 todd_a has joined #wpwg 13:49:30 MattS has joined #wpwg 13:49:36 present+ 13:49:37 present+ 13:49:40 AdrianHB_ has joined #wpwg 13:49:57 dezell has joined #wpwg 13:50:01 present+ 13:50:02 present+ 13:50:05 present+ 13:50:05 present+ 13:50:08 present + 13:50:09 present+ 13:50:10 present + 13:50:11 present + 13:50:12 Present+ 13:50:21 Max has joined #WPWG 13:50:21 present+ 13:50:43 present+ 13:50:48 present+ 13:50:54 ltoth has joined #wpwg 13:51:04 present+ ltoth 13:51:21 scribe: ian 13:51:52 present+ 13:51:53 fdold has joined #wpwg 13:52:06 I can Scribe this one if you want, Ian 13:52:18 Max_ has joined #WPWG 13:52:30 present+Jean-Yves 13:52:39 topic: Welcome 13:52:46 [Nick welcome + invitations] 13:52:52 zakim, who's here? 13:52:52 Present: nicks, Ian, Rouslan, nicktr, jeff, AdrianHB, padler, manu, zkoch, CyrilV, Li_lin, MattS, mweksler, todd_a, michel_cc, Roy, dezell, mike_mastercard, Max, oyiptong, ltoth, 13:52:56 ... mathp, Jean-Yves 13:52:56 On IRC I see Max_, fdold, ltoth, Max, dezell, AdrianHB_, MattS, todd_a, frank, mathp, zkoch, mike_mastercard, Roy, alyver, MattPi, RRSAgent, Zakim, AdrianHB, padler, nicks, jeff, 13:52:56 ... mweksler, rouslan, Li_lin, michel_cc, jean-yves, CyrilV, cweiss, hober, schuki, dlehn, trackbot, dlongley, Ian, manu, mkwst, ShaneM, slightlyoff, nicktr, adrianba, oyiptong, 13:52:56 ... JakeA, emschwartz, Dongwoo, davidillsley_ 13:53:00 present+ mathieu 13:53:04 present+ Tommy 13:53:10 present+ molly 13:53:14 present+ MattMiller 13:53:18 present+ adamr 13:53:19 present+ schuki 13:53:36 present+ todd 13:53:45 present+ mattSaxon 13:53:48 present+ Ken 13:53:53 present+ jeanyves 13:53:57 present+ Frank 13:53:59 present+ Alan 13:54:04 present+ michelw 13:54:08 present+dezell 13:54:13 present+ Stoyab 13:54:13 present+ Stoyan 13:54:16 present+ Kris 13:54:21 present+ Guy 13:54:25 present+ DickHardt 13:54:28 present+ marcos 13:54:44 DavidM_GSMA has joined #wpwg 13:55:17 jiajia has joined #wpwg 13:55:30 AlanSamsungPay has joined #wpwg 13:55:38 present- Stoyab 13:55:42 +present 13:55:47 present+ 13:55:49 agenda: https://github.com/w3c/webpayments/wiki/FTF-March2017 13:55:57 jiajiaAlipay has joined #wpwg 13:56:10 present+jiajia 13:56:17 kriske has joined #wpwg 13:56:41 adamR has joined #wpwg 13:56:41 Nick: Goals for the next two days - understand whether we are ready to request PR API, PMI ready to move to CR 13:56:54 ...and also whether payment handler API ready for FPWD 13:56:55 present+ kris ketels 13:57:01 ...and also advance payment method specs 13:57:13 Ryladog_ has joined #wpwg 13:57:17 Present+ Katie_Haritos-Shea 13:57:26 present+ 13:57:56 Present+ 13:58:14 IJ: I will review the process bits on Friday. Goal is to understand what the todo list is before launching the call for consensus 13:58:19 ...which will last 7 days 13:58:59 m_and_m_ has joined #wpwg 13:59:07 present+ 14:00:06 q? 14:00:28 topic: Update from the payment request API editors 14:00:34 [Zach presentation] 14:00:57 zkoch: I am a fast talker. 14:01:15 present+ 14:01:23 zkoch: Since we last met: 14:01:40 - marcos joined as an editor, domenic also joined as an editor 14:01:49 - cheers for adrian bateman 14:01:57 - merged 65 pull requests 14:02:05 ...they did not fundamentally change the shape of the API 14:02:10 ...closed around 100 issues 14:02:27 [Biggest changes] 14:02:55 ...one of the first breaking changes in a while was made yesterday - updateWith now returns a promise that can be rejected. 14:03:14 ...it used to be that we failed silently if weird things happened (e.g., negative totals) 14:03:48 ...we shipped a fix where a promise can be returned that can be rejected after validation 14:04:02 ...did not have an impact on shipping merchants. 14:04:18 ...we added a paymentRequestID for push payments 14:04:32 ...help with reconciliation 14:04:45 ...one of the biggest new functions was the addition of canMakePayment() 14:05:58 ...discussion was about how to balance merchant desire to create good UX with privacy 14:06:18 ...the canMakePayment() function returns true if there is an active payment instrument available. 14:06:50 ...and in the spec we suggest that UAs mitigate the privacy concern. ... google's implementation does rate limiting 14:06:57 q+ to ask if we expect canMakePayment() will be deprecated in time 14:07:00 ...I think that CR will inform our implementation choice, and we can revisit it 14:07:13 ack AdrianHB_ 14:07:13 AdrianHB_, you wanted to ask if we expect canMakePayment() will be deprecated in time 14:07:15 ack AdrianHB_ 14:07:21 AdrianHB_: Do you see that becoming deprecated in the long run? 14:07:36 zkoch: No. 14:07:58 q+ 14:09:04 GuyB has joined #wpwg 14:09:17 ack alyver 14:09:39 dick has joined #wpwg 14:09:39 alyver: There is value in canMakePayment() because the merchant may wish to know whether the method that returns the most value is available 14:10:39 zkoch: (Continuing) 14:10:49 ....for iFrame support we added allowpaymentrequest attribute 14:11:04 ...trying to be forwards-compatible as well 14:11:18 ....lots of editorial changes to the spec, removing ambiguity, etc. 14:11:37 ...Boris from Mozilla raised a bunch of valuable issues; and Domenic and Marcos have been knocking them out 14:11:44 [Getting to CR] 14:12:23 zkoch: I'd like to review the issues that the editors feel are the most important to address. Also want to hear if you have some 14:12:29 ....we have a CR milestone 14:13:11 [Issue 462] 14:13:32 zkoch: This is on multiple PRs at once; not a big issue but it is open 14:13:39 [Issue 360] 14:13:49 zkoch: What should happen during navigation away.... 14:13:57 ..e.g., window closes down, or a navigate event 14:14:01 vkuntz has joined #wpwg 14:14:05 present+ 14:14:09 ...we think we have an answer in the discussion on the issue itself...just awaiting some clarification 14:14:17 ..so we are far along on this one 14:14:21 [Issue 327] 14:14:29 zkoch: This is an I18N issue; we are waiting on Marcos 14:14:36 Marcos: It's both RTL and language of labels. 14:14:59 ...we are going to push that back to WebIDL...we created an object that all APIs can use 14:15:07 [Issue 309] 14:15:15 Multiple modifiers behavior 14:15:34 zkoch: We have this thing paymentMethodModifiers...you can alter the price or line items on a payment method specific basis 14:16:02 ....we need to clarify what happens when there are more than one 14:16:09 ...either first one wins or throw an error 14:16:14 ..we just need to be explicit in the spec 14:16:18 [Issue 464] 14:16:37 zkoch: supported methods as enums or URLs 14:17:03 IJ: About matching semantics 14:17:17 marcos: It's a minor issue; just needs to be fixed 14:17:28 zkoch: We also have some editorial issues (439) 14:17:34 [Issue 229] 14:17:44 zkoch: On guidance text regarding user consent 14:18:02 ...what should we say about user consent....(AdamR issue) 14:18:22 ...the issue is "what does it mean to grant user consent" 14:18:33 zkoch: One view is that the spec says consent is necessary, but now how it's granted 14:18:43 ....we can't be overly authoritative on how 14:18:51 ...part of the question in this issue is how much guidance do we give. 14:19:01 q? 14:19:20 ...other than 229, I think the editors are clear on how to resolve the other issues 14:19:26 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 14:19:29 pierre has joined #wpwg 14:19:30 q+ 14:19:32 Ken has joined #wpwg 14:19:59 [Zach shows currently language; question is whether sufficient or whether more needs to be said] 14:20:02 ack Msat 14:20:04 ack M 14:20:04 q+ 14:20:15 ack MattS 14:20:41 MattS: One of the issues that I raised relates to this issue. I raised an issue about "interaction." The spec is written in a sense that assumes some human interaction. 14:21:01 ...it is my understanding that consent can be granted before hand. And a call to show() could return data without user interaction. 14:21:02 q+ 14:21:18 q- 14:21:26 q+ 14:21:34 Marcos: I agree with Matt's view that prior consent can be granted without user action on every transaction 14:21:59 zkoch: I agree that the spec might not need to constrain "must have an interaction"; ok to review the spec to ensure it 14:22:01 ack Ryladog_ 14:22:08 ...how it works in practice is distinct 14:22:27 Ryladog_: Regarding consent; jurisdictions may affect what is required 14:22:55 ...data protection requirements may vary by jurisdiction 14:23:17 q+ To ask question about regulatory topic raised yesterday in IG meeting and where/when this might make sense to add as a CR? 14:23:20 stoyanstefanov has joined #wpwg 14:23:29 q? 14:23:37 ack adamR 14:24:05 adamR: Mostly I wanted to say I agree with MattS that we allow the streamlined payment in order to be competitive with one-click card on file experiences 14:24:21 ...I think the spec should call out the use case 14:24:29 Marcos: Yes, we can add an informative note describing the use case 14:24:37 NickS: But the spec should not mandate it 14:24:37 q? 14:24:42 zkoch: Ok, I've added it 14:24:45 ack padler 14:24:45 padler, you wanted to ask question about regulatory topic raised yesterday in IG meeting and where/when this might make sense to add as a CR? 14:25:35 padler: Some services require reporting as part of transactions. Might be interesting for merchants to specify the jurisdictions they are bound by and data would be affected by jurisdiction 14:25:51 AdrianHB: Interesting requirement but a new one 14:25:57 padler: Might be an additional hook 14:26:07 zkoch: You can file as an issue and we'll mark it as non-CR blocking 14:26:12 q? 14:26:23 [Pending pull requests] 14:26:49 [468 is minor] 14:27:01 [455 is about I18N] 14:27:07 Marcos: I need to do the work on 455; not much to do 14:27:17 q+ 14:27:59 [450 on accessibility] 14:28:30 marcos: The proposed text is overly generic 14:28:39 ...I think as we gain implementation experience, we will see issues come up 14:28:45 q+ 14:29:22 marcos: implementations are already pretty accessible; I think we need to be able to identify what the key things are; those things will emerge naturally as we gain implementation experience ce. 14:29:28 ...and we don't need generic statements 14:29:46 present+ Mahesh 14:30:25 mattS: I am not sure that the matching algorithm is detailed enough. 14:30:31 ...so would like to review that 14:30:39 ...do implementers think they can implement the spec consistently 14:31:02 AdrianHB: I have an action to call out in the spec (with next text) to say that payment handler will be used for the extension point 14:31:48 ack me 14:31:50 ack m 14:31:52 q? 14:32:05 scribe assit: AdrianHB 14:32:29 ian: I agree with Marcos on accessibility. No value in being generic. 14:33:00 dkuxe has joined #wpwg 14:33:06 q? 14:33:06 ... there have been comments on the thread with a proposed solution. I propose we look at Chaals proposed solution 14:33:10 q+ 14:33:14 ... and don't let this block CR 14:33:20 ack Ryladog_ 14:33:36 marcosc has joined #wpwg 14:33:36 IJ: My proposal is that we not include generic text (since there are many issues that need to be addressed by implementations) and that we consider the mapping proposal separately (from Chaals) and make it non-blocking for CR 14:33:38 q+ 14:34:32 ian: we will also put practical info on the developer portal to help developers do things the right way ito security, regulations and accessibility 14:34:44 ack Ian 14:34:44 ... I don't think the spec needs to say it 14:34:56 q+ 14:35:26 IJ: I think the developer portal is the place to put practice guidance 14:35:29 ian: please join the merchant adoption task force to help us work through some of these accessibility issues... 14:35:35 https://github.com/w3c/payment-request-info 14:35:50 zkoch: The question is "what is useful" 14:35:57 Q+ 14:37:14 ian: we have a number of horizontal issues we must consider. There is no push back on concrete a11n spec additions we simply don't have concrete a11n text to put in the spec right now. 14:37:39 IJ: There is no expectation IMO to provide generic statements. Concrete statements are very important. Guidance should go in the developer portal 14:38:13 MikeSmith has joined #wpwg 14:39:26 RRSAgent, make minutes 14:39:26 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html MikeSmith 14:39:39 RRSAgent, make logs public 14:39:40 MattS: have we made enough progress in payment apps to determine stability of PR API? 14:39:55 Ian: That's my presentation tomorrow; I believe the answer is "we don't have any breaking changes" 14:40:48 zkoch: Most of our changes to date have been small changes; I have gone over the big changes so far in my presentation. 14:41:05 MattS: When I read the spec, lots of the language is pull-payment centric 14:41:41 marcos: Going to CR is an important milestone but it's not the end of the world. :) 14:41:43 q? 14:41:47 ack MattS 14:42:10 Marcos: We can freeze PR API and then layer (v 1.1) based on experience 14:42:24 ...we can get very interoperable over the next year while we work out payment handler 14:42:34 ...I like the layered appraoch 14:42:44 ...I am hopeful that that is the approach we take 14:43:04 q? 14:43:05 q+ 14:43:31 q= 14:43:32 q- 14:43:33 q+ to be concerned about taking saying we can deploy and change something when we have no implementation experience around Payment Handlers. 14:44:07 MaheshK has joined #wpwg 14:44:16 Ken: Regulatory activity is going up globally. 14:44:31 ...e.g., in Hong Kong, payment schemes for users in HK, or when the merchant is in HK, that data has to stay in HK 14:44:39 ...they haven't yet addressed cross-border 14:45:00 ...unlike PCI (a minimum threshold), there is no group looking at minimum for data protection 14:45:17 ...I think it will be challenging to say anything else other than in a developer portal 14:45:18 ack manu 14:45:18 manu, you wanted to be concerned about taking saying we can deploy and change something when we have no implementation experience around Payment Handlers. 14:45:56 manu: This is not an argument against CR, but I think it's naive to layer on PR API. We don't have experience with implementation of payment handler 14:46:15 ...we might want to get some implementation of payment handlers (even with polyfills) 14:46:22 q+ to talk about current states of other specs 14:46:28 ack Ken 14:46:30 ...I do not think that should block us from getting to CR 14:46:38 Marcos: I expect we'll sit in CR a year or two 14:47:05 NickTR: This session is to bring people up to speed...we have a good chunk of time tomorrow afternoon to sew all this together 14:47:13 q? 14:47:25 AlanSamsungPay_ has joined #wpwg 14:47:36 In addition to Ken's remark, FYI such a regulation, compelling to keep data locally, is on the way for several african countries, under decision of African central banks 14:47:49 marcosc_ has joined #wpwg 14:47:50 ack rouslan 14:47:50 rouslan, you wanted to talk about current states of other specs 14:48:30 q+ 14:48:38 ack adamR 14:48:44 rouslan: I think we can go to CR and have a living spec 14:49:04 AdamR: If we go to CR, I don't want that to be a reason not to make changes based on payment handler experience 14:49:16 ...I am most concerned is that we will end up a spec that is incompatible with how we implement payment handlers 14:49:21 q? 14:49:29 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 14:49:48 q+ 14:50:02 zkoch: We have a number of other editorial issues we consider non-blockers; feel free to tell me if you think differently 14:50:11 Marcos: Contributions welcome 14:50:36 ...and getting help to close issues will speed us up 14:50:56 [VAT address collection] 14:51:14 q- 14:51:29 pascal_bazin has joined #wpwg 14:51:30 zkoch: Editors were asked to figure out how manage digital goods price changes (for VAT) 14:51:51 zkoch: Roy (Facebook) is going to look into this more in detail 14:52:15 ...the issue is without an address, you can't determine the totla 14:52:57 ...it can be dealt with by merchant by asking for billing address up front 14:53:05 ...WG said "we think this is important" 14:53:26 ...we concluded after review that we are not going to try to get this in right now 14:53:32 ...there needs to be a lot more spec work to make this possible 14:53:42 ...there's no longer a shipping component, which means we need to clarify the behavior 14:53:54 ...FB is most interested in this, and propose how we alter the spec 14:53:55 q? 14:54:20 Ian: One observation is that the new process would allow, if in six months, there are implementations starting to do this, and we can add that to spec, it's easier to do that now. 14:54:39 Ian: If we make a change like that, you go back to the start of CR. 14:54:40 q+ 14:54:51 q+ 14:55:07 Ian: Let's not say that we are going to go to v2, we can always restart CR 14:55:15 IJ: Let's use the right process at the time, which might include new CR 14:55:16 ack dick 14:56:05 zkoch: from a payment request perspective, the merchant can update shipping options which allows price update (based on events) before user pays 14:56:24 ...shipping is optional, you can do outofband data gathering as needed 14:56:33 ack AlanSamsungPay_ 14:56:40 [Ian asked about revising a Candidate Rec - here is the pointer in the W3C Process --> https://www.w3.org/2017/Process-20170301/#revised-cr] 14:57:03 Alan: I have another cross-border issue - I raised this last night at dinner. The payment manifest file does not appear to have good support for instantiating a market or country specific application 14:57:23 zkoch: Tomorrow we'll discuss the payment method manifest spec...we can add that to tomorrow's agenda 14:58:00 https://github.com/w3c/webpayments/issues 14:58:11 q? 14:58:21 zkoch: Did I miss anything? 14:58:42 stoyanstefanov has joined #wpwg 14:58:55 marcos: What happened to store pickup? 14:59:20 zkoch: We have request shipping (a boolean). We added the notion of a shipping type...it basically updates the label in the UI 14:59:27 ...one does not ship a pizza. You deliver a pizza 15:00:10 ...we left out "store pickup" 15:00:19 ...pick a hardware store that allows store pickup 15:00:28 q+ to note British English/American English diff 15:00:31 ...one challenge is that this store has stores around the country 15:00:44 ...flows get more complicated than what we have affordance for 15:00:49 ...so for the moment we have punted.... 15:01:10 ...we recognize that it's a merchant...but it's complex, and it does not make sense to push into shippingOptions 15:01:15 ...would not be good for the UX 15:01:23 ...we don't have a huge demand for this, so we've decided for now to punt on it 15:01:28 q+ to suggest those that care about the use case make a proposal 15:01:34 ..I realize Apple has store pick up and NickS can tell us about their experience 15:02:00 NickS: It's tied up in our UI. Shipping method and shipping fields are two things 15:02:07 ...in our UX it can be made to make sense 15:02:25 ...not many people use our feature; I'm ok if we leave it out for CR 15:02:30 ack nick 15:02:30 nicktr, you wanted to note British English/American English diff 15:02:39 nick: You wouldn't talk about shipping address in en-uk 15:02:46 ...I get that there's a semantic difference here 15:03:17 Have the opinions of the big box retailers, walmart and costco been considered on the store pickup? The primary online merchants are not the right audience to ask about this 15:03:27 Nick: I think the language in the spec should speak to the difference 15:03:37 q+ to provide merchant feedback on store pickup 15:03:55 ack mah 15:03:55 MaheshK, you wanted to provide merchant feedback on store pickup 15:04:24 MaheshK: our experience - when user chooses store pickup, the user should pick the store 15:04:43 ...for some merchants, people can do store pickup for some items in the cart and some items in store 15:04:47 It also is a growing method for restaurants 15:04:52 ack AdrianHB_ 15:04:52 AdrianHB_, you wanted to suggest those that care about the use case make a proposal 15:04:58 zkoch: So I am proposing we punt on the following topics (1) VAT (2) in store pickup 15:05:02 ack AdrianHB_ 15:05:19 AdrianHB_: I think that people who want us to support the use case would help us most by making a concrete proposal. 15:05:24 ...even while we are here 15:05:35 q? 15:05:50 [Payment Method Identifiers] 15:06:05 zkoch: In general there has been less work on these; I think we have less work to do on both of them. They are much much simpler 15:07:22 zkoch: PMIs are short strings (W3C) or URLs 15:08:29 zkoch: We have some editorial fixes to make 15:08:38 [Issue 8 on equivalence] 15:08:43 stoyanstefanov has joined #wpwg 15:08:54 kihe has joined #wpwg 15:09:02 Ian: What does "handle failure" mean? 15:10:01 Marcos: Fetch mechanics 15:10:11 Ian: We need to review the dependencies 15:10:35 [Issue 26 - link to registry of short names] 15:11:11 q+ 15:12:23 zkoch: Ian proposes we link to a w3c page with the list of short strings 15:13:07 marcos: Let's include them dynamically in an informative note 15:13:10 Ian: +1 15:13:25 Ian: I am aware that there is some disagreement about what short strings should go in the identifier list 15:13:41 nickTR: I think the short strings are a hack; I still think we should use URLs 15:14:37 q? 15:14:41 ack nicktr 15:15:04 [Basic Card] 15:15:29 CyrilV has joined #wpwg 15:16:51 Ian: What is the reluctance with supported types? 15:17:01 zkoch: Note that supportedTypes may be difficult to implement in practice (by payment apps) 15:17:06 q Does the PR spec allow for the potential of merchant routing choice in case that carries over to the web in the U.S.? 15:17:16 (No) 15:17:47 q+ 15:21:35 [Discussion of payment method specs going to Rec v. Note] 15:21:55 q- 15:22:24 Ian: I had intended to raise this as a spec bug, but I'm hearing that people may want to reopen the discussion. 15:22:37 q? 15:22:57 Zakim: 15:23:32 mweksler has joined #wpwg 15:24:19 mweksler has joined #wpwg 15:25:07 mweksler has joined #wpwg 15:25:55 mweksler has joined #wpwg 15:26:45 mweksler has joined #wpwg 15:26:47 pascal_bazin has joined #wpwg 15:27:32 mweksler has joined #wpwg 15:28:20 mweksler has joined #wpwg 15:28:45 RRSAgent, make minutes 15:28:45 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 15:28:48 RRSAgent, set logs public 15:29:08 mweksler has joined #wpwg 15:30:32 ltoth has joined #wpwg 15:32:58 mweksler has joined #wpwg 15:37:06 mweksler has joined #wpwg 15:37:54 mweksler has joined #wpwg 15:38:42 mweksler has joined #wpwg 15:39:30 mweksler has joined #wpwg 15:40:18 mweksler has joined #wpwg 15:41:06 mweksler has joined #wpwg 15:41:54 mweksler has joined #wpwg 15:42:42 mweksler has joined #wpwg 15:43:30 mweksler has joined #wpwg 15:44:19 mweksler has joined #wpwg 15:45:06 mweksler has joined #wpwg 15:45:54 mweksler has joined #wpwg 15:46:42 mweksler has joined #wpwg 15:47:30 mweksler has joined #wpwg 15:48:13 nicks has joined #wpwg 15:48:18 mweksler has joined #wpwg 15:49:06 mweksler has joined #wpwg 15:49:54 mweksler has joined #wpwg 15:50:42 mweksler has joined #wpwg 15:51:30 mweksler has joined #wpwg 15:52:19 mweksler has joined #wpwg 15:53:06 mweksler has joined #wpwg 15:53:55 mweksler has joined #wpwg 15:54:42 mweksler has joined #wpwg 15:55:30 mweksler has joined #wpwg 15:56:18 mweksler has joined #wpwg 15:56:32 mike_mastercard has joined #wpwg 15:57:06 mweksler has joined #wpwg 15:57:54 mweksler has joined #wpwg 15:58:32 stoyanstefanov has joined #wpwg 16:02:54 [nobody assembles] 16:04:19 alyver has joined #wpwg 16:04:45 topic: Implementer updates 16:05:52 adamR has joined #wpwg 16:06:14 todd_a has joined #wpwg 16:06:37 vkuntz has joined #wpwg 16:06:46 present+ 16:07:00 present + 16:07:28 [We see a demo of chrome on android ] 16:08:53 zkoch has joined #wpwg 16:09:40 rouslan: We are working on third party payment app integration 16:09:43 Present+ Katie_Haritos-Shea 16:09:45 mweksler has joined #wpwg 16:11:21 pierre has joined #wpwg 16:11:27 kriske has joined #wpwg 16:13:11 MattPi has joined #wpwg 16:14:33 q? 16:14:43 Ryladog has joined #wpwg 16:14:46 Present+ Katie_Haritos-Shea 16:15:07 present+ 16:15:08 adamR has joined #wpwg 16:16:41 MattS has joined #wpwg 16:17:04 q+ about origin from iframe 16:17:14 q+ to ask about origin from iframe? 16:17:26 q+ to ask about third party payment handlers in Cananry 16:17:44 q+ to ask about how Web Payment apps are expected to be displayed. 16:18:23 adrianHB: Where would you show the origin if payment request originates from an iframe? 16:18:26 q+ on desktop UX 16:18:49 Rouslan: We have talked to security team, and one option is to show top-level origin AND iframe origin 16:18:59 ...we are not sure what the value is to the user of seeing the iframe origin 16:19:25 q+ 16:20:53 marcos: how do you prevent forgery? 16:21:00 rouslan: Safe browsing initiative. 16:21:14 ...user can override, but currently payment will not work if overridden 16:21:29 zkoch: Very hard to make an unspoofable UI in mobile...we accept that and have other mitigations in place 16:21:58 ...users not aware of differences 16:22:25 [IOS implementation] 16:22:28 q? 16:22:33 ack AdrianHB_ 16:22:33 AdrianHB_, you wanted to ask about origin from iframe? 16:23:10 rouslan: We have an early IOS implementation; no flags; you need to do a build 16:23:18 q? 16:23:36 nicktr: Can you used third party web-based payment apps with canary yet? 16:23:43 Tommy has joined #wpwg 16:23:46 Rouslan: You can do it on android with android native payment apps 16:23:49 ..if you flip a flag 16:24:00 marcosc has joined #wpwg 16:24:01 ...you cannot do anything sensible yet on web-based payments 16:24:08 AdrianHB_: There is also Tommy's modified build 16:24:09 dick has joined #wpwg 16:24:11 q? 16:24:15 q+ on flags for desktop 16:24:16 ack nick 16:24:16 ack nicktr 16:24:17 nicktr, you wanted to ask about third party payment handlers in Cananry 16:24:20 ack manu 16:24:20 manu, you wanted to ask about how Web Payment apps are expected to be displayed. 16:24:30 Manu: What is the experience anticipated for web apps? 16:24:44 Rouslan: Web app will define one or more instruments 16:25:14 q? 16:26:49 zkoch: We are working on concepts 16:27:08 Manu: We used a polyfill looks like what rouslan has 16:27:18 ...but the "danger" is whether you add credentials into a spoofed window 16:27:55 Rouslan: Safe browsing initiative should help us out as well with spoofing issues 16:27:56 ack Mah 16:27:56 MaheshK, you wanted to comment on desktop UX 16:27:59 ack MaheshK 16:28:01 q? 16:28:08 Mahesh: Your desktop UI did not ask for CVV. 16:28:17 Rouslan: It does. I didn't show it in the demo. 16:28:24 q? 16:28:36 Mahesh: For the IOS...the view? 16:28:49 Rouslan: Objective C native interface 16:28:59 ...we have a fullscreen overlay that hides everything when you are making your payment 16:30:04 zkoch: There are strange things that happen with polyfills.... 16:30:13 I think iframe support may be challenging at the beginning 16:30:19 q+ to ask if the "polyfill" is only for native payment apps right now. 16:30:26 ack fdold 16:30:27 q? 16:30:28 ...we are trying to work through it but may need to limit at the beginning 16:30:38 florian: What about click jacking protection? 16:30:52 marcosc_ has joined #wpwg 16:31:10 rouslan: Not part of the spec, but something we are looking at. We use 400-500ms delay as an example. What do you think? 16:31:15 Florian: Page can be in the background. 16:31:19 jeff has joined #wpwg 16:31:23 ...so it needs to be a "delay while the window is in focus" 16:31:26 rouslan: Makes sense 16:31:37 florian: What prevents merchant JS from clicking the button 16:31:51 rouslan: It's objective C; merchant cannot access it 16:31:54 q? 16:32:43 rouslan: One thing that's interesting in IOS is that it's completely accessible ... so we don't trust the JS...we inject into objective C and validate there 16:32:55 ...merchant doesn't have access there so we trust it more 16:33:23 IJ: Why different from today? 16:33:34 Florian: Risk goes up if it's a one-click process 16:33:41 Q? 16:33:43 Rouslan: There's definitely a trade-off 16:34:11 zkoch: Right now in Chrome, you can't end up in this scenario 16:34:27 ...if a payment app goes down the route of 1-click or no-click, this is a risk that you assume. 16:34:42 Max has joined #WPWG 16:34:43 q+ 16:34:53 ...I think to go to a UI-less payment flow exposes you to this vulnerability, but you are forced into the UI. 16:35:04 Florian: My concern is tricking the user into clicking 16:35:44 q? 16:35:46 Zkoch: We talked about this in our issue about deconstruction. I think our proposals mitigate this risk; please check out the issue 16:35:50 ack oyiptong 16:35:50 oyiptong, you wanted to comment on flags for desktop 16:35:59 oyiptong: Can you show me the flags that you need to show for desktop 16:36:05 chrome://flags 16:36:08 Experimental web platform features 16:36:11 Web Payments 16:36:14 https://github.com/w3c/webpayments/wiki/FTF-March2017 16:36:16 ack manu 16:36:16 manu, you wanted to ask if the "polyfill" is only for native payment apps right now. 16:36:24 (you can’t link to chrome:// pages, so you’ll have to type in manually) 16:36:28 Ken has joined #wpwg 16:36:36 manu: You said there's an objective C polyfill.... 16:36:48 Rouslan: The polyfill is JS that calls into Objective C on ISO 16:36:51 s/ISO/IOS 16:37:00 ..there are no native payment apps in IOS 16:37:22 zkoch: We only do stored cards for Chrome on IOS 16:37:24 q? 16:37:38 ack Max 16:37:59 Max: Do you implement canMakePayment()? 16:38:15 rouslan: Yes 16:38:39 world deployments, at times the user installs Alipay as an android app, and sometimes they don't 16:38:56 ...when the user installed Alipay we want the API to invoke it 16:39:11 ...if the user doesn't install Alipay, we want browser to use Web app 16:39:21 Rouslan: Doesn't work currently but a great implementation idea 16:39:22 q? 16:39:23 q? 16:39:43 [From the trenches] 16:39:58 Rouslan: There have been questions about adding new card network identifiers 16:40:33 ...questions - should we distinguish global from country-specific? 16:40:37 ...how to reduce friction? 16:42:32 https://www.w3.org/Payments/card-network-ids 16:43:05 q? 16:43:22 Rouslan: Chrome security team may push back on arbitrary string matching 16:43:48 ...but the preference is to strictly parse and when doesn't match a known string we throw it away 16:43:49 q+ to ask about limit charset or regex 16:44:00 ...so right now people need to do a pull request on chromium project. 16:44:20 adamR: Can you be more confident with a regexp? 16:44:25 Rouslan: No, more of an enum. 16:44:53 q- 16:44:57 ...restrictions are a point in your favor, e.g., max length no numbers, etc....we might do that. 16:45:49 kird has joined #wpwg 16:45:51 q? 16:46:10 IJ: This is the first time we've heard that "there might be a way" 16:46:24 Rouslan: Web payment app spec is in flux; please join the task force! 16:46:26 (IJ: +1) 16:46:38 +1 16:46:52 Rouslan: One thing we have encountered in early versions of payment request API was that it was vague and additional review was valuable 16:47:00 ...so we have appreciated the additional details in the spec! 16:47:31 ...another point that echoes that is that the spec does not always restrict the shape of data that would make it easier for merchant to communicate with any browser in the world. 16:47:40 (e.g., phone number formats) 16:48:04 ...I believe we agreed eventually to use an IETF format. I think restrictions like this are very useful for merchant web sites to be sure to get data in the form that they expect 16:48:18 +q 16:48:20 mathp has joined #wpwg 16:48:46 (we’re about halfway through, so just want to make sure that we get to Roy) 16:49:02 IJ: Can you write the spec in a way where there are benefits if you do something one way, but some flexibility 16:49:12 ack marcosc_ 16:49:15 Rouslan: Mozilla proposed that....but we want to push in a particular way 16:49:32 Marcos: It helps to have an agreed to standard, but may be useful to to have the flexibility 16:49:46 Marcos: It would be useful to hear back from people on formatting of labels 16:50:03 I don't think that the spec actually specifies the phone number format - can someone point me to where it does? 16:50:11 ...in Mozilla's prototype the "USD" is on the other side of what Google displays 16:50:18 q+ 16:50:22 q? 16:50:35 ...for additional consistency, it would be helpful to provide guidance to developer on how to display labelos 16:50:39 adamR has joined #wpwg 16:51:01 q+ 16:51:31 NickS: Guidance makes sense; would not put requirements in the spec. In some cases you may default to the OS 16:51:40 q+ to ask about capturing user data outside this flow and formatting it 16:51:47 ack nicks 16:52:01 (IJ adds notes to the dev portal to return to this later: https://github.com/w3c/payment-request-info/wiki/DeveloperGuides ) 16:52:08 ack adamR 16:52:40 adamR: If we don't go down the path of phone number normalization, it's a fast path to 'works best with' 16:52:54 Marcos: Challenge is legacy contact apps where that info is being pulled from 16:52:56 AdamR: There is an IETF guidance 16:53:01 Marcos; We point to that in the spec as a SHOULD 16:53:20 GuyB has joined #wpwg 16:53:25 NickS: It may be impossible for the browser to make a determination about the format (e.g., if user puts in number without a country code so format unknown) 16:53:32 ...we make a best guess 16:53:34 q? 16:53:35 ack AdrianHB_ 16:53:36 AdrianHB_, you wanted to ask about capturing user data outside this flow and formatting it 16:53:37 ack AdrianHB_ 16:53:58 AdrianHB_: You clearly want to use a bunch of existing data ... is there a solution where you return the data in a format, with a flag that indicates the format? 16:54:04 Spec says: "When setting the payerPhone value, the user agent should format the phone number to adhere to [E.164]" 16:54:10 (IJ thinks "mime type") 16:54:27 AdamR: You mostly get that by seeing a "+" at the start of the string 16:54:35 AdrianHB: What about addresses or other data than phones? 16:54:45 AdrianHB_: Does the response indicate the format of the data? 16:54:47 Rouslan: Not yet 16:55:15 MattPi has joined #wpwg 16:56:22 q? 16:56:53 [Roy on FB experience] 16:57:00 Roy: We'll see a demo in a moment 16:57:04 ...here's what we have done: 16:57:19 ...implement PR API in FB SDK...it overrides the default PR API implementation in the web vie 16:57:28 ...implements a proprietary FB payment method that does tokenization 16:57:44 ...our app can return tokenized cards AND process payments; depends on merchant configuration in our system 16:58:08 ...our implementation was fairly smooth 16:58:15 ...we moved from our custom API to PR API! 16:58:16 q+ to ask Roy about push payments 16:58:41 ....we are running the test suite as well (and pass all the tests) 16:58:51 nicktr: You said that your implementation can do both pull and push payments 16:58:51 q+ 16:59:12 ack nick 16:59:12 nicktr, you wanted to ask Roy about push payments 16:59:17 nicktr: Any new needs based on your push implementation experience? 16:59:27 roy: "id" is very useful. 16:59:32 ...right now we are not yet doing third party apps 16:59:51 q? 16:59:54 q+ 17:00:16 q+ on demo 17:00:25 alan: "ID" is of interest to payment schemes. 17:00:47 vkuntz has joined #wpwg 17:00:50 present+ 17:00:56 ...can ID be an order number? 17:01:21 roy: I think we have this covered. 17:01:36 ...ID field is part of the details that go to the payment app 17:01:59 cweiss has joined #wpwg 17:02:27 AdrianHB: Yes, ID flows through to payment app 17:02:28 q? 17:02:35 q+ rouslan 17:02:38 ack alan 17:02:42 IJ: Yes, that's in the spec (but I see some legacy use of paymentRequestID rather than ID) 17:02:43 ack matt 17:03:03 q? 17:04:19 ack mahesk 17:04:26 ack MaheshK 17:04:26 MaheshK, you wanted to comment on demo 17:05:24 Rouslan: Do you support shipping physical goods? 17:05:30 Roy: We just do digital goods I think 17:05:40 Stoyan: You can ship things 17:05:43 q? 17:05:45 ...FB doesn't but merchant can 17:05:54 Stoyan: Right now implemented on Android and IOS 17:06:04 ack rouslan 17:06:04 topic: Demos 17:06:13 [Stoyan Stefanov to demo FB implementation] 17:06:26 rouslan has joined #wpwg 17:07:38 q+ to ask about availability of tutorials 17:09:51 q+ to ask about merchant experience 17:10:27 q+ 17:10:32 [stoyan shows code; indicates it works end to end] 17:10:46 ack rouslan 17:10:46 rouslan, you wanted to ask about availability of tutorials 17:10:50 q? 17:10:53 rouslan: Is there a use case where the FB user cannot make payments? 17:10:55 q+ 17:11:14 q+ 17:11:18 stoyan: canMakePayment() is more about merchant checking to see whether the FB app supports the API 17:11:31 Roy: there are also some use cases about payments in certain countries 17:11:48 Rouslan: What should merchant do when canMakePayment() returns false? 17:11:49 q? 17:11:55 Stoyan: We fall back to traditional web form for card data 17:12:03 q+ 17:12:13 Stoyan: Even though we have card data, we don't share that with data. We only return token. 17:12:22 Rouslan: Do you have documentation on how to integrate? 17:12:24 Stoyan: Not yet 17:12:26 q? 17:12:38 Roy: We will should when it's available. 17:12:48 s/share that with data/share that with merchants/ 17:12:56 (IJ asks for the link to documentation when available to dev portal) 17:13:10 nicktr: How does the merchant know they got paid in the push payment case? 17:13:26 Stoyan: In the payment response there's an ID and also an identifier from the processor. 17:13:38 ...so, e.g., Stripe gives you an identifier that the merchant can use to poll Stripe for status. 17:14:20 q? 17:14:23 ack nicktr 17:14:23 nicktr, you wanted to ask about merchant experience 17:14:28 q+ 17:14:28 ack zkoch 17:14:30 (IJ thinks this aligns with our previous expectation that the merchant would query the merchant or vice versa and that the payment service provider determines which to do) 17:14:32 q+ 17:14:49 zkoch: At some point do you imagine removing FBextensions and moving to PR API? 17:15:01 stoyan: Yes, and I had to do that to pass the W3C tests 17:15:40 zkoch: So it "just works" by showing payment method identifiers because implementations ignore then ones they don't pay attention to. 17:15:48 Zkoch: Please use URL for your identifier 17:15:51 q? 17:15:51 Ian: +1 17:16:00 +1 to URL for PMI 17:16:13 Roy: I like Zach's observation that the right thing happens via payment method matching 17:16:43 Stoyan: One note - we had an event called "checkout cancel" in our API; we haven't found a corresponding event in PR API. 17:16:47 Marcos: We have "abort" 17:17:16 Rouslan: Show() promise resolves with an error that you can use; this is a new feature 17:17:34 rouslan: Please file an issue if you need a more specific error message 17:18:26 Stoyan: As a merchant you may want to know that you had a thing in a shopping cart and maybe you get a discount if you come back tomorrow after aborting your carty 17:18:29 s/carty/cart 17:18:51 Marcos: Look at the user abort algorithm 17:19:04 zkoch: I think this is the only situation.... 17:19:13 Adrian: There is more than one place where you throw an abort error 17:19:30 q? 17:19:34 zkoch: There is merchant explicit abort and user abort; we can disambiguate between the two 17:19:43 going to close the queue in 2 minutes 17:19:46 q- 17:19:47 marcos: But a merchant who initiates the abort already knows 17:19:53 ...so there's really one use caser 17:19:53 q? 17:19:53 q? 17:19:55 zkoch: So you can know. 17:19:57 ack nicks 17:19:58 s/caser/case 17:20:22 nickS: Is the intent that if you were running on a platform that supports payment handler you would support it? 17:20:49 NickS: Is it possible that, e.g., you could do card on file? 17:21:01 Roy: E.g., operating as a card payment supporting app? 17:21:14 q? 17:21:15 ..we can't do that in our implementation; we have stronger security requirements; we need the merchant's id 17:21:23 ack Max 17:21:35 q- 17:21:44 max: who gets the card number? 17:22:02 Roy: merchant only gets token; not raw PAN 17:22:02 q? 17:22:16 ack Ryladog 17:22:22 katie: Do you have any funds limitations? 17:22:28 q+ 17:22:30 Roy: I don't know of any practical limitations 17:23:44 IJ: Fund limitations are not relevant to the API; these can be addressed in payment systems or developer guidance 17:23:46 Todd: +1 17:23:55 AdrianHB: The transaction will just fail (at other parts of the flow) 17:23:58 q? 17:24:01 ack MattS 17:24:22 MattPi has joined #wpwg 17:24:22 MattS: Have you looked into race conditions regarding push payments? 17:24:35 ...there's a possibility that the merchant can abort payment 17:24:40 Roy: That's where the ID comes in 17:24:47 ...so you can use it to reconcile 17:24:58 MattS: Do you want the ability to block abort while processing? 17:25:27 Stoyan: Not in the abort implementation. But there is a message in our implementation. 17:25:48 Stoyan: Abort or app crash or battery dies are similar use cases 17:26:30 q+ 17:26:41 q+ michelw 17:27:05 mattS: I think that you should be able to change state to "processing" and block during that time 17:27:10 AdamR: But network could time out 17:27:11 nicks has joined #wpwg 17:27:21 zakim, close the queue 17:27:21 ok, nicktr, the speaker queue is closed 17:27:28 MattS: I can raise an issue and propose something 17:27:38 zkoch: We have a note in the spec that "abort" cannot necessarily be enforced 17:27:39 s/and block during that time/and block calls to abort() during that time/ 17:27:48 q- 17:28:09 q? 17:28:17 MattS: I see there is a provision in the spec; probably good to mention this explicitly 17:28:26 q? 17:28:28 AdamR: I am hearing zach say that this is implementation dependent 17:28:48 roy: I can see it being useful to add a value 17:28:53 AdrianHB: What are the use cases? 17:29:04 NickTR: Question is whether we need a state between "interactive" and "state"...e.g., "processing" 17:29:16 q+ 17:29:32 mathp has joined #wpwg 17:29:38 IJ: It's just information, right, not a requirement for a particular use experience? 17:29:44 q+ 17:29:51 q? 17:29:52 Tommy has joined #wpwg 17:29:54 ack mich 17:30:12 michel: Larger point - this is a distributed system 17:30:22 ...we can't always know what's happening 17:30:39 ...trying to abort a payment while it's happening elsewhere; by definition you can't do that AND have a consistent response. 17:30:46 ...is there support for idempotency? 17:30:58 ...how are retries handled? 17:31:33 AdrianHB_: In my opinion we do support that; abort and show are functions of the payment request. So we can abort the payment request, which tells the browser "give me back control". You have the "id" 17:31:46 ...so you can try a new payment request with the same ID and hope that the processor recognizes it as a retry 17:31:59 ...but we can't make any promises in the browser that the PSP supports idempotency 17:32:06 ...so we have "what we need" but can't provide guarantees 17:32:16 NickS: We don't need to make guarantees, but there are two types of abort 17:32:35 ...payment apps still need to be able to handle aborts (e.g., if page dies) 17:32:51 ...so I definitely think that payment apps should have a state where they can abort. 17:33:26 q? 17:33:33 [Lunch] 17:33:36 RRSAgent, make minutew 17:33:36 I'm logging. I don't understand 'make minutew', Ian. Try /msg RRSAgent help 17:33:38 RRSAgent, make minutes 17:33:38 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 17:33:46 RRSAgent, set logs public 17:34:14 thanks from the chairs for the presentations from Zach, Rouslan, Roy and Stoyan 17:42:08 stoyanstefanov has joined #wpwg 18:05:23 stoyanstefanov has joined #wpwg 18:14:58 cweiss has joined #wpwg 18:18:36 canton_ has joined #wpwg 18:18:36 pea13 has joined #wpwg 18:21:15 nicks has joined #wpwg 18:26:06 MattS has joined #wpwg 18:26:34 rouslan has joined #wpwg 18:27:06 Max has joined #WPWG 18:28:26 mike_mastercard has joined #wpwg 18:28:58 mweksler has joined #wpwg 18:29:45 mweksler has joined #wpwg 18:35:46 alyver has joined #wpwg 18:38:59 topic: Demo from Samsung 18:39:25 scribe: manu 18:39:30 Tommy has joined #wpwg 18:39:47 Allan: This is the SamsungPay demo... first step install the Pay Application 18:39:59 Allan: Big thanks to shopify for enabling this, Andre thank you. 18:40:42 Allan: There is a special website up there, I'm going to hit "Buy Now"... add items to cart, check out 18:41:12 Allan: When I click check out, see payment sheet, use payment request, select shipping address. 18:41:33 m_and_m has joined #wpwg 18:42:14 Allan: I can click on pay button, since I selected all items merchant wanted. Samsung pay comes up, I enter my PIN or fingerprint, then that completes the payment, notification at top, lots of round trips took place. 18:43:06 zkoch has joined #wpwg 18:43:08 Allan: Merchant submits to Visa, pull down certification, launch me into Samsung Pay, Visa card network submission, gave back response to merchant saying payment was ok, then notification comes back in a different channel, so user can see verification in both places. 18:43:13 q? 18:43:25 NickS: Is the UI yours or chromium's? 18:43:33 Manesh: Samsung's browser 18:43:58 kriske has joined #wpwg 18:44:01 Samsung pay has tokenized DPAN/Crypto 18:44:36 vkuntz has joined #wpwg 18:44:43 present+ 18:44:53 q? 18:44:54 Allan: Yes, trust zone based auth takes place, that's used w/ keys from issuers keys, cryptogram is created, passed back... then tokenized payment is decrypted, and submitted w/ cryptogram 18:45:00 Ken: Timeline that you can share? 18:45:03 Allan: Soon. 18:45:22 Manash has joined #wpwg 18:45:31 Ian: We'd like to link to implementation stuff, developer docs/portal, when it's available, we'd like to hear about it. 18:45:42 AdrianHB: What kind of method identifier are you using? 18:45:56 Allan: spay.samsung.com 18:46:12 Manash_ has joined #WPWG 18:46:12 Allan: We'll publish a payment manifest file... 18:46:26 AdrianHB: That would limit it to Samsung Pay? 18:46:32 pierre has joined #wpwg 18:46:32 Allan: Yes 18:46:52 Topic: Demo from WorldPay 18:47:33 dick has joined #wpwg 18:47:38 nicktr: My innovation team has put this demo together, tech demonstrator, show it to product teams/merchants, exec committee, etc. 18:48:00 nicktr: I'm showing you the experience when you have native and web apps, going to check out 18:48:37 nicktr: Here's the payment sheet, we have a web app worldpay online (web app), android pay (worldpay Android native app) 18:49:02 nicktr: Native experience, no auth, native app, select pay, submits to test platform, transactions occur. 18:49:59 nicktr: For a web app, here's the experience... pick worldpay online... calls service worker, moves to web page, no auth, pay now, transaction occurs. 18:50:19 nicktr: User experience is consistent - payment app is consistent, down to implementation... 18:50:31 nicktr: When they see payment experience is consistent, that they get. 18:51:00 AdamR: Is the serviceworker implementation a complete implementation? 18:51:12 nicktr: It's Tommy's polyfill. 18:51:42 Tommy: It's a bit of a hack, but it goes through actual service worker. 18:52:28 Topic: Alibaba Demo 18:52:29 q? 18:52:42 Max: Hi, I'm from Alibaba, this is our demo - updated our demo. 18:53:07 Max: We use the manifest file for this... right side is the browser, working w/ Google, thanks Rouslan/Zach for the help. 18:53:18 Max: In the source code, here is the payment method, Alipay.com 18:53:45 Max: We have payment method related information, we have payment request API to invoke the payment method. 18:54:09 Max: When I click buy, alipay native app comes up, we can choose different methods in alipay, support credit cards. 18:54:41 Max: We can use fingerprint for authentication, payment is done. 18:55:28 Max: Payment manifest, we put that in alipay.com. When I push pay button, they get manifest, here's the JSON data ... note the fingerprint, browser can use that fingerprint to verify. 18:55:49 Max: The latest proposal, we put that information in a different web app manifest, we'll talk about this tomorrow in detail. 18:56:07 q? 18:56:12 Zach: That was standard chrome, 18:56:16 nicktr: Native ali pay app? 18:56:18 Max: Yes. 18:56:56 Max: When the merchant only has one payment method configured, we can just directly show only configured payment method. When I clicked buy button, only Alipay would work. 18:57:21 Ian: That conversation has come up before, when there is only one match, you consider doing it. 18:57:49 Zach: In chrome dev channel, if you call paymentrequest with one method, no additional features, the UI in the middle adds no value. Only thing you can do is click next. 18:58:16 Ian: If I store a credit card in the browser, when I click buy, I enter CVV (prompted)? 18:58:42 Zach: Third party payment app, URL identifier, search system, system has that device on there. 18:58:57 Allan: One less click for the user, it does create a different user experience. 18:58:58 Manash has joined #WPWG 18:59:06 MaheshK has joined #wpwg 18:59:08 Allan: We've talked about that internally. 18:59:19 q+ what features of PaymentRequest shouldnt be used? 18:59:24 Zach: It's a concession to reality, if ultimate goal is payment request is reduce Nascar question. 18:59:30 zakim, open the queue 18:59:30 ok, manu, the speaker queue is open 19:00:05 CyrilV has joined #wpwg 19:00:09 q+ what features of PaymentRequest shouldnt be used? 19:00:18 q+ 19:00:40 ack MaheshK 19:00:53 Zach: I think you'll see "Pay with X" buttons, not generic checkout buttons, we need to make the case to add more things to payment apps list over time. 19:01:12 Mahesh: There is an alternate way of using this, we should spec that. 19:01:32 Zach: Not sure I agree, this is a UX decision. From spec perspective, nothing is changing. 19:01:32 kiird has joined #wpwg 19:01:45 Ian: Should we make it easier for people per domain? I always use Visa on this domain? 19:02:14 Zach: We have no current plans around that. Difficult from perspective, tricky agreements in place, payments at providers would not be happy... 19:02:43 Allan: There is an emerging tension between browser and app itself... Samsung Pay, functionality in in-app SDK that enables collection of shipping address. 19:03:10 ... there is overlap there, we may want to evolve the spec to expose how much functionality it has, so optimal path can take place... not sure. 19:03:22 q? 19:03:26 Topic: Microsoft Demo 19:03:52 Molly: We have early windows releases in windows insider... this is our demo site, microsoft edge. We have a payment request demo 19:04:00 Ian: This is pubic? 19:04:41 Matt: Anyone can access this. 19:05:04 Molly: This opens up Microsoft Wallet, kick off payment request. Shows up changing shipping address. 19:05:31 Matt: What we see here, it's a signed in experience, opt-in page for wallet. Giving awareness that you're using Microsoft Wallet. 19:05:51 s/pubic/public/ 19:06:26 Matt: We always require CVV, we're w orking on security, so we'll reauthenticate... dabbling with these. 19:07:14 Matt: This is available on insider builds now, this is a good guide to see how different interactions will work. 19:07:47 q? 19:07:49 Ian: Any public statements on release? 19:08:03 q+ 19:08:18 Matt: Nothing firm, next quarter or the one after. 19:08:19 frank has joined #wpwg 19:08:25 q+ 19:08:31 q+ 19:08:39 ack MaheshK 19:08:41 Mahesh: What part of that was native app? 19:09:03 Matt: This wallet is a native app, but what's rendered inside is our website. 19:09:18 ack frank 19:09:23 Frank: What's support for 3rd party payment apps. 19:09:47 Matt: We're focused 100% on Payment Request, focus on basic card, looking at payment handlers. 19:10:00 ack adamR 19:10:02 Matt: Similar to approach to Zach/Google is taking, we have proprietary platform features... 19:10:17 AdamR: This is basic card right now, tokenized scheme, plan to use it? 19:10:24 Matt: MSDN docs, there are tokenized schemes/payment methods. 19:10:50 Ken has left #wpwg 19:11:24 ken has joined #WPWG 19:11:39 Topic: Gemalto Demo 19:12:24 MattPi has joined #wpwg 19:12:52 Pascal: This demo was meant for internal demo purposes, Gemalto has a mobile financial services demo. Produce SDK for bank/financial institutions. The idea that I'll show you, implementation of creating new web payment app, and use it through payment request API, using Tommy's polyfill. 19:14:21 Pascal: I have a small demo website, the idea is to show details of implementation and let them understand what types of information exchanges between browser/app. Full process we've implemented. If you dont' do anything special what you have is only the payment moethods included into your wallet. 19:15:20 Pascal: But, if the merchant is about to enter other payment method, opportunity to install it, you can register payment method, credit transfer payment... enter details for this payment method... then install payment app. 19:16:00 Pascal: I can go back to merchant website, when add items to cart, then it shows my credit transfer method. 19:17:04 mathp has joined #wpwg 19:17:22 Pascal: I include tax/shipping information, it shows up, selecting new shipping method, SEPA information is displayed on payment app, I accept, payment happens and I go back to merchant. 19:17:28 q? 19:17:35 Pascal: These were web-based payment methods. 19:18:56 Ian: How many people have played around w/ writing payment apps. 19:19:01 10-ish people raise their hands. 19:19:37 Topic: EMVCO Update 19:20:04 stoyanstefanov has joined #wpwg 19:20:09 nicktr: We've been talking w/ EMVCO on Web Payments - WorldPay is an associate of EMVCo, we pay to be an associate... EMVCo is a standards body that do chip card standards. 19:20:40 ltoth has joined #wpwg 19:20:52 nicktr: The apps that sit on the card, certification process, communications, EMV standards - tokenization standard, Apple Pay, Android Pay, they are network tokens. Implemented EMVCo specification. 19:21:12 nicktr: 3DSecure specification.... 19:21:50 nicktr: It's not open, closed organization, so we have to be careful about what we're saying, speak in generalities. 19:21:56 https://www.emvco.com/ 19:22:34 ken: This is mostly 6 members, align on card specifications, terminal specifications, and then come up with other standards around comms, specification, contactless, alignment, mobile standards, tokenization standards for issuers. 19:23:03 nicktr: We've been trying to work w/ EMVCo - that conversation is ongoing, but complicated, fruitful, different in ethos between W3C and EMVCo. 19:23:24 nicktr: EMVCo doesn't operate like that, builds specs internally and then publishes, we're trying to have those conversations now. 19:24:14 nicktr: They have not made any information public yet on how they're thinking about this. Security is at cornerstone of what EMVCo does. That's where input will come from. 19:24:38 nicktr: We need to be patient about timescales. Over the course of this year, we'll make progress, can't talk about time scales yet. 19:24:43 nicktr: Watch this space. 19:25:06 q? 19:25:31 q+ 19:25:40 ack nicks 19:25:45 Ken: Part of American Express joining W3C is to bring value. We support building relationships between existing standards bodies that can add value, EMVCo and PCI, we're behind trying to help foster a healthy relationship between all of these organizations. 19:26:26 NickS: How does not being able to talk about EMVCo's process work w/ W3C Process. 19:26:36 Ian: There is a good faith effort going on right now on working together. 19:26:54 marcosc has joined #wpwg 19:27:11 Ian: I had a chat with PCI, what are the PCI DSS implications. I talked w/ them, updated FAQ on developer portal. 19:27:47 FAQ -> https://github.com/w3c/payment-request-info/wiki/FAQ 19:28:14 PCI -> https://www.pcisecuritystandards.org/ 19:28:16 Ian: What does this mean for PCI DSS compliance? Probably nothing, but I have a meeting in two weeks to get official analysis from them. For large merchants, there is a requirement to look at code. You will need to undergo PCI... it happens when you have data, not when you got the data. 19:28:50 Ian: There is a FAQ wrt. collecting data outside of transaction and what to do. Mostly to say that we've started a good conversation. 19:29:22 Ian: I was invited by European Central Bank, regulatory theme was predominant yesterday, getting regulatory parties involved. Finnish engineers at ECB want to read specs, that's a good conversation. 19:29:23 marcosc_ has joined #wpwg 19:29:42 adamR has joined #wpwg 19:29:57 Ian: We've been talking w/ NACHA - goal of W3C specs is to make front-end development easier, only useful if they're useful different credit card systems / credit transfer systems. 19:30:39 Ian: Our goal is to come up with a common set of fields, ask NACHA if what we have would work for them... they have ISO20022 fields, Todd has a document, we need to engage with credit transfer stuff. 19:30:49 Ian: We're doing our due diligence. 19:31:14 Ian: Atos is going to get more involved. 19:31:26 Cyril: They're a "French WorldPay" 19:31:50 Ian: We're having bigger conversations w/ MAG, those are ongoing. 19:32:56 q+ 19:32:59 nicktr: There has been a huge consultation process around PSD2... this capped interchange rates, etc.... new focus on authentication, and restructuring. 19:34:00 nicktr: There are significant changes that this group needs to be aware of, looks like increased usage of two-factor authentication. I'm hesitating to say where it's going to land, still not done, EU Parliment delegated power to ECB, being reviewed by European Commission now.. then needs to be accepted by European Parliment. 19:34:52 nicktr: The direction of travel is, frictionless/invisible payments are going to be challenging to do... UI going straight through is going to be hard to do, low transaction limits, amount is same every month, those will be exempt... but in general, you will have to authenticate. 19:35:19 https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+(EBA-RTS-2017-02).pdf 19:35:32 ^^^^^ FINAL REPORT ON DRAFT RTS ON SCA AND CSC 19:35:46 nicktr: There is a strong regulatory direction - our architecture works well for that... demo from Pascal, shows how payment experiences might land. 19:36:07 q- 19:36:17 nicktr: We've talked about W3C specs as standards that those groups should pay attention to. 19:36:17 q? 19:37:01 rrsagent, make minutes 19:37:01 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html manu 19:37:03 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 19:37:40 stoyanstefanov has joined #wpwg 19:38:02 adamR has joined #wpwg 19:38:03 mweksler has joined #wpwg 19:38:11 Final draft is here: -> https://www.eba.europa.eu/documents/10180/1761863/Final+draft+RTS+on+SCA+and+CSC+under+PSD2+%28EBA-RTS-2017-02%29.pdf 19:38:52 mweksler has joined #wpwg 19:39:40 mweksler has joined #wpwg 19:40:00 alyver has joined #wpwg 19:40:25 mweksler has joined #wpwg 19:41:15 mweksler has joined #wpwg 19:42:03 mweksler has joined #wpwg 19:42:46 mweksler has joined #wpwg 19:43:20 mweksler has joined #wpwg 19:43:55 alyver has joined #wpwg 19:44:25 mweksler has joined #wpwg 19:45:02 mweksler has joined #wpwg 19:45:53 mweksler has joined #wpwg 19:46:50 mweksler has joined #wpwg 19:47:39 mweksler has joined #wpwg 19:48:25 mweksler has joined #wpwg 19:49:15 mweksler has joined #wpwg 19:49:19 Max has joined #WPWG 19:50:03 mweksler has joined #wpwg 19:50:51 mweksler has joined #wpwg 19:51:40 mweksler has joined #wpwg 19:52:25 mweksler has joined #wpwg 19:52:45 nicks has joined #wpwg 19:53:16 mweksler has joined #wpwg 19:54:04 mweksler has joined #wpwg 19:54:52 mweksler has joined #wpwg 19:55:40 mweksler has joined #wpwg 19:56:25 mweksler has joined #wpwg 19:57:16 mweksler has joined #wpwg 19:58:04 mweksler has joined #wpwg 19:58:52 mweksler has joined #wpwg 19:59:40 mweksler has joined #wpwg 20:00:25 mweksler has joined #wpwg 20:01:16 mweksler has joined #wpwg 20:02:04 mweksler has joined #wpwg 20:07:29 fdold has joined #wpwg 20:09:26 stoyanstefanov has joined #wpwg 20:09:45 Manash_Mastercard has joined #WPWG 20:17:42 adamR has joined #wpwg 20:19:07 mweksler has joined #wpwg 20:19:37 marcosc_ has joined #wpwg 20:19:49 alyver has joined #wpwg 20:20:01 topic: Payment Apps Update 20:20:19 Slides: https://www.w3.org/2017/Talks/ij_apps_201703/adamr-20170323.pdf 20:20:22 scribe: Ian 20:21:07 dick has joined #wpwg 20:21:22 MattPi has joined #wpwg 20:21:44 AdamR: My main goal is to bring people up to speed to participate in the conversation tomorrow (Ian's presentation on issues) 20:21:51 [Adam reviews primary changes to the spec] 20:22:02 Payment Handler API -> https://w3c.github.io/webpayments-payment-apps-api/ 20:22:13 Tommy has joined #wpwg 20:22:17 alyver has joined #wpwg 20:22:43 (IJ plans to not scribe what is on the slides; will focus on other comments & questions) 20:22:56 zkoch has joined #wpwg 20:23:34 (Text around instrument display) 20:23:57 Max has joined #WPWG 20:25:02 q? 20:25:43 serviceWorkerRegistration.PaymentManager.instruments 20:26:20 (slide 5 shows code) 20:27:07 (slide 6 shows permission request by site -> do you let me handle payment requests?) 20:27:17 q+ 20:27:34 AdamR: We'll talk more about permission requests tomorrow 20:28:49 Michel: Registration of a web based payment app is analogous to a plugin installation 20:29:14 vkuntz has joined #wpwg 20:29:21 present+ 20:29:25 ack me 20:29:52 m_and_m has joined #wpwg 20:30:49 Marcos; Same idea as for things like geolocation 20:31:21 Alan: I have some concerns about how permissions are presented 20:31:40 AdamR: Agree this is an important topic; this demo is just a hint at the direction 20:33:37 AdamR: Different ways that logos and icons can be brought in to display app information in the sheet 20:33:47 ..including app manifest and link/meta info 20:33:53 q? 20:34:11 michel: Registration seems to be something that happens once, early on 20:34:22 q+ 20:34:38 AdamR: The payment app is associated with an origin, and it's up to the origin to keep the app up to date 20:34:58 ...apps that are updated have permission and don't have to ask for it again if they update their capabilities, or if the user adds instruments 20:35:05 CyrilV has joined #wpwg 20:35:13 present+ 20:35:20 ...I also understand that there's an update mechanism of service workers. So service worker can help keep the app up-to-date 20:36:12 q+ 20:37:04 dick: Can the user pick a friendly name instead of ***4322"? 20:37:10 AdamR: That's an implementation choice. 20:37:37 q? 20:37:47 NickTR: I think of this as being a site-specific feature...you can add/remove instruments and also provide friendly names 20:37:48 ack dick 20:37:56 ...so that the friendly name is REGISTERED rather than the default 20:38:06 Tommy has joined #wpwg 20:38:43 zkoch: Chrome today does not provide the friendly alias functionality 20:39:03 AdamR: WE've heard that art work is an important feature 20:39:46 Marcos: We have a data structure for cards. Not sure if we can reuse the information; would be nice to consider 20:40:14 q? 20:40:58 IJ: Also easier to add new cards and update card data easily due to finer grain API 20:41:01 ack me 20:41:11 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 20:41:48 AdamR: Set operations have keys associated with them....payment instruments can use those keys to appear in wallets 20:42:02 ...key format is up to payment app provider 20:43:14 ...tomorrow we will talk about the user's ability to select instruments directly from the browser chrome, or whether selection is at the level of the app 20:43:57 q? 20:47:01 [Client open window] 20:47:12 AdamR: Moving in direction of a payment-specific open window event 20:47:40 Ian: A nice reason to do this can improve on user experience that we have today. This is a significant usability win. 20:48:08 q+ 20:48:13 ...and experience can change based on screen dimensions 20:48:18 Katie: Make sure focus moves to that window 20:48:29 Marcos: Chrome's implementation does this and others will 20:48:33 ack fdold 20:48:40 fdold: How would navigation be handled? 20:49:00 ...what happens if error happens 20:49:10 AdamR: We have not talked a lot about what web primitives you can use internally 20:49:22 Marcos: Suppose you get a 404...and didn't have a close button 20:49:33 AdrianHB_: You might need a post messager 20:49:50 AdamR: I am certain we will need some affordance for user aborting the payment 20:50:05 ...we need to make sure there is some recovery path 20:50:29 MattS has joined #wpwg 20:50:53 q? 20:51:17 Ken has joined #wpwg 20:51:18 RRSAgent, make minutes 20:51:18 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 20:52:17 AdrianHB_: We should not carve out a narrow path for developers; let them leverage the full strength of the platform 20:52:46 AdamR: Can call postMessage back to service worker when done 20:52:53 ....to send the payment app response back 20:53:07 [Wallets] 20:53:25 AdamR: use cases involving grouping (e.g., business v. personal account, or white label wallet provider) 20:53:49 (slide showing amex business and amex personal wallets) 20:54:02 ...same origin, different semantic groupings 20:54:03 q+ to nit on a terminology issue (but not dwell on it) - wallets vs. groups 20:54:46 q+ 20:54:59 ack manu 20:54:59 manu, you wanted to nit on a terminology issue (but not dwell on it) - wallets vs. groups 20:55:25 IJ: Permissions are by origin; but there might be different display goals for a given origin; hence wallets 20:55:28 q? 20:55:31 Manu: Concerned about the term "wallet" 20:55:49 AdamR: We are not wedded closely to "wallet" 20:56:04 AdamR: Something like "Instrument Groups" might be fine 20:56:14 ack zkoch 20:56:15 ack zkoch 20:56:18 mike_mastercard has joined #wpwg 20:56:25 mweksler has joined #wpwg 20:56:35 Propose we call them Web Costanza's :) 20:56:43 zkoch: What does this gain you really? You could simply use different labels like "personal card" 20:57:21 AdrianHB_: I think white label wallet provider is a stronger use caser 20:57:23 use case 20:57:24 jean-yves has joined #wpwg 20:57:40 ...there was pushback to saying "use subdomains" as there's a cost to doing that 20:57:49 AdamR:...and that requires a new set of permissions 20:58:17 q+ 20:59:03 q? 20:59:10 Ian: So the question is "Do we need this additional complexity to meet these use cases"? 20:59:26 AdrianHB_: As an implementer you can choose to display under a single list; the spec gives you some extra structure 20:59:34 zkoch: Just want to say that implementation is not free 20:59:46 q? 20:59:53 ack Al 20:59:55 ack AlanSamsungPay_ 21:00:17 AlanSamsungPay_: I don't see this getting adopted much. There's a lot of opportunity for control of the user experience in the user experience. 21:01:24 q+ 21:02:00 q+ 21:02:21 Mahesh: On the UX side, when does the window open? 21:03:23 ack MaheshK 21:04:18 adamR has joined #wpwg 21:04:57 nick has joined #wpwg 21:05:26 nicktr: On ordering....merchants provide ordered list of payment methods. What is relationship between payment method ordering and groupings? 21:05:36 ...suppose bobpay has a personal and a business wallet 21:05:54 ...and one wallet includes instruments for basic-card and, say, bitcoin 21:06:08 ...and one wallet includes different instruments for the same. 21:06:11 ...how does that work 21:06:30 AdamR: That is currently unspecified. I expect that can be specified. 21:06:51 q? 21:06:54 ack me 21:07:52 IJ: I agree that there is an issue about merchant pref as related to payment app prefs 21:07:58 AdamR: Agree we need an algorithm for this. 21:08:45 RRSAvgent, make minutes 21:08:48 RRSAgent, make minutes 21:08:48 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 21:09:12 Roy has joined #wpwg 21:09:25 q? 21:09:44 q+ 21:09:57 Alan: Who are the primary authors of the payment handler spec? 21:10:22 q? 21:10:28 ack Roy 21:10:44 Ken has joined #WPWG 21:10:56 Roy: If you have registered an app and on a different device, and you add a card, how does that get updated? 21:12:12 Marcos: Permissions are per device 21:12:27 IJ: You should be able to write your payment app so that instruments are visible on multiple devices 21:13:12 DavidM: Could you limit visibility of some instruments for, say, mobile 21:13:16 Marcos: Yes. User controlled. 21:13:29 ...you can manipulate instruments on a given device, AND also sync them as you want 21:14:51 stoyanstefanov has joined #wpwg 21:14:52 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 21:16:04 Topics that came up today: 21:16:04 Payment Request (Pat) 21:16:04 Can we leverage payment options or other aspects of PR to assist with regulatory requirements on payee? 21:16:04 Payment Request (Matt) 21:16:04 Algorithm language is very pull payment centric. Will this change with Payment apps/handlers 21:16:05 Payment Request (Manu) 21:16:05 We should not be naive about how difficult it is to change implementations. We need implementation experience with Payment Handler. 21:16:05 Payment Method Specs (Adrian) 21:16:05 Should these be rec track specs 21:16:05 Payment Request/Handlers (Manu/Zach) 21:16:05 Where does the payment app UI get rendered? 21:16:06 Payment Request/Handler (Max) 21:16:06 Is there spec text required to help users invoke either web or native handlers? 21:16:07 Payment Request (Adrian) 21:16:07 Can we indicate in payment response what format data is in? 21:16:07 PaymentRequest (Zach) 21:16:07 Disambiguate between user abort and merchant abort, also is there a state to be added for “processing” of a push payment. 21:16:09 PaymentRequest/Handler (Alan) 21:16:09 Can we improve how apps expose the functions they have internally (like shipping address capture) to optimize checkout flow 21:16:09 PaymentHandler (Adrian) 21:16:09 Handling issues in clientWindow. Ping? 21:16:09 PaymentHandler (Adam) 21:16:09 Multi-level ordering 21:16:18 ========== 21:16:49 [Regulatory] 21:17:01 Pat: We can talk about this further in the IG. This would not happen in PR API 21:17:21 ...we can look at what data is perhaps useful for some jurisdictions 21:18:03 +1 to writing down the use cases in the IG 21:18:04 Ian: I think we should write down the use cases that we have, Vincent had one wrt. contracts registered, let's write them down in the IG, play around with whether this would be useful as private data, new payment method, etc. Let's write the use cases down in IG. 21:18:34 [Language of spec is "pull payment centric"] 21:18:41 adam_ has joined #wpwg 21:18:55 MattS: I'm ok to discuss this via a pull request 21:19:16 ...there are three or four places in PR API where it might be worth making it less pull-centric 21:19:26 zkoch: +1 to pull request 21:19:44 [Payment handler implementation] 21:20:08 (On the agenda tomorrow) 21:20:21 [Payment method specs as Notes or Rec track?] 21:21:19 q+ 21:21:26 AdrianHB: How to render UI? 21:21:30 nicktr: Tomorrow we have a slot for it, let's talk about it then. 21:22:09 AdrianHB: Max raised a point around handler invoking - web and native app installed, how does browser decide which one to present. How do we say "this native app is a version of this web app". Or are they separate apps? 21:22:27 Zach: This is a UX question - UAs will determine what is the right way to do this. 21:23:11 AdrianHB: Maybe this is a way to handle it in the manifest discussion. 21:23:18 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html nicktr 21:23:20 ack AlanSamsungPay 21:23:24 adamR has joined #wpwg 21:23:39 Alan: Has there been discussion around recurring payments and data flow? Flag from merchant wrt. subscriptions? 21:24:21 AdrianHB: This has been deferred at this point... recurring payments are focused on cards, some payment methods don't work for recurring Bitcoin, for example, scheme and payment method specific. 21:25:00 AdrianHB: Indicate things like subscription, terms, ... if we want to add that to basic card... 21:25:55 Alan: Quick backgrounder, part of input params for visa cryptogram generation in the cloud to generate cryptogram in different way for recurring payments, so this is important to keep in mind. Since it's relevant in other circumstances, it doesn't seem like it should be payment method specific. 21:26:02 CyrilV has joined #wpwg 21:26:11 q+ 21:26:14 present+ 21:26:15 Alan: It's a more generic use, don't want to specify something specific to our payment handler... similar to order number. 21:26:28 AdrianHB: I could imagine this being added to basic card spec... it isn't in v1 of that spec. 21:26:36 q+ 21:26:40 AdrianHB: We should explore that. 21:26:42 q+ 21:26:50 Michel: It sounds like recurring payment is closer to basic card. 21:27:07 s/is closer/is not really associated/ 21:27:48 q+ 21:27:49 Michel: Recurring payment may be out of scope of payment request API, passing credentials that are outside of scope - pass me credentials, I'll process it for you, recurring - we may be able to look at it in that way - how many times, days - it should be generic. 21:27:52 +1 21:28:15 AdrianHB: If someone can design this flow and come back and show us why it doesn't work, that's a great way for us to decide what needs to change. 21:28:29 nicktr: Recurring was not in v1 scope. 21:28:29 q? 21:28:33 ack dezell 21:28:34 q+ to talk about recurring payments experience 21:28:36 (clarification that recurring payments are NOT for v1) 21:28:49 q? 21:29:03 dezell: In Lisbon, we had a session with Andrew Betts that talked about subscriptions, recurring payments, and there was supposed to be a CG. This is why the IG stopped talking about it. I don't know what happened with it 21:29:31 ack CyrilV 21:29:33 AdrianHB: I think it's a digital publishing CG now. 21:30:34 CyrilV: We have direct debit systems that do recurring payments. 21:31:13 CyrilV: It's easier to do this work on SEPA Direct Debit and work for any direct debit... direct debit across countries is a nightmare... we need more than one scheme that can support it. 21:31:36 ack nick 21:31:41 AdrianHB: We have opportunity to standardize data model - we need more use cases to standardize. 21:32:12 NickS: I would resist trying to do recurring at this point. The variety of information you need to collect is large. 21:32:34 NickS: We already have this support, you can put it in the payment method spec. 21:32:44 +1 to Nick's approach 21:32:59 ack Ian 21:33:01 AdrianHB: If someone writes 3rd party payment app - strong motiviation for browsers on how they can support that. 21:33:34 https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0012.html 21:33:38 Ian: I've found when we did call for consensus - we concluded to request publication, TR to Wendy, note that these are called out clearly as not going to REC. 21:33:41 https://lists.w3.org/Archives/Member/chairs/2016AprJun/0006.html 21:33:49 q? 21:33:52 ack rouslan 21:33:52 rouslan, you wanted to talk about recurring payments experience 21:33:55 http://i.imgur.com/GY31DAb.png 21:34:21 Rouslan: In relation to subscription, PaymentRequest API works, Washington Post uses payment request for subscriptions... even though we don't have mechanism, merchants can figure this out on their own. 21:35:04 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 21:35:24 AdrianHB: What format for metadata in payment request - format for phone number, etc. 21:35:51 Ian: one thing that's analogous to this is our currency code decision... we have a way to say "this thing is in this repository over here". 21:36:04 Ian: The default format is X, but if you want to use another format, it's over there 21:36:19 MattPi has joined #wpwg 21:36:35 AdrianHB: Difference in this case is this is in the response, browsers will support one format or "we don't know" 21:37:21 Zach: Do we care about anything else than phone number here? 21:38:22 Zach: We picked a standard address format... our i18n team is okay with it, that exists. Phone numbers are the only exception... very difficult to format them, I think safest thing is to remove all formatting, return back a bunch of numbers, then optional plus before country code. 21:38:37 PaymentAddress interface -> https://w3c.github.io/browser-payment-api/#paymentaddress-interface 21:38:49 Rouslan: We don't have separators, but we do have a format that we follow 21:39:05 Alan: It's only numbers or only values. 21:39:39 I have made the request to generate http://www.w3.org/2017/03/23-wpwg-minutes.html Ian 21:40:28 AdrianHB: Disambiguation between different abort()s 21:40:56 Zach: There are two places that .abort() is thrown, when user intentionally stops it. If you can deduce who abort()'ed. 21:41:26 AdrianHB: Additional state when you can't abort because payment app is in processing state. 21:41:54 q+ 21:41:59 Zach: We put it in the spec because there are certain situations where you can assert control... I'm hesitant to impose a tighter restriction here. 21:42:04 ack nicktr 21:43:11 nicktr: The payment apps spec, before complete is called, payment request user interface stays in a pending state. There is another state in the state model, there is already another state in the state model - diagram of state model. 21:43:25 marcosc: We should delete the diagram, it's accurate, but not helpful. 21:44:22 AdrianHB: Something we need to figure out in Payment Handler spec wrt. when on payment request is made, and then someone calls .abort() on payment request on merchant side. What's the teardown mechanism there, is there one? 21:44:51 marcos: You need to tell it you're aborting, as you go to next step, something is going wrong - if I'm buying a movie ticket, the tickets are all gone. 21:45:19 nicktr: A point was made about idempotency. 21:46:08 marcos: We'll see if it has any effect, and add it in. We could add a conceptual state... state machine, accept promise is selecting the reality of the state, that's what you get back when you get .show() 21:46:26 marcos: it's strange, but expected, 21:46:44 nicktr: We should add it to the discussion for tomorrow, but not high priority, very technical 21:47:02 Ian: I integrated the last 3 into the presentation tomorrow. 21:47:23 mweksler has joined #wpwg 21:48:38 1929 dayton street 21:49:01 1929 Dayton St <- Ian's House 21:49:10 meal at -> http://www.chezmoichicago.com/ 21:49:35 dezell has left #wpwg 22:15:09 nick has joined #wpwg 22:42:18 cweiss has joined #wpwg