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

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

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: High-Stakes Credentials and Web Login
http://manu.sporny.org/2014/identity-credentials/

Received on Friday, 14 November 2014 21:31:51 UTC