[Agenda] 7 Feb 2017 Payment Apps task force call

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

Received on Monday, 6 February 2017 18:43:52 UTC