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

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

From: Joseph Potvin <jpotvin@opman.ca>
Date: Sat, 15 Nov 2014 05:44:55 -0500
Message-ID: <CAKcXiSpW6CTZAJszQwjsyeST0d8c2nf6FwFbDd8X=myADDOA=A@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: "public-webpayments-comments@w3.org" <public-webpayments-comments@w3.org>, Web Payments CG <public-webpayments@w3.org>
What you're saying Anders is that the W3C WP effort is about herding cats:

May I suggest it's about identifying the sort of cat food that will entice
them into a common area.

Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
Mobile: 819-593-5983

On Sat, Nov 15, 2014 at 2:18 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Manu,
> 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.
> Anders
> 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 10:45:43 UTC

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