Little Springs Design. 2001 – 2010.

Somewhere in my Twitter feed, I was pointed to Rita McGrath’s Why I Hate Micropayments on Harvard Business Review. A nice read, and points to several problems. But I’m not ready to throw the baby out with the bathwater.

When originally conceived, micropayments were pennies, fractions of pennies, or maybe small fractions of dollars. This has unfortunately migrated into $0.99 or even $2.99 “micropayments.” Maybe these are “centipayments?” Nah, too geeky. “Minipayments” is better.

I think the minipayments evolved because you can’t make micropayments work financially for a single site. With credit card fees starting at $0.30, a $0.05 payment isn’t going to fly. Even Paypal’s current offering is $0.05 + 5% for micropayments.

I’ve seen some attempts to create cross-site micropayment systems, but they were way too small and folded soon after. At one point I had sent $10 on each of three systems, but only ever got $3 worth of content out of any of them.

Premium SMS is great, except that you only get at best 25 cents on the dollar.

Problems with minipayments

Right now, minipayments have business and user experience problems.

• They are large enough to make you think about clicking, to actually track the money. I could have gotten a song for that! Or a cup of coffee! Or a turnpike toll!

• Each micro-purchase is made with a separate financial decision, unlike turning on a light switch, sending a text message, or driving to the store. Each of these other decisions have financial consequences, but few of us think about it.

• Most of these decisions also have a high time and attention cost. Entering credit card data, for example, is slow. Even password entry creates a barrier to entry. These extra user steps remind the user of the dollar cost as well.

There are places where minipayments are making sense. Apple’s iTunes store is clearly an example. Arguably, other app stores are also successful.

These success stories have addressed part of the minipayment problems. Customers have a single iTunes account, they aren’t really paying attention to how much they are spending, and Apple is left to get the money to the content creators.

But a central store for web content simply won’t work. The “store” needs to be highly distributed.

Other successful models

For sites with known value, small annual payments are useful. Flickr’s professional account is $25 for a whole year; $2/month is invisible to nearly all.

Monthly fees are more problematic, as customers get reminded every month of the cost. We subscribe to a few services, and seeing $50 here, $25 there, and $100 over there every month is painful. I find myself stripping down services like this.

Annual payments could work for some content companies, but customers would have to know the value. I’d happily pay $20/year for Harvard Business Review content, but I will not pay $4/article on nearly any site.

Making micropayments work

In short, we need an ecosystem for acquisition and payment of content, especially long-tail content of all flavors. If done correctly, the ecosystem could allow bands to sell their songs directly, application developers to sell their apps directly, and of course some web pages to be behind paywalls.

Micropayments need to be beneficial to the content owners, the payment providers, and to the end users. Here’s one way how:

1. A large brand, such as Visa, Paypal, Google, or mobile operators, creates a micropayment platform. Actually, we need to see several of these.
   • Mobile operators would simply use their payment gateway. For more, check out Visionmobile’s Why mobile can bring back the value to the internet
   • Google and Paypal may need to require the account to be primed with a small amount of cash, which can be withdrawn at any time and also applied to other purchases.
   • Visa and Mastercard could make micropayments available to good customers carrying a balance, or perhaps add an annual $10 fee
2. Payment providers create a signup for content owners intended to be fast and simple, more like signing up for Adsense than for an App Store.
   • Protecting against fraud may involve a refundable deposit, scaled against projected sales volume, for unknown providers
   • Content owners should sign up for as many payment systems as possible
   • Payment provider provides buttons for their call to action
3. Credit or debit cards associated with micropayments get charged once per month, or similar, perhaps just refreshing the account balance. It could vary by provider.
4. A pre-pay option could be cash-based, much like buying minutes
5. Content behind a paywall would have an array of payment buttons next to it, much like the social media share buttons on blog entries right now.
6. Purchases are one-click or click + passphrase, based on security settings
   • Purchases are limited to one per 3 minutes (fraud protection)
   • More than, say, $5 spent in an hour triggers an authentication request
   • No purchase can exceed $3 without an authentication request
7. The payment provider returns an approval code that allows the content to be displayed.
8. Payment providers have easy-to-integrate code for hiding and revealing the content, ideally using a standardized micropayment API

By batching the transactions to a weekly or monthly level, we reduce the effects of transaction fees. The same function makes the price effects of the purchase less visible to the customer.

By allowing purchases with a click or very short code, we reduce transaction friction for end customers. By providing several types of accounts, we provide flexibility for end customers to choose the right type, such as mobile phone, debit, or prepaid.

I agree, this isn’t the way to save the newspaper industry. But it’s more likely to help than to require that I pay $5 for a week’s access and have to sign up for a specific site. And it could be highly disruptive for a number of long-tail publishers.