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.

Motivation

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.

Extensibility

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