Why micro-transactions have failed in the past

In earlier posts I mentioned that micro‑transactions to read articles online are hard. When I say micro‑transactions, I mean paying for articles individually, on a per‑read basis. In theory it is the best of all worlds: no commitment from readers, granular control for publishers, and prices that track what people actually want to read. In practice it has not worked.

The trouble starts with the payments themselves. In its simplest form, every article means its own payment, and every payment has costs: processing, risk checks, talking to banks. On a twenty‑five cent sale, the fee can swallow the margin. So the money has to be batched elsewhere.

Do you batch per publication? It could work, but every publication would have to roll out its own system, and the revenue would be unpredictable. Some subscription paywall tools do offer a version of this: add your card, then buy individual articles from that publication. But it has not gained much traction, because the value prop is still narrow. Readers are being asked to set up payment details for one site, with no guarantee they will want enough from that site to make the effort worthwhile.

So the other option is a third-party system many publications can opt into. There have been plenty of attempts at that.

Previous attempts at micro‑transactions

The problems faced by earlier micro‑transaction models are not insurmountable, but they are real. A few common approaches:

Donations

(Buy Me a Coffee, Patreon, Ko‑fi)

The idea is that after reading an article, if it was worth it, a small donation is sent the author’s way. This is appealing, but depends heavily on reader goodwill. At the end of an article, few readers will invest the time and effort to set up an account, add a card, and contribute. It can work for some writers, but is rarely a reliable, primary revenue model.

Some major publications have made reader contributions a central part of the business, including The Guardian and The Walrus. These prove donations can work at scale, but it also shows how much has to be true first. Readers need to know the brand, trust its work, and feel some stake in its survival. That kind of brand relationship takes years to build.

For smaller publishers, donations are usually a supplement rather than a substitute for paid access. They ask readers to pay after the value has already been delivered, with no direct exchange attached to a particular article. Some people will do that because they want the publication to exist. Most readers, most of the time, will not.

Browser extensions

(for example, Flattr‑style models or older micropayment APIs)

One model relies on a browser extension with your bank account or wallet connected. It tracks what you visit, and when a publication registers, it receives a share of your monthly spend based on your visits.

It's a neat idea that quickly runs into a few problems:

• It is unpredictable in terms of value per read, because you have a finite pool of money being divided among many sites, and it still relies on readers choosing to enable it.
• It requires a high level of tracking. The extension has to see everything you visit, and most people are understandably uncomfortable with that.
• It depends entirely on opt‑in. Readers have to know the extension exists, install it, keep it enabled, and then do all of that again on every device they read from.

That last point alone limits how widely these systems can spread.

Blendle

Blendle was the most serious attempt at the pay-per-read model, and it ran on a prepaid wallet. Readers topped up a balance, ten or twenty euros at a time, and each unlock drew it down. Publishers set their own prices, generally somewhere between nine and forty-nine cents, averaging around a quarter, and Blendle kept thirty percent. If an article disappointed you, there was a one-click refund available for 24 hours, and about five percent of reads were refunded.

That refund button is worth pausing on. Readers had no way to judge a piece until after they had paid for it, so Blendle had to build them an undo. Five percent of reads resulted in a refund.

It also ran into several problems:

• The app was the centre of gravity. In later stages, there was a Blendle Button that let readers pay on a publisher’s own site, and some experimentation with integrating directly into Dutch paywalls, but the main experience involved downloading an app and buying into the model wholesale.
• The wallet asked for money before delivering anything. Ten euros up front is a far bigger decision than a twenty-five cent article warrants, and the reader carries the risk on whatever they never spend.
• The discovery experience was limited relative to what you might expect from the broader open web.
• It mostly worked for larger, established publications; smaller independent blogs still needed an easier on‑ramp.
• It primarily took off in Europe.

What did it get right? Quite a lot. Blendle reached a critical mass of publications, and with that much variety to access, readers will accept some friction. Its pricing is also a useful data point. Publishers set their own prices and landed on an average of roughly €0.25 an article, almost exactly where Paperwall's ticket price sits, which is decent evidence of what a single piece is worth to people.

Eventually Blendle moved away from this approach and into a more subscription‑like model after being acquired by Cafeyn.

How Paperwall fits in

Paperwall is the latest attempt in this space: a pay‑per‑read system that lives alongside existing paywalls. On registered publications, enabled articles show a second option at the paywall. Readers can either subscribe as usual, or pay a small, clearly priced amount to unlock just that article.

Two design choices differentiate this solution:

• Bills on usage rather than up front. A reader adds a card once. Unlocks accumulate over the month and settle as a single charge at month-end, so one payment fee covers however many articles were read. Publishers are then paid out according to the number of articles unlocked.
• Uses tickets as an internal unit to price articles and pay out publishers, mapped to a small set of fixed local price points ($0.25 USD, $0.30 CAD, £0.20 GBP). The split on net revenue from article unlocks - 30/70 split after processing fees, where Paperwall keeps %30 and the publisher takes the remaining %70.

Billing based on usage instead of topping up an account answers the fee problem from the top of this post. The batching has to happen somewhere, and doing it at the end of the month means the reader never pre-commits or has credit stranded in an account they stopped using.

How does this address the shortcomings of previous attempts?

• It shows up before you read, at the paywall moment, instead of relying on goodwill after the fact. The decision is made when interest is highest.
• It is not a browser extension and does not track your entire browsing history. Publications explicitly register with Paperwall, and access only appears on the articles they enable.
• It uses standard web technologies and integrates cleanly with existing paywalls. There is no app to download and it runs wherever you have a browser.
• It lives alongside your existing paywall instead of replacing it and the integration is quick and flexible: a few lines of copy-paste code, or a deeper SDK implementation if you want one.

Adding a card up front is still a point of friction, but the difference is that the reader adds a card once, access is granted across all participating publications, and no money changes hands until the end of the month. After that first setup, each unlock is just a small decision at the moment they actually want the article.

When Paperwall shows up is important too - it provides alternative access, not as the primary access point to an article. A piece behind a paywall has already been marked as premium by the publisher, and the other option on the page is a full subscription. The paywall does most of the vouching; Paperwall only has to be the cheaper option, which makes the one-off unlock an easy choice.

Where should pay‑per‑read apply?

Which articles should fall behind this pay-per-read paywall is largely a question of how easily the piece can be replaced. If a reader can get the same thing free somewhere else, they will. General news and basic information are everywhere, and if all someone wants is the facts, they'll find them on another site or ask AI.

The pieces worth enabling are the harder ones to substitute: original reporting; the explainer people link to; analysis that works because of who wrote it; an old, timeless piece that is still an authority on its subject. An evergreen piece can pick up unlocks for years, while breaking news can be dead in a week.

For most publications the split is roughly: daily news stays free or a blanket subscription, and pay-per-read for features, essays, opinions, and the archive. The archive is usually the easiest place to start. Those pieces aren't converting subscribers anymore and most of them earn nothing at all, so there isn't much risk in trying.

A note on the blanket subscription: for daily news in your area, subscribe to at least one publication featuring high quality journalism and/or local reporting - they do amazing work and are the bedrock of keeping the world informed.

Where that leaves us

The problem was never that readers won't pay for one article. Blendle's publishers set their own prices and landed around €0.25, which tells you something about what a single piece is worth. What went wrong was the shape of the ask. Donations come after the reading is done, when there is nothing left to gain by paying. Extensions want you to install something and be tracked. Blendle's wallet wanted ten euros before it handed over anything. Per‑publication checkout wants your card for one site, on the chance you come back.

Paperwall's answer is the latest arrangement of all these pieces:

1. Put the option next to the subscribe option as alternative access, where the reader is already making a decision.
2. Register the payment method upfront, for every publication in the network.
3. Charge nothing until the end of the month, which is where the transaction fees don't kill the billing model.

So the payments are no longer the open question. It's whether a reader at a paywall takes the cheaper option when it is put in front of them. That is a conversion problem, and the only way to answer it is to try it out.

If you are interested in seeing whether this kind of pay‑per‑read option fits your publication, you can try it out here or follow along on with this newsletter.