OpenTransact a tiny payment standard

POST /transactions/usd HTTP/1.1
Authorization: OAuth ... oauth_token="ad180jjd733klru7", ...
Content-length: 239

amount=10.00&[email protected]&memo=Milk

@token.post "/transactions/usd", :amount=>10, :to=>"[email protected], :memo=>"Milk"

Motivation

I think The Sorry state of Payment Standards should provide enough motivation for this, but briefly payment standards in the payments fields are too complex.

• focus on batch processing of messages
• have to deal with multi day inter bank settlement
• not inherently authenticated, but rely on rule books and certification.

Most of the API’s we have to deal with such as PayPal’s and most merchant account apis have to deal with this complexity. They are also often based on old Web 1.0 style practices.

Common objections

What about currencies?

OpenTransact was designed to allow transfers of any kind of asset from US$ to EUR to stock options and phone credits. Rather than add a bunch of different parameters to support all of these, we thought it a good idea to rely on this modern invention called the URL. We call this the transaction url.

Lets say an imaginary electronic currency eepay.com they offer one asset type, their currency. So they would only have one transaction url:

• http://eepay.com/transactions

If it offered multiple currencies it should have a url for each currency as they are really separate asset types:

• http://eepay.com/transactions/usd
• http://eepay.com/transactions/euro

If a larger existing bank offered various kinds of services each one would have it’s own URL:

• http://megabank.com/current
• http://megabank.com/savings
• http://megabank.com/bonds/mortgage

A mutual fund company would have a url for each of their funds.

• http://fidelify.com/funds/sp500
• http://fidelify.com/funds/emergingmarkets

A broker could actually also implement an OpenTransact API and have a different URL for each symbol eg:

• http://feetrade.com/trade/AAPL
• http://feetrade.com/trade/EBAY

This would be kind of neat allowing them to create their own internal market.

You could even imagine with GoDaddy’s new patent for offering shares in domain names they could do something like this for each of their domains offered as shares:

• http://godaddyexchange.com/domains/stakeventures.com/shares

A mobile phone operator could allow transfers of phone credit which is already very common in Africa and Latin America.

• http://prepay.add.com/prepay/minutes

But OAuth sounds complicated…

The protocol itself may be complicated, but the good news is you don’t need to understand it as there are great libraries for every single language out there. If you can write an application using Twitter you can write an application using OpenTransact.

OpenTransact does however also allow merchants to use non OAuth Simple Website Payments using nothing more than a few lines of PHP and a http redirect.

What about interbank settlement?

Well what about it? I do not think a modern API should be designed around 300 year old business practices when we have this amazing thing called the Internet. Settlement should be done within 200ms and not 3 days.

While OpenTransact doesn’t specify anything about exchanging funds between http://megabank.com/current and http://bancleys.co.uk/current, having both of them support the same simple standard makes it very easy for entrepreneurs to create new realtime decentralized settlement systems outside the traditional system.

Anyway I doubt banks are going to be early adopters of OpenTransact so why add 10 times the complexity to support them. I imagine virtual currencies, local currencies and prepaid systems who have no issues with settlement are going to be the main implementers in the beginning.

How would I use this to buy my morning coffee?

I know that there are at least 4 startups working on mobile phone applications that would allow what we called POS (Point of Sale) payments using OpenTransact. Here is an example from OpenWallet

It would also be fairly straightforward to create VISA debit cards that could be linked to arbitrary OpenTransact accounts. CapCard is a proof of concept showing how this could work:

See CapCard source on github if you’re interested in this.

Who is using OpenTransact?

Demo sites:

• NuBux is a reference transaction provider with full source code on github.
• OsCurrency is Tomwiththeweathers software for running an OpenTransact compliant timebank. Full source on GitHub

Real money sites:

• Bay Area Community Exchange based on OsCurrency
• Austin Time Exchange

I am particularly excited that a new site will be launched soon using OpenWallet that has the potential to be the PayPal of the middle east.

Talking about PayPal. They expressed interest at BarCampBank London in experimenting with an OpenTransact gateway. Will this replace their current API? Hardly, but it would make it easier for developers to get started.

Several people (including me) are working on businesses based on OpenTransact. Most people are really excited about the potential size and depth of this that there is plenty of space for competition.

How can I help?

The first thing to do is join the Agile Banking mailing list.

After that the most important thing we need are more applications. Create a virtual currency for your web applications instead of or in addition to freemium and ads. Think up new ideas on how this could be used.

We also need libraries and reference implementations for whatever programming languages you are working in.

update There are a couple of interesting comments on the HN comments page