W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Re: Updates to Payment Apps wiki page

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Wed, 11 May 2016 13:52:39 +0200
Message-ID: <CAKaEYhLND8A8fCyg6kALpvxd-qMNpjQx3OAe5i0kzJiY+UvhGg@mail.gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Payments WG <public-payments-wg@w3.org>
On 9 May 2016 at 17:03, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> Hi Ian and WG,
>
> I have made some updates to the payment apps wiki as requested:
>
>
>    - I added a comment about us needing to clarify our scope. I think a
>    lot of what was in there assumed that the scope was only payment apps that
>    run in a browser and ignores the possibility of other apps that can still
>    be interfaced from a browser over the Web.
>
> +1 strongly support the inclusion of payments apps that dont run only in
the browser.

Modern web development allows libraries to be built (eg in javascript) that
can run in multiple environments

The same workflows (and hopefully code) should be deployable to multiple
targets


>    - I added a few definitions to differentiate between browser-based and
>    web-based apps (per scoping question above).
>    - I also dropped the hybrid and web-technology apps as I'm not sure
>    these have any impact on integration with a browser (i.e. an app either
>    runs in the browser or doesn't which is all that matters from the
>    perspective of integration with the browser).
>    - I added the following line to the display text:
>    "The browser should display matched payment apps in an order that
>    corresponds with the order of supported payment methods supplied by the
>    payee"
>    - I made changes to the advantages and disadvantages of the invoking
>    and response sections based on discussions with Ian.
>    (Although I'm still not sure I agree that JavaScript encapsulation has
>    an advantage of flexibility, I think it's the opposite)
>    - I corrected the steps in the JavaScript encapsulation approach to
>    include passing the response to the browser.
>    - Added a hybrid response approach
>    - Made some minor changes to the data collection points
>
>
Received on Wednesday, 11 May 2016 11:53:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 May 2016 11:53:08 UTC