Payment systems

edit topic

The May Scale of Money Hardness and BitCoin

Posted by Pelle March 7th, 2012 12 comments edit

About 10 years ago after a bunch of E-Gold exchangers lost money from fraudulent purchasers performing chargebacks Start e-gold app developer JP May published his May Scale of Money Hardness (only on wayback machine now).

The idea is that the easier it is for a payment to be reversed, the softer it is. I’m trying to update it for 2012 so the next generation of financial startups don’t get burnt more than they already have been and learn the lessons learnt by the e-gold community.

Original May Scale

Hardness Item
1 Street cash, US dollars
2 Street cash, euro currencies, japan
3 e-gold
4 Street cash, other regions
5 Interbank transfers of various sorts (wires/ACH etc), bank checks
6 personal checks
7 Consumer-level electronic account transfers (eg bPay)
8 Business-account-level retail transfer systems
9 Paypal and similar ‘new money’ entities, beenz
10 Credit cards
(Ridiculously soft)

Updated May Scale

Hardness Item
1 Street cash, BitCoin, Gold/Silver Coins
2 Western Union and other money transmitters
3 Account based electronic currencies fire walled away from banking system (e.g. Liberty Reserve)
4 International wires
5 bank checks
6 ACH, personal checks
7 Consumer-level electronic account transfers (eg Dwolla, AlerPay), BitCoin sellers (BitInstant, MtGox etc)
8 Business-account-level retail transfer systems, credit cards (brick and mortar)
9 Credit cards (via internet or phone)
10 PayPal
(Ridiculously soft)

updated 3/8/2012 Based on comments I moved things around a bit. Ordinary bank wires are more less reversible than ACH’s. The scale shouldn’t cover default risk only reversal risk so I’ve moved all street cash to 1. and added gold/silver coins to it. I’ve added electronic currencies like Liberty Reserve that are fire walled away from the banking system to 3. Any account based system that interfaces directly with the banking system will be in 7, so AlertPay belongs with Dwolla as their banking connections can also put undue pressure on them. I still consider Personal checks risky. At least until it clears so I’m leaving that at 6. Also see The BitCoin Wiki’s Payment Method page for alternative rating

Why do I place Dwolla above PayPal? Mainly because they exclusively use the ACH system and not the credit card system, which makes it harder for people to perform chargebacks.

Why is PayPal below Credit Cards then? While it is a blended system of ACH and CC, their risk management procedures makes it even more risky to merchants than using a straight credit card processor. Just by virtue of being successful or having one or two chargebacks they will freeze your accounts.

What can we learn from the May Scale?

Purchasers benefit by having softer money as it reduces risk for them and merchants benefit by having harder money.

If you are selling game credits, subscriptions to a web service without any significant cost to you the benefits and ease of accepting soft money is fine.

It is slightly trickier for merchants sending physical goods to users. The merchant does have a risk, but the shipping infrastructure does provide some insurance and documentation that partly alleviates it.

If you are selling financial instruments, real estate, cars and other high value items you should not accept anything higher than 5 on the May scale. As a matter of fact due to anti money laundering laws since the original May scale was written you probably shouldn’t accept anything less that 5 either.

If you sell BitCoin you are in a little bit of a different situation similar to e-gold exchanges of yore, due to the growing hostility to it from financial institutions and governments. Depending on how high your spread or transaction fee is you could accept the risk of accepting bank transfers, in particular if you limit the size and frequency of transactions with customers until you feel you can trust them. But I would probably stick to 3 or below.

One risk potential risk with Number 3 is that you might accept a Western Union transfer from a party who is on the terrorist watch list, in which case you could get associated with them. This is a particular risk if you are not registered with the FSA (in the US) or similar elsewhere and did not perform some level of Know Your Customer.

Why soft money?

Most of the soft money is based on book entry systems with central authorities. One of the benefits of this is that in case of fraud it is possible to contact this central authority and reverse a transaction.

BitCoin is also a book entry system, but there is no central authority so there is no way of reversing a charge.

So if you as a consumer buy some coffee with BitCoin and the merchant doesn’t send it you there is no real recourse unless you know who the merchant is and are able to take the merchant to small claims court.

Because of this there is a trend within the BitCoin community of having centralized BitCoin denominated book entry systems that temporarily keep the funds in a reversible place. There are also BitCoin escrow agents. These are potentially good solutions, of course you also need to trust the operators of these or they may just run away with your BitCoin. There were probably more fraudulent than trusty escrow services in the e-gold days. I would expect the same with BitCoin.

There is also a risk to the merchant in BitCoin. See the recent Linode Bitcoin fiasco. If they were using softer money they could have called the central authority (PayPal etc), freeze their account and have dodgy transactions reversed.

Anyway none of this is easy. If you are trying to do something with BitCoin or other kinds of alternative financial services you need to think about it for your business.

OpenTransact vs PaySwarm part 2 - yes it's still mostly out of scope

Posted by Pelle January 2nd, 2012 1 comments edit

The debate continues. Please read the first part of my response OpenTransact the Payment Standard where everything is out of scope first.

Manu wrote a new response which I will respond to in a separate blog post. First let me finish responding to the original

Generally this post will again reflect the differences in approaches. OpenTransact is a single layer simple pragmatic standard for performing payments nothing else. PaySwarm is a fully featured idealistic multi layered approach where you must buy into a whole different way running your business.

A Facebook friend suggested that OpenTransact vs PaySwarm is like Libertarianism vs Socialism. I don’t quite buy that in practice as I know that PaySwarm is not about forcing anyone to do anything.

However the basic PaySwarm philosophy of wanting to design a whole world view is very similar to central planning or large standards bodies like ANSI, IEEE etc. OpenTransact follows the market based approach that the internet was based on of small standards that do one thing well.

OpenTransact the payment standard where everything is out of scope

Posted by Pelle December 21st, 2011 1 comments edit

The W3C Web Payments Community Group was launched in August 2011 because Digital Bazaar had created their PaySwarm spec. I have been working with several others since 2009 on bootstrapping an open grassroots created standard OpenTransact with pretty much the same purpose as PaySwarm. I immediately joined the W3C group to see if we could work together towards our obvious common goal.

Different philosophies

So while we both shared this common goal, the fundamental philosophies of PaySwarm and OpenTransact could not be more different.

PaySwarm attempts to solve every single problem up front and thus creates a standard that is very smart in many ways but also very complex. It’s background is I understand in a P2P media market place called Bitmunk where licenses, distribution contacts and other media DRM issues are considered important. Manu Sporny of Digital Bazaar has also been a chair of the RDFa working group so PaySwarm comes with a lot of linked data luggage as well.

OpenTransact comes from the philosophy that we don’t solve a problem until the problem exists and several people have real experiences solving it. I have also been very active in the OAuth community and believe there are many things both good and bad that can be learnt from that process and how developers took to it. OpenTransact also follows the tradition of early web standards of having most parameters as optional.

On currencies, virtual or otherwise

Posted by Pelle December 7th, 2010 3 comments edit

Currency is one of the most popular buzzwords right now and there are lots of different definitions. I’ll try to unify them in some way and talk about some of the issues involved. Over the next couple of posts I’ll try to analyze what currency is.

Maceration of Money

If you ask most people on the street, currency is what they have in their bank account and in their wallet.

Gamers will tell you that currency can also mean numbers on a screen earned and spent within a game.

Silicon valley hipsters will also try to say that Virtual Currency is the latest monetization strategy out there, often without realizing what it really means.

Community activists also like to remind us of all the successful community currencies that have sprouted up in the past few years.

So my first attempt at a definition is:

A currency is a fungible asset that can be transferred from one person to the other.

Now under that definition we may also need to include stocks, options other securities. As they are generally transferrable and fungible. Most people wouldn’t consider them currency, but they fit the definition perfectly. I’m personally quite happy to consider them currencies.

Virtual Currencies?

What makes a currency virtual or not? It’s not wether it has any real value as World of Warcraft Gold clearly has value. I’d say it depends on the backing of it. So an attempt at a definition:

A virtual currency is a currency backed by the promise of it’s issuer.

Closed loop currencies

A closed loop currency is a currency only meant to be spent with the issuer. Good examples are Starbucks Cards, but most game currencies are also closed loop currencies as you can only use them within the games.

What about Whuffie, Page Rank and other reputation currencies?

That is a good question. These are currencies that are objectively awarded and taken away based on your standing/actions in a community. Pagerank is often also described as a currency. Most of these break my definition above as they aren’t generally speaking transferable.

Whether they are really fungible is also a good question. A Google PageRank of 8 would have to be worth 8 times a PageRank of 1. But clearly that is not the case.

In my next post I explore a few different flavors of what many of us think is just one currency, the all mighty US Dollar.

Open Web Payments - an alternative to OpenTransact

Posted by Pelle July 22nd, 2010 edit

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=[email protected]&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=[email protected]&memo=Milk&amount.2=2.00&to.2=[email protected]

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 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:

  • – do whatever default behavior is

These options could be presented to merchant using WebFinger.

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


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.