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

Payment logic in the Browser (was Re: CfC to publish documents as FPWD of the Web Payments WG)

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 6 Apr 2016 02:15:40 -0700
Message-ID: <CA+eFz_LSirLu4Y2dH6Oo33qh4FgXX08bML+-PsraJ_BJQw3uoQ@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Web Payments Working Group <public-payments-wg@w3.org>
Hi Anders,


*NB: Please can we restrict the discussion on the CfC thread to +1 or -1 on
the CfC itself.*
That said, I have forked the thread, so thanks for your input.

If you read the specifications you'll see that we have explicitly NOT "put
payment application logic inside of a browser".

Instead we have created a standard interface to initiate a payment in a way
that is agnostic to the method of payment and allows the payment logic to
exist almost anywhere.

I have just pushed a proposal for another specification in this set that
describes how Payment Apps integrate with this API and the many forms they
might take. I'd appreciate your thoughts as I think this is starting to get
into the realm of things that you have been discussing for some time:

https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

Adrian

On 6 April 2016 at 01:57, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> I'm neither a W3C member nor an invited expert so feel free ignoring the
> following.
>
> Anyway, IMO there's no point putting payment application logic inside of a
> browser;
> it will only constrain innovation which is the core problem with Web
> Payments.
>
> That is, "Energizing" Web Payments rather than "Standardizing" is what I'm
> proposing.
>
> That's obviously an entirely different project which though would be
> better aligned
> with W3C's track record for standards than jumping into the very
> fragmented and
> politically awkward application space where payments appear topping the
> list.
>
> Sincerely,
> Anders Rundgren
> Consumer and Technologist
>
Received on Wednesday, 6 April 2016 09:16:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:15 UTC