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

On 2014-11-15 11:44, Joseph Potvin wrote:
> What you're saying Anders is that the W3C WP effort is about herding cats:
> http://www.blinkx.com/ce/saQTySG9pg5QQ_bOz5lULrZwc2FRVHlTRzlwZzVRUV9iT3o1bFVMclp3c2FRVHlTRzlwZzVRUV9?id=1604418093

Great video!

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

A possible ingredient could be an open source client running on Android.

Since the costs and difficulties for doing this are extremely high I also
think that a successful project (beyond producing a REC) must be open for
any willing participant.

Running this as standard W3C project is a surefire recipe for failure unless
it (in reality) becomes a single big-company affair.

Anders

>
> --
> Joseph Potvin
> Operations Manager | Gestionnaire des opérations
> The Opman Company | La compagnie Opman
> jpotvin@opman.ca <mailto:jpotvin@opman.ca>
> Mobile: 819-593-5983
>
>
> On Sat, Nov 15, 2014 at 2:18 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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/ <https://web-payments.org/specs/source/roadmap/>
>
>         -- manu
>
>
>
>
>
>
>

Received on Saturday, 15 November 2014 12:47:00 UTC