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

What you're saying Anders is that the W3C WP effort is about herding cats:
http://www.blinkx.com/ce/saQTySG9pg5QQ_bOz5lULrZwc2FRVHlTRzlwZzVRUV9iT3o1bFVMclp3c2FRVHlTRzlwZzVRUV9?id=1604418093

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
jpotvin@opman.ca
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
>>
>>
>
>