Payment systems

Correction: I had misunderstood this to be an official PayPal proposal. It is actually Praveen and Ray Tanaka private provosal, that they are trying to push with amongst other providers PayPal.

Praveen and Ray Tanaka’s both from PayPal gave a talk at OsCon presenting their new Open Web Payments proposal:

PayPal of course have one of the oldest http based payment APIS out there already, but as PayPal’ers like Praveen have admitted it is pretty old school in its approach and very bloated by now. I’ve been talking quite a lot with Praveen the last half year about OpenTransact , which seems to have had a fair amount of influence on this.

Like OpenTransact Open Web Payments utilizes OAuth as well as WebFinger. Where it differs is it’s use of Atom and AtomPub and more fundamentally that it ignores URI’s as a fundamental part of the protocol.

Atom transactions

I think Atom in itself could be a good way of publishing transaction data, but it shouldn’t be the only way. There also needs to be json and microformats. XML and in particular heavily namespaced XML is not very popular today with developers outside the enterprise. The datamodel isn’t too bad but I think it is too complex. There are too many data elements:

AtomPub for payments

To create a payment you POST a chunk of atom xml to a URL creating an entry. I’m glad it follows HTTP conventions. I’m not in love with allowing GETS for modifying transactions. And a refund might be better modeled with a DELETE

This is an example of a transaction:

Contrast this with OpenTransacts equivalent:

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

amount=25.00&to=support@safeway.com&memo=Milk

Again too much information. We already know the sender through the OAuth token, no need to repeat it. Why do we need enter this much information about about the recipients. A single URI, email address or other identifier should be sufficient, particular as we are using webfinger.

What this does have that OpenTransact doesn’t support at the moment is multiple recipients. We could add that using the following convention:

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

amount=25.00&to=support@safeway.com&memo=Milk&amount.2=2.00&to.2=support@yourgroceryapp.com

Where art thou URI

Each transaction does have a URI which is excellent. Posting to an atom resource should create a URI. The rest of the API misses an opportunity to look at the fundamental concept of value as a resource.

For historical reasons payment apis have traditionally followed the messaging model. This goes back to the days before financial institutions were online (see my previous article on the sorry state of payment standards). PayPal, VISA, M/C, SWIFT are financial intermediaries sending messages with instructions back and forth. This message oriented way of thinking about payments is what causes much of the complexity as you need to include lots of redundant information in the payment message.

The web on the other hand works using the concept of resources and actions. It is pretty object oriented in this way. Messaging applications can be created on top of the web, but the complexities are hidden behind this object oriented world. This is how atom, twitter, facebook etc all work.

The best example of a field all payment messaging standards require is the currency field. On the web we don’t need this as we have URI’s.

A payment is the transfer of one resource to another. So lets model that in the restful object oriented way. Each currency has a separate URI:

• http://paypal.com/owp/usd
• http://paypal.com/owp/eur

HTTP POST to this URI to transfer funds. HTTP GET to get transactions in that currency.

In addition in the above grocery transaction the funding types elements. Neither the merchant nor the consumer cares about these. They are also extremely specific to PayPal and are likely not of any interest to most other people wanting to implement this, such as banks. They could be modeled into the URIS as well:

• http://paypal.com/owp/usd – do whatever default behavior is
• http://paypal.com/owp/usd/creditcard
• http://paypal.com/owp/usd/checking

These options could be presented to merchant using WebFinger.

This concept of using URI’s to represent value is key to OpenTransact’s simplicity.

Conclusion

I am glad that Praveen is at PayPal trying to open up their payment world. We can’t discount the importance of an evangelist within PayPal pushing for open standards. I just don’t think it is radical enough. I also think it is too complex both for consuming developers and for developers creating new financial services supporting it.

Any good developer could definitely work with it, but for the majority of developers creating simple PHP/ASP type sites it would present some major hurdles the same way OAuth 1 has. OAuth 2 learnt from this and PayPal’s proprietary API’s have always been targeted at these kinds of developers. While conceptually it is simpler than the old API’s, I think many developers would find it easier to deal with the old API in practice due to the complexities of XML.

Another important question is if PayPal are actually committing to this. I believe PayPal has good intentions with this, but other large corporations were notorious for bringing down competitors with nothing but press releases announcing new products.

It is more of a full stack though than OpenTransact. Hopefully we can work together on the lists to create a common full stack. I see this as Ray and Praveen’s reply to OpenTransact and as the start of a conversation. Similar to OAuth Wrap being the response to the complexity of OAuth1 which lead to the great new OAuth2 standard.

2 news stories on the same day are quite interesting in their contrast.

Pin and Chip is broken

The first one has the collective might and minds of the European banking system and their suppliers who overlooked a slight issue in their authentication protocol for authenticating Chip cards with a pin number. In Europe most Visa/MC cards are smart cards and have to be authenticated with a pin. This in theory allows for an authenticated payment message.

Only problem was that, well one very important bit of the message was not authenticated leaving a gaping hole. I won’t go into the details as well as Ross Anderson does. He is one of the security researchers who discovered the flaw. Unfortunately it sounds like carders discovered it before them.

Now what to do with these supposedly safe authenticated transactions? There is no way of knowing which ones were fake. You can’t mass revoke all european cards. Some one is in a bit of a bind right now.

Grader’s security screw up

The second story was about HubSpot a Cambridge, Mass. based startup who self admittedly screwed up and let a malicious user comprise the security of their Grader service a rating service for twitter users.

Granted we are not talking about a system that handles the majority of Europe’s electronic point of sales transactions here. But they know they screwed up. However due to the fact that Grader used OAuth they were able to mitigate any damage pretty quickly by asking Twitter to revoke their Consumer credentials and any tokens they had issued to it.

Revokability

The difference is that while both Chip and Pin and OAuth are ways of doing delegated authentication, the only token to revoke in the Chip and Pin scheme is in the card itself. The standards behind Chip and Pin assumes that it’s technology is perfect and through their rule books that all parties involved along the long chain from the card to the issuing bank can automatically be trusted.

This is basically the exact issue I described in The sorry state of Payment Standards.

OAuth does not define how a user authenticates himself to either of the services involved, rather it is focused on the delegation.

The delegation is done in the form of an authorized token that can be equipped with limits and can at any time be revoked. It is under the control of the user. In this case Grader themselves request the revocation as they knew that all of their credentials were compromised. Where do the European bankers even start to clean up this mess?

I think OAuth a simple (as authentication standards go) standard developed on a mailing list by a small group of developers has incredible potential in payments applications. This is of course why we picked it as one of the fundamental building blocks for OpenTransact.

Is OAuth perfect? Probably not. Nothing is 100% secure. It has had one serious security flaw which was fixed. But by design it is revokable. You can do something about it if something goes wrong. There is now an IETF OAuth Working Group working on making it an official internet standard.

As I mentioned in my last post The Sorry state of Payment Standards I wanted to blog about OpenTransact which so far is probably one of the most important outcomes of the Agile Banking mailing list set up after my talk last year on Agile Banking.

OpenTransact was designed to be very simple and is based on REST the best practice for current web API design. It should be so easy to implement for developers that there really shouldn’t be an excuse not to implement it.

An OAuth authenticated HTTP POST request to assets URL containing the parameters amount, to and optional memo field. Payer is deduced from the OAuth token.

eg.

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

amount=10.00&to=you@example.com&memo=Milk

The above example shows a payment of $10 to you@example.com from the user who authorized the “ad180jjd733klru7” OAuth token.

Using the Ruby OAuth gem you would write the above as:

@token.post "/transactions/usd", :amount=>10, :to=>"you@example.com, :memo=>"Milk"

That is pretty much it. But please do read on for more about motivations, issues and applications.

Since my talk last year at Reboot on Agile Banking the Agile Banking Mailing List has been quite active with lots of different ideas. One of the most important yet also simple products of the list has been OpenTransact which I now realize I haven’t even mentioned on my blog.

OpenTransact aims to be the worlds simplest technical standard for transferring some sort of value between 2 accounts. We wanted it to be so simple that there wouldn’t be a good technical excuse for not implementing it and also make it extremely simple to build all sorts of new value added services on top of it. You can find out more at the OpenTransact site and I will post a detailed article about it tomorrow.

In this article I will focus on what we’ve got. Current payment standards and bank business processes are incredibly complex and I don’t pretend to understand all of it, but I will try to present a much simplified version of what goes on.

What is wrong with existing Payment Standards?

Complex messages

The big issue with most of them is that they are ancient (SWIFT the standard banks use to transfer funds internationally dates back to the mid 70s). Most of them are designed for ancient technology like mainframes with batch processing as well as ancient business practices such as delayed settlement and bank opening hours.

Most of these standards are message based and extremely complex.

SWIFT has 25 standard data elements and 79 types of messages with strange names like MT542. People make good money specializing in specific message types. You often see programmer jobs in the financial industry calling for 3 years of experience in eg. MT530.

ISO 8583 which is used for handling most payment card transactions dates from 1987 is a little better in that at least it does expect to be able to send one or two small messages online, but still most of the heavy lifting is done after the fact in the settlement phase.

Most countries have their own electronic banking clearing systems with their own set of standards and procedures. The largest US clearing system ACH won’t even let you at their online rules website without buying a $79 book.

Security nightmares

Any non cash financial transaction consists of one or more entries known as book entries into various companies databases. By definition any act of creating a financial transaction is delegated by you to someone else. Whenever your transaction involves another bank your original delegation gets delegated onwards to x number of other institutions. Unfortunately the transactions are often unauthenticated. Whether you are sitting in a bank office ordering a wire transfer or handing a waiter your credit card you are delegating authority to transfer funds out of your account. This is why a check says “Pay to the order of…”.

Card payments do support some level authentication from pin to signing via an onboard smart card. But they aren’t used when performing an internet payment. This is obviously where much of the fraud goes on. Credit Card or ACH fraud essentially boils down to convincing (delegating) someone to transfer funds from the victims account.

Since you can’t satisfactorily secure the payment message most of these standards come with complex reconciliation standards that make up most of their complexity and even larger and more complex rule books. These rules are what allow you to deny a transaction when you get your statement a month later after the fact.

Enter PayPal

PayPal’s original Website Payment API while not a standard was a big step up over the actual standards in that it was born of the web. Web 1.0 yes but still the web. So rather than using REST to hide some of the complexity it uses a single URL with lots of different fields including optional non payment fields such as address and shipping details.

A big issue that PayPal had was that they still had to interface with the traditional banking world with their settlement times and insecure payments. To make it economical for them they need to use ACH and similar slow low cost national payment networks guaranteed by credit cards if these don’t go through. This is where much of the complexity of dealing with their Instant Payment Notification comes from.

Most of PayPal’s competitors use similar API’s to PayPal’s, but there hasn’t been any real standardization on it yet.

Their new Adaptive Payment API is much clearer. Yet still fairly complex for a new developer faced with it. And no it’s still not REST.

Why is it like this?

Closing Time

There are many reasons why banking related standards are complex. Most of them are historical. For example banks still operate 5 days a week with close of business at some time like 6pm decided many decades ago by gentlemen in top hats. Of course they do work 24 hours but all their processes are still based on this pre online world.

This means there is still a lot of batch processing going on in that last hour before closing. Most banks have a cutoff time a couple hours earlier than their official closing time to give them time to batch up and reconcile the days business. This is why you have to rush to the bank with your checks before 3pm on a Friday or it won’t get credited until Monday evening.

Settlement

Settlement is another important issue that all of these ancient standards have to deal with. Once you’ve bought that dry martini in the bar after work with your debit card, the money doesn’t actually leave your account yet. Your bank basically puts a hold on your money first. Then over the next couple of days they settle it through a network of banks and institutions depending on the country. Most of the settlement processes is done through batch processes once a day, the more step between your bank and the bars bank the longer settlement takes.

Most of these settlement (clearing) times are standardized by rules set out by central banks or banking associations. The holy grail for many of these systems is to reach what is known a T+0 clearing, which is fancy banker speak for instant clearing. It will take a long time for this to happen in most large economies like the US as there isn’t really a demand for it from anyone except consumers and small businesses.

Conclusion

Any new standard or API that attempts to deal with the existing banking standard is very difficult to simplify. You need to account for each countries settlement and fraud prevention rules. SWIFT was updated to a fancy smancy new XML standard, which didn’t do anything to simplify it besides making it easier to parse.

Any kind of innovation in this needs to be designed for an online world with 7 days, 24 hours and clear simple standards that only aim to solve a simple need. We have had this magic new technology now called HTTP thats been here for close to 20 years now and it’s been kind of successful. OpenTransact is only a very thin layer on top of HTTP and uses OAuth for its authentication, I think it is going to be big. But I will write more on that in my next post.

Last week I gave my talk on Agile Banking at Reboot 11. This week I have taken my talk and turned it into a series of blog articles that I will post here once a day.

Douglas Jackson was an oncologist from Melbourne, Florida. He was an idealist and thought the world would be a better place with a strong private currency away from the control of any government. So he created e-gold back in 1995.

E-gold is an electronic currency backed by real gold bars. Some people use it to invest in gold, but more commonly it was used like a regular currency to make and accept payments.

Doug was a true innovator. E-Gold created an easy to use API before PayPal allowing all sorts of small businesses around the to accept payments. At this time it was very hard for small businesses to get merchant accounts. E-Gold provided a real solution to this.

They let their users audit them

How much gold is in the system?

Where is the gold physically located?

What are serial numbers , exact weight and brand of individual gold bars

Real time usage statistics showing amount of transactions, transactions by size and statistics about account sizes

The e-gold mailing list kept them honest. People were analyzing the stats, theorizing and asking explanations from E-Gold staff for any thing out of the ordinary. Like this 10% drop in gold from the balance sheet in October 2001, where SnowDog performed analysis of why this was happening:

There are 11,161 accounts in the E-Gold system with over 10 grams of e-gold, (about $90 US in e-gold). This is almost the same number that E-Gold has supported for the past 6 months. So, it appears that most of the people with any significant balances are NOT selling their e-gold. The 10% drop in gold, in the past month, seems to be due to gold sales from small-balance accounts. E-Gold mini run

The community started creating tools to scrape and analyze e-gold

Craig Spencers E-gold revenue calculator

This was a mashup of the data on the above mentioned statistics page and their published fee structure. Note the sharp dip in 2007 (we will come to that soon)

Trust the system hate the man

Then Doug started acting like a bit of a bastard. Started suing several very nice people who were well known in the community. The mailing lists went berserk, Doug was called all sorts of names (very few of them good) and an alternative mailing list was set up in case E-Gold started censoring their own list.

Yet a funny thing happened. People continued to use e-gold. As a matter of fact the use grew and grew until at its peak there were $85 million dollars worth of e-gold in circulation. Not bad for a single activist entrepreneur from Melbourne, Florida.

Black helicopters

In 2007 the US government caught up with Doug. He was arrested and last year received a guilty verdict for “conspiracy to commit money laundering”. Doug was not performing “know your customer” a legal requirement in most countries that financial services institutions check the identity of their customers.

People are still kind of using e-gold. People are buying and selling black market auctions on their balances.

For more background on E-Gold check my article How the man finally brought e-gold down as well as Wired’s article Bullion and Bandits: The Improbable Rise and Fall of E-Gold.

In tomorrows post I will cover specific steps I think we could take as small entrepreneurs to innovate banking.

Earlier this week I wrote about Risky Business the core problem in todays financial services industry and Benches, Coffee and Bubbles about the origins of financial innovation.

These were all based on my Talk about Agile Banking that I gave at Reboot 11