12:53:24 RRSAgent has joined #apps 12:53:24 logging to http://www.w3.org/2016/08/10-apps-irc 12:53:33 Meeting: Payment Apps Task Force 12:53:44 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0042.html 12:53:46 Chair: ian 13:01:49 alyver has joined #apps 13:02:59 need dial-in details, please 13:03:14 https://mit.webex.com/mit/j.php?MTID=mab3c7a1fb772cbcbf39b054b2ebd9183 13:03:17 present+ Ian 13:03:20 present+ AdamR 13:04:16 present+ Andre 13:06:00 maheshk has joined #apps 13:06:45 Spec: https://w3c.github.io/webpayments-payment-apps-api/ 13:07:28 topic: New draft 13:07:34 IJ: Please review updated draft 13:08:13 present+ Mahesh 13:08:44 topic: Registration 13:08:58 https://w3c.github.io/webpayments-payment-apps-api/#registration-and-unregistration 13:09:49 IJ: Jason completed his action about registration. 13:09:59 "Registration is not required to invoke a payment app or process a response. If a payment app is included in the list of recommended apps provided by the merchant and the user selects it during the checkout process then the app is not required to register itself with the user agent, it can still walk the user through the payment process that it provides and in the end provide a payment response to the user agent." 13:11:21 Jason: note the relation to second bullet. 13:12:41 s/Jason/Andre 13:14:37 IJ: Should payment apps api have "all the bits necessary to do payment apps, including modifications to payment request api?" 13:14:38 or 13:14:47 we should do pull requests to payment request API? 13:14:51 AdamR: I strongly prefer the latter. 13:15:41 Andre: Also prefer that it be done in payment request API 13:15:47 Mahesh: I am also leaning that way 13:16:55 AdamR: Let's put on the agenda of this week's call. 13:18:19 ACTION: Ian is going to make small edits to 4.3 to make clearer that registration is not required to use a payment app; it's required for persistence 13:18:44 Andre: We revisited recommended payment apps 13:19:00 ...in some cases flow can be awkward - merchant recommending apps that the user may not have used before. 13:19:23 ...for whatever reason, suppose user is inclined to use bob's pay wallet, but doesn't yet have a bob pay account 13:22:12 [Aha moment] 13:22:25 Andre: You may need a wrapper for some payment methods. 13:22:54 ...you might find yourself with a payment app that acts like a wrapper that knows how to invoke some payment methods. 13:23:08 ...think Shopify's "active merchant" module 13:23:23 ...which has 150 payment gateways connected into it; and people can add their own via a library spec 13:23:36 present+ AdrianHB 13:25:09 ...I am concerned there could be a proliferation of payment apps that act as wrappers. 13:25:14 AdrianHB: Is that a problem? 13:25:22 ...can you stop people from coding? 13:28:07 q? 13:28:43 [Discussion of hosted pages] 13:29:33 Andre: Suppose a merchant wants to use a hosted page (e.g., hosted by worldpay). As a merchant, I can redirect user to worldpay page, and worldpay has done the integration to paypal. Merchant beforehand has provided worldpay with credentials. 13:30:06 AdrianHB: Worldpay, similarly, could do this from a payment app 13:30:27 Andre: How does the customer know they have to use the "worldpay payment" app to pay with some payment method? 13:30:34 ..if we allow apps to register themselves at checkout, this helps. 13:31:02 AdrianHB: It's actually not the worldpay payment app, it's branded for the merchant 13:31:16 ...so we imagine worldpay or others building white label payment apps 13:31:27 ..and each merchant who wants it gets a branded version 13:31:40 ...then it's up to the retailer to incentivize the user to install the merchant app 13:32:19 AdrianHB: But we don't want to find ourselves in a place where merchants require users to install the merchants' app 13:33:07 Andre: Can you have the same app register itself under multiple names? 13:33:13 IJ: Yes (different payment app identifier) 13:34:00 AdrianHB: But we need to be able to enable the payment app to get javascript from another origin 13:34:09 ...we need think carefully about what that means. 13:35:28 topic: Trust 13:35:41 Q. should merchants be able to limit apps to those that they accept? 13:36:27 AdrianHB: I think this defeats the purpose of having payment methods (and decoupling them from payment apps) 13:36:41 ...how would a merchant say "I only support basic card payment method supported by the browser"? 13:36:45 (IJ: Good question) 13:36:54 ...this is a pretty major change in approach based on our early discussions 13:38:21 ..if the merchant can say I accept PayPal (the payment method) 13:38:33 ...why do they need to limit the set of apps? 13:38:55 ...if they want that level of control they can not use the payment request API 13:39:28 q+ 13:39:48 AdrianHB: I understand that merchants want to control the payment system, but that's not how this system works. 13:39:51 ack me 13:41:33 AdrianHB Proposal: No filtering mechanism other than on payment methods 13:43:20 ...I don't want to facilitate an anti-pattern that sounds like "best viewed in browser X" 13:44:23 q+ 13:44:55 ack al 13:45:10 alyver: I think +1 to AHB 13:45:17 ...we are working through payment request implementation on our side 13:45:34 ...one challenge we encountered was a merchant accepting N payment methods supported by Shopify 13:45:49 ...for our checkout to be a seamless experience, we can have the checkout button trigger payment request, but it excludes some payment apps 13:46:04 ...so we've had to limit the scope of our payment request implementation to those merchants who only accept credit cards 13:46:09 ...otherwise you get 2 different flows 13:47:16 AdamR: I heard AdrianHB said that people can define their own PMIs 13:47:25 ...I am also concerned about ossification 13:47:50 IJ: So I am hearing remove accepted apps bits from the spec 13:47:54 ...any design considering 13:48:07 Define their PMIs or use some other existing mechanism to hand-off the checkout to a specific app like custom-url protocols 13:48:53 IJ: I propose to add "if the merchant wants tine-grain control over apps...they can do this in several ways..." 13:49:37 AdamR: I think we should not talk about the anti-pattern 13:53:07 AdrianHB: Could say "This API is designed so that merchants do need to focus on application integration" 13:55:13 ACTION:Ian to update decoupling section and remove filtering on apps from the spec 13:55:22 ...and close the related issue with the resolution 13:55:38 ...with link to the minutes 13:56:25 topic: User experiences 13:56:31 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes#user-experience-descriptions 13:59:34 (IJ: I note that I need to remove the accepted apps column) 13:59:39 Andre: Add line numbers 14:02:09 ACTION: AdrianHB to read the table for next week's call. 14:02:31 [Adrian leaves] 14:02:58 AdamR: Regarding the table...I think you could collapse the table 14:05:21 Topic: Implementations 14:05:44 IJ: Can we show up at TPAC with payment app demos? 14:06:40 IJ: How do we get polypill? 14:06:47 IJ: Any payment app developers we could use with? 14:08:27 Andre: I will take away the question and see if we can find anyone to speak with. 14:08:33 Mahesh: I will get back to you as well. 14:09:18 Topic: Next call 14:09:24 17 August 14:09:33 rrsagent, make minutes 14:09:33 I have made the request to generate http://www.w3.org/2016/08/10-apps-minutes.html Ian 14:09:35 rrsagent, set logs public 15:24:03 alyver has joined #apps 15:26:57 alyver has joined #apps 16:11:13 Zakim has left #apps