In earlier posts, I alluded that micro‑transactions to read articles online are hard. In this article, when I say micro‑transactions, I mean being able to pay for articles individually on a per‑read basis. In theory, these micro‑transactions are the best of all worlds: no commitment from readers, granular controls for publishers, and direct monetization in line with supply and demand. However, that has not proven to be the case in practice.
From an implementation standpoint, micro‑transactions are difficult because in their simplest form, each article would require its own card transaction. This is impractical because of payment fees. Every transaction has a cost: fees, processing, communication with financial institutions, and risk checks. Doing a full transaction per read does not make sense. Another approach is needed: some form of batching or aggregation behind the scenes.
Do you batch per publication? That could work, but it would still mean each publication has to roll out its own system. It also leads to unpredictable revenue. Subscriptions are attractive because they provide “reliable” recurring revenue, ideally with minimal churn. That is why we see so many freemium and free‑trial subscription models locked behind paywalls.
As a result of this widespread push toward subscriptions, readers experience subscription fatigue. Will we read this publication enough to justify it? What about that one new article everyone is reading from a completely different publication—do we subscribe there too? So while it may make sense from a publisher’s perspective to rely on subscriptions, it is not always well received, and there is real demand for alternatives.
From a UX perspective (readers being greeted with a paywall), this is the critical point of friction. It forces a tough question: “Is this article going to be worth it?” More often than not, especially with any overhead in setting up payment, the reader will sigh and walk away, or scour the internet for another way to read the article. With AI in the mix, if they are just looking for information, they may bypass the article entirely and use an AI assistant. If they are familiar with the writer or publication and know what they are paying for, they may persist.
Previous approaches to 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, Flattr)
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.
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.
This is an interesting thought experiment that runs into a couple of big 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.
Browser extensions also suffer from opt‑in friction. Readers have to know the extension exists, install it, and keep it on. That alone limits how widely these systems can spread.
Blendle
Blendle was an app you could download to read articles on demand and be charged at the end of the month. Unfortunately, it suffered from a few problems:
You had to download an app. That is a large point of friction, and readers had to fully buy into the model for it to work.
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? The business model was not unreasonable, and more importantly, Blendle reached a critical mass of publications. When there is enough inventory in one place, readers are more willing to accept some friction.
Eventually Blendle moved away from this approach and into a more subscription‑like model after being acquired by Cafeyn.
Where Paperwall fits
So, what exactly is Paperwall and how does it fit into this space?
Paperwall is a pay‑only‑for‑what‑you‑read system that adds a pay‑per‑read option alongside existing paywalls. On participating publications, eligible articles can show a Paperwall prompt at the paywall: readers can either subscribe as usual, or pay a small, clearly priced amount to unlock just that article.
Instead of running a separate card transaction for every article, Paperwall:
Uses tickets as an internal unit to price and settle unlocks.
Maps those tickets to a small set of fixed local price points per currency (for example, 0.25 dollars in the US, 0.30 dollars in Canada, 0.20 pounds in the UK).
Batches the underlying billing and settlement so readers see a simple, predictable price and publishers get a clear payout, without dealing with raw micro‑transactions themselves.
From the reader’s perspective, this is “pay‑per‑read” at the point of the paywall: a small, local‑currency charge for that article, no subscription required.
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. Paperwall only appears at those paywalls.
It uses standard web technologies and integrates cleanly with existing paywalls. There is no app to download; it runs wherever you have a browser.
It can live alongside existing subscription paywalls using an SDK and documented integration path, instead of asking publishers to replace their infrastructure.
These are the technical pieces that separate Paperwall’s pay‑per‑read approach from earlier, more brittle micro‑transaction attempts.
The remaining challenge: “Is this worth it?”
The biggest remaining challenge is not technical; it is about confidence. At the moment of decision, the reader still has to decide: “Is this unknown article from this writer or publication going to be worth paying for?”
If an article is personally recommended, that is a simple decision. If you stumble across it randomly, it is less clear.
Paperwall’s broader vision includes elements to help with that:
A discovery layer that can show engagement signals across the network.
Social proof tools such as ratings, upvotes, and, over time, community‑style annotations.
People trust other people’s recommendations. Ratings, reviews, and simple engagement signals are how we choose movies, books, and products. Bringing some of that context to pay‑per‑read decisions can give readers more confidence that an article is worth unlocking.
Where this model works best
This model is not ideal for every type of content. It tends to work best for:
Well‑researched essays and explainers
Opinion pieces and analysis
Thoughtful long‑form reporting
It is less suited to brief news hits or light informational posts. Readers often expect basic information to be free and will either find another similar article or use AI, rather than pay for a quick fact.
If you are interested in trying Paperwall and seeing whether this kind of pay‑per‑read option fits your publication, you can get started here or follow along with the project.