Transaction Payment Revenue Models

Per user payment models work fine when usage doesn’t vary significantly between users; usage being clustered close to an average. It starts to break down if some users can benefit much more than others; heavy users then get subsidized by light users, leading to two possible outcomes: either the light users break away to another less expensive alternative, or begin to waste the resources in a bid to redress that inequality. Both of these are inefficient options, driven by inefficiencies in the Revenue Model.

That’s where transaction payment models make sense. Payment is linked to usage, rather than to number of users. A heavy user pays proportionately more as compared to a light user, because he benefits more.

Ebay is the classic example. The fees paid relate to the value of the transaction and the number of transactions, providing a greater equality between users. Online marketplaces like Elance have similar models.

Not surprisingly, several 2.0 sites have also adopted similar revenue structures. Prosper and Zopa, among the best known peer to peer lending sites, have fees based on the amount lent and borrowed – both participants in the transaction pay fees.

Transactions can be of many types – including services not thought of before. Payperpost links bloggers to link builders and takes a fee per transaction. Google Answers provides a way to get specific information solutions in return for a fee to the provider plus a listing fee to Google.

It even extends to fundraising of all kinds. Check out Fundable and Chipin – they allow you to raise funds through contributions – and charge a fee for success.

Transaction based models work well when you have a sizeable marketplace and an ability to control transactions – and the transaction have value for the users. Expect to see more of these coming up in the future.