Tag: virtual currency

Tookets: a charitable rewards currency

A Credit Union in France just announced the opening of a new online agency called Tookam. Besides a number of innovation related to social networks, the new agency provides a virtual currency that helps businesses engage their customers with charitable rewards, that is: rewards that can be turned into donation in government money to a charity chosen by both the business and the customer.

It’s an interesting variant on the “donate 1$ and our business will match it”, instead: “give us $x of your business and we will donate $1 to one of the charities we support”

It works as follows:

  1. The business establishes a rewards program in Tookets and pre-defines a number of charities that the tookets can be converted in Euros and donated to.
  2. Customer earns the tookets as they do transactions with the business.
  3. The customer can then turn some of the tookets into Euros and donate them to one of the charities pre-selected by the business.

What’s interesting here is the alignment of values that it creates between the business and the customer. By looking at the list of charities that the business’ rewards program support, the customer can decide whether to increase or stop shopping at this particular business.

This program fits in the larger trend of rewarding real-life purchases with virtual currency. By defining what their rewards currency can be converted in, the business has another opportunity to express their mission and connect meaningfully with their customers.

There is no reason that this model be limited to charities: rewards could for instance be converted to donations to specific projects, such as the ones found on SpotUs or Kickstarter.

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

When will payment networks open up to non-government issued currencies?

Probably sooner than later, not only because these new kind of currencies are currently popping up all over the place and represent a lost opportunity for payment networks, but especially because there are very valid business use cases.

First of all, what are we talking about?

A payment network opening up to non-government issued currency would essentially allow payments to be done non just in US dollars or any other legal tender, but in privately-issued currencies, whether it’s World of Warcraft gold coins, Facebook currency or others. In particular, multi-currency payments would be possible: say 20% of the amount in a currency and 80% in another, which isn’t possible right now.

Furthermore, non-government issued community or virtual currencies are by nature circulating within a specific group of people, with limited conversion from/to real US dollars, which reduces revenue for payment networks exclusively focused on US dollar. It would be much better for payment networks to provide their operational expertise to communities and charge for it.

What would be the business case?

Think about the following scenario: you log in to Amazon and have registered your World of Warcraft username, so Amazon knows that you are a player. You have authorized Amazon.com to access your WoW balance and submit transactions on your behalf (say via OAuth). You now browse to a produce page, and instead of the regular price of $100 (USD), you see $80 (USD) and 20 WoW gold coins. You press the buy button, and $80 are taken out of your credit or debit car or bank account, while 20 WoW gold coins are transferred to Amazon.com WoW account.

Why would Amazon.com do that?

  • It’s a very cheap way to target and attract a particular community of customers that they can further target with specific offers knowing what they like.
  • It’s a perfect way to build their brand using the accumulated game currency on the virtual world
  • They can use the acquired game currency to target specific players with incentives to purchase at Amazon.com
  • As long as they see value in using these acquired game currency to build their brand (i.e. they recirculate them), it’s really not a rebate, simply a different use of their marketing dollars.

Beyond game currencies

Beyond game currencies, the above use case would be valid for any community currency, say of a particular city or neighborhood. It may not work very well for Amazon in the case of a neighborhood since Amazon.com may not be willing to spend too many dollars on a particular local community, but that’s the point: if they don’t, why would the local community shop at Amazon.com? there are probably other retailers that would be happy to collect currency that they can redeem for advertisment in a local newspaper or local Web site.