W3C home > Mailing lists > Public > public-webpayments@w3.org > November 2014

Re: Discussion - Payment APIs: others are thinking about this problem space, too

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 15 Nov 2014 08:18:54 +0100
Message-ID: <5466FE5E.1070501@gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>, Web Payments CG <public-webpayments@w3.org>
I think this discussion highlightes what I have tried to say which
is that standardization of payments probably is the most difficult
target you can possible find!

Anyway, standardization has never been a level playing field, nor a
democratic process or even a quest for the best possible solution.

With SuperProviders like Apple and Google (and Alibaba on the horizon)
it just got worse.

The limited information available around the Google Wallet and Apple Pay,
also shows that the W3C members aren't mentally ready for standardization,
i.e. whatever we do it will be a "rebel" effort or even more likely a no-go.
Gemalto is participating in the IG because they have a wallet but they
haven't submitted the specs...very useful indeed.

I would personally consider schemes that *compete* with established
payment industry but that is something W3C can't do so therefore it
seems that the whole W3C payment standardization thing is toast.

Regarding polyfilling as a solution, I think this is a hard sell when
the SuperProviders can add whatever feature they need using an army of
developers and then get it distributed as an automatic update.
You can't replace security elements with polyfilling and for payments
that's a show-stopper.

Apple Pay is the new yardstick for the payment industry.


On 2014-11-14 20:35, Manu Sporny wrote:
> On 11/13/2014 02:54 PM, David Ezell wrote:
>> As I see it, there are two levels of API with which we are
>> concerned:
>> 1) Interfaces for the "payment agent"[2] - probably WebIDL defined
>> interfaces.
> I'm always concerned when this comes up because it has fantastic
> potential for vendor lock-in. For example, if we create the WebIDL
> interfaces in such a way that only the browser manufacturers can
> implement them, then we will fail for at least two reasons:
> 1. We will fail because the browser vendors may drag their feet to
>     implement it, and more importantly
> 2. We will fail because it won't create a level playing field, it'll
>     make it so that the browser vendors determine the payment landscape
>     on the Web.
> WebIDL is a great way to hand an enormous amount of power over to the
> browser vendors.
> So, when we talk about WebIDL interfaces, we should build them in such a
> way as to avoid vendor lock-in. That is, any WebIDL we provide must be
> implementable in pure JavaScript w/o waiting on the browsers to implement.
> Just pointing out what should be a show-stopper for every payment
> company that isn't a browser vendor.
>> 2) RESTful web services for other as yet TBD goals.
> I think this is a better approach. RESTful web services coupled with
> WebIDL APIs that can be implemented in pure JavaScript. That removes
> many technical barriers to adoption and doesn't put this group in the
> position of waiting for any particular organization or industry to get
> off their keister and open themselves up to competition.
>> We need to generate some concrete ideas and get the ball rolling.
> Some concrete ideas:
> https://web-payments.org/specs/source/roadmap/
> -- manu
Received on Saturday, 15 November 2014 07:19:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC