Re: The difference between PaySwarm and OpenTransact

On 01/12/2012 02:38 PM, Pelle Braendgaard wrote:
> Dave,
> No where does it mention that OpenTransact is for individual payment 
> providers.

To my knowledge, OpenTransact doesn't work across different payment 
providers -- and you seem to have said so yourself. That 
interoperability isn't there. Instead, it defines a standard API for 
working within a single payment provider. You might only have to write a 
tool to work with a payment provider once -- such that you can then 
switch it to any other payment provider that also implements the same 
API, but you can't communicate or initiate commerce across those two 
payment providers. You need a separate account with each provider.

PaySwarm, by contrast, makes online payment and commerce largely payment 
provider agnostic. A merchant doesn't have to list all of the payment 
platforms that they have an account with and then require their 
customers to go sign up with them in order for commerce to occur. 
OpenTransact makes no effort to change this current problem; it is out 
of scope. Similarly, it is out of scope in PaySwarm to tell a particular 
payment provider what API that they have to use or what authentication 
method they have to do other than what's necessary to facilitate commerce.

OpenTransact seems to want to be a general account delegation method, 
where a specific API (what to POST/GET from various URLs) must be 
implemented for the specific functions of financial delegation. This 
"encompasses only one way of doing things". Though, that's part of what 
a standard is about -- you provide only one way of doing things so that 
everyone knows what to expect.

PaySwarm doesn't tell payment providers what their API must be for 
delegating general access to their customer's accounts. It spec's out 
only the delegation that is required for online payments and commerce is 
standardized (based on digital signatures). In fact, for more general 
access, you could use OpenTransact -- or any other technology. You could 
also simply use Oauth2 and invent your own API should you find that 
OpenTransact is insufficient. I'm sure that many payment providers will 
have more Oauth2 functionality that they'd like to expose on top of 
OpenTransact. This also means that many payment providers will provide 
their own API access tools anyway, so the people writing tools to access 
various payment providers will only need to link to the library for that 
payment provider. In other words, most of their tool (what makes it 
unique) will be write-once anyway. However, if all the payment providers 
out there used OpenTransact, there would only be one library that had to 
be linked to their specific (extra-functionality) library, so there is 
some benefit there.

>
> It is about creating a lively open ecosystem of payment providers, 
> merchants, marketplaces and other kinds of apps.

I disagree. It is not about an open ecosystem, but rather a closed one 
where everyone has to get an account with each payment provider -- or 
they can't do business with each other. Instead, my reading is that 
OpenTransact is about making it easier for people to write tools that 
link to the same library; or for payment providers to cut down on 
development time when providing their own libraries. I'm having a hard 
time seeing it as more than an API standard because of its 
interoperability issue and its silence on the payment silo issue that 
exists today.

> The basic building block is a transfer. That transfer could encompass 
> one or more transfers with business logic behind the scenes.

Sure, but what I'm hearing is that someone else will have to build a 
standard on top of OpenTransact in order to make online commerce truly 
open and interoperable. At the same time, they'll have to do so with any 
inefficiencies that come from a standard that isn't forward looking 
(enough, IMO). There seem to be significant scalability (at least much 
is non-optimal) and atomicity issues with using OpenTransact, eg: to 
send payments to multiple people for the same asset. Without considering 
how applications may want to leverage OpenTransact to engage in more 
than just "the basic building block", there are a lot of open questions 
as to whether or not "the basic building block" is performant enough. A 
MySQL database stores data just fine for the most basic application. 
However, trying to get it to scale is a much more complex process. It is 
a good idea to think forward sometimes, especially when the use cases 
are out there -- and have been out there for many years (MySQL didn't 
have this advantage).

Another example of a potential issue with OpenTransact is exactly what 
we ran into when designing PaySwarm. You have said that digital 
signatures are a good idea and you'd like them to be built into 
OpenTransact in the future as an extension. However, if that's true, all 
of the same challenges that PaySwarm has solved will come up in that 
process. In fact, you may learn the same lessons and decide that Oauth2 
duplicates the necessary delegation functionality required to facilitate 
commerce. Then you'd be stuck with a system with two methods of 
delegation that *must* be implemented in order to be compliant, instead 
of just one.

>
> The biggest problem with PaySwarm is that it really encompasses only 
> one way of doing things. Yes it's extendable but the specs makes many 
> assumptions that limits it.

PaySwarm only "encompasses one way of doing things" for what it is that 
it standardizes. PaySwarm enables interoperability between payment 
providers and facilitates online payment and commerce. It only 
standardizes what needs to be delegated in order for this to happen and 
gets out of your way for everything else. That is not a limitation, 
rather just the opposite. What PaySwarm does limit is only what it 
standardizes, which solves the challenges that anyone who wants to 
engage in open online commerce would otherwise need to solve themselves. 
I think it does so rather minimally, without being so basic that it 
ignores what I think are very important and long standing use cases for 
online commerce.

>
> I would really like to see a joint set of standards bringing along the 
> best of both worlds and that is what I had originally hoped the web 
> payments group was about. My big complaint that started this debate 
> was a seeming lack of will to do this from the PaySwarm team.

I don't think there's a lack of will to work together at all, I just 
think that there's currently a misunderstanding of what the two 
standards do and where their strengths and weaknesses are. But that's 
what this conversation is about.

>
>
> P
>
> On Thu, Jan 12, 2012 at 2:25 PM, Dave Longley 
> <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote:
>
>     My reading on the main difference between PaySwarm and
>     OpenTransact, based on the current discussion, is this:
>
>     OpenTransact is about telling payment providers how they can
>     communicate with their own customers and how they can let their
>     customers delegate access to their account.
>
>     PaySwarm is about telling payment providers how they can
>     facilitate commerce between their customers and the customers of
>     other payment providers.
>
>     I think the latter is more about an open standard for payments and
>     online commerce than the former.
>
>     -- 
>     Dave Longley
>     CTO
>     Digital Bazaar, Inc.
>
>
>
>
>
> -- 
> http://picomoney.com - Like money, just smaller
> http://stakeventures.com - My blog about startups and agile banking


-- 
Dave Longley
CTO
Digital Bazaar, Inc.