Minutes [Was: [Agenda] 7 Feb 2017 Payment Apps task force call]

Minutes from today’s call:
 https://www.w3.org/2017/02/07-apps-minutes

Summary:

 * Issues 97 and 73: we are glad to have Marcos volunteer to write up 
   specification text around a new openClientWindow method.

 * Issue 74: Discussion today suggested the most valuable aspect to Recommended payment 
   apps would be to bootstrap the app ecosystem. AdrianHB has some ideas for
   addressing this declaratively, outside of PR API.

 * Issue 99: The consensus on the call was that, while people would support reuse of
   objects, we think the way they are currently structured in PR API means they do not 
   lend themselves to reuse in the context of payment apps. This is both because there
   would be a lot of empty fields when shipped to the payment app, and also there is
   some data from the user agent that should not be exposed on the merchant side.
   While PR API could change to enable a more reusable structure, the sentiment from
   developers on the call was that that would be unlikely to happen.
   AdrianHB took an action to summarize the discussion online for further discussion
   with Marcos, to see if there are other ways to support reuse.

Next meeting: 14 February

Ian


> On Feb 6, 2017, at 12:43 PM, Ian Jacobs <ij@w3.org> wrote:
> 
> Participants in the payments app task force,
> 
> We meet 7 January at 10am ET. 
> 
> Previous meeting 31 January:
>  https://www.w3.org/2017/01/31-apps-minutes
> 
> WebEx: 
> http://www.w3.org/2017/01/paymentapps-2017.ics
> 
> 
> Ian
> 
> ========
> Review the Proposal, which identifies points of consensus and open issues. 
> I updated the proposal based on recent discussions including last week's meeting: 
> https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
> 
> I would like to discuss in particular some proposals that would help us move forward:
> 
> 1) FILTERING. See proposals from Adam [1] and Rouslan [2]. These
>    proposals move away from filtering-in-the-payment-app back to
>    filtering-in-the-browser. We will need to hear from browser
>    developers whether they would commit to a simple matching
>    language, and whether that commitment would enable other
>    payment methods to make use of it.
> 
>    [1] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457
>    [2] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276423629
> 
> 2) DISPLAY OF OPTIONS
> 
>    Action 20170131: Andre to write up use cases for additional
>                     organizational capabilities for payment apps.
> 
>    Do we need additional container capabilities?
> 
>    Is it required that user agents display option information (or just
>    a way for user agents to improve the user experience)? See issue 90.
> 
> 3) DEPENDENCY ON WEB APP MANIFEST
> 
>    As we have moved in the direction of "payment apps are web apps
>    that implement additional permissions" we have moved in the
>    direction of dependency on other parts of the Web platform.
>    Web App Manifest is one such component, which provides app-level
>    information about labels and icons. However, it is not yet
>    widely supported in browsers and also would not (as is) provide
>    information about options-level labels and icons. How should
>    we write the spec to balance these considerations?
> 
> 4) RECOMMENDED PAYMENT APPS
> 
>    What should we aim for in FPWD? My personal preference is to
>    enable merchants to provide a list of payment app identifiers
>    (including just origins for web-based payment apps) as input to PR
>    API and let the user agent try to make good use of the information
>    such as highlighting registered payment apps recommended by the
>    merchant.
> 
> 5) OPENING WINDOWS.
> 
>     There seems to be consensus on "a new openClientWindow method 
>     on the event”. Would someone like to volunteer to write up the proposal?
> 
> =======
> Tommy's pull request regarding Example 3
> https://github.com/w3c/webpayments-payment-apps-api/pull/101
> 
> Do people support the fix to the example?
> 
> =======
> Conor's suggestion regarding recovery of a failed push payment
> https://github.com/w3c/webpayments-payment-apps-api/issues/102
> 
> Quoting:
> 
> "I suggest adding the "PaymentComplete" enum to the response that
> comes back to the mediator from the app, allowing for a clear mapping
> like the "details" object."
> 
> =======
> Next meeting
> 
> * 14 February
> 
> ========
> Other issues
> https://github.com/w3c/webpayments-payment-apps-api/issues
> 
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
> 
> 
> 
> 

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Tuesday, 7 February 2017 17:55:26 UTC