A look at the Opensocial Virtual Currency API proposal

The Opensocial virtual currency API proposal is at revision #3. There has been growing interest in the money geek community as to what it might entail, so I thought I’d take a stab at it.

First of all, we are talking about virtual currency, that is governement-currency converted to a separate denomination to provide the following benefits:

  • Allow those without a bank account, particularly kids to be able to convert cash into virtual currency by way of gift cards.
  • Higher relative denominations (ex. $1USD = 10 virtual currency unit) for psychological impact: to increase the perceived value of virtual goods sold and of monetary gifts received.
  • Usually, non-convertibility or limited convertibility back into government-issued currency, which limits liquidity risk on the issuer side while allowing the issuer to use the currency as a way for users to earn by participating, checking-in, accomplishing tasks, volunteering personal information, etc.
  • Typically shouted transactions in the social graph as a way to seek mimetism of donations by social graph members or to increase social capital and seek indirect reciprocal benevolent behaviors.


The first paragraph of the design explains the primary motivation for the API. The API provides essentially a way to workaround the fact that the application requesting the payment does not hold user’s credentials required to authorize the payment, so it has to communicate first with the container of the application, get the user’s authorization at that level, before the request can be passed to the authorization system.

A bias towards single currency per app

Looking at the details of the API, what is interesting is that there is no currency passed as part of the Payment object, only an amount and a reason. In fact, the currency is implicitly specified via the a opt_paymentHandlerUrl parameter (the URL of the payment handler) or via a pre-registered payment service URL.

In other words, it is designed primarily for applications who only deal with their own single currency, although it does not prevent an application to support multiple payment URLs. In all cases, each currency is tied to a currency service. It should also work very well for applications, which want to use a third-party currency and currency transaction service.

A bias towards purchases/rewards

Looking at the required versus parameters, the API seems really biased towards transactions between the application and the user such as virtual goods purchases.

The API supports both debiting the user’s account and crediting it, which means the API can be used to authorize both purchases and rewards for the user.


Despite the above mentioned biases, flexible “parameter” parameter can contain any application-specific data that the application may want to transmit. This opens the door to referencing invoice #, destination accounts, currencies, etc

4 thoughts on “A look at the Opensocial Virtual Currency API proposal”

  1. Just looked at this. It strikes me as overly complex. There should be no need for that level of complexity for what is basically a book entry transfer.

    With regards to multi currency, I think it's best to do that a layer above the actual currency level. In other words it's not the currency issuer's job to perform an exchange between multiple currencies.

  2. Hello Guillaume, I found this page on Google and later found you posted it to Open Money@ning. My group is currently working on a similar idea. If you are interested in learning more, please send me an email I'd be happy to talk.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>