Business models
The ways a BSV product can earn when a payment costs less than a penny: pay per use, metering, allowances, tipping, credit to try, unbundled subscriptions and models without advertising, with what each asks of the user.
When a payment costs a fraction of a penny and needs no account, you can charge for the thing the user wanted, one at a time. That opens models that were never worth a processing fee. It also moves the hard part from collecting money to keeping the user comfortable while you collect it.
Every model below runs on the same parts: a payment from the user's wallet, often inside a web request, and an allowance that lets small payments happen without a prompt each time. See Payments and Charging per use.
Pay per use
A price on each thing: an article, a request, a download, a level. The user pays only for what they take, and you need no account system to know who has paid.
For the user: they pay only for what they take, and do the most arithmetic. A heavy user feels every unit.
Do
Charge for the unit the user already thinks in: an article, a song, a search. A price per kilobyte or per token is a price nobody can predict.
Metered or streamed payment
A running charge while something is in use: per second of video, per minute of a call, per unit of compute.
For the user: precise, and the most likely to frighten, because the number moves without them doing anything. The pattern is in Metered spending.
Do
Choose metering only when the value genuinely accrues over time. If the user would describe what they bought as one thing, charge for one thing.
Prepaid allowance
The user grants your app a budget in their own wallet, and payments inside it happen without a prompt. Nothing is paid in advance: the budget stays in the user's wallet, and only what is spent leaves it. This is what makes per-use and metered models usable at all. It is less a model than the mechanism the others run on, which is why it appears in the table as a way of deciding. See Spending allowances.
For the user: one decision instead of hundreds, with the risk bounded by the amount they chose.
Don't
Build a prepaid balance that your app holds in place of an allowance in the user's wallet. Money sitting with you is a custody decision, and the allowance does the same job without it. See Custody as a product decision.
Tipping
A voluntary payment after the user has had the value. Small payments make a tip of a few satoshis worth sending, and a handle makes it easy to direct to a person rather than a platform. See Paying by handle.
For the user: no obligation, and a small pleasure if it is quick.
Do
Put the tip where the value was felt, at the end of the article or the stream, and send it to the creator's handle, saying if the platform keeps any of it.
Paying people to try
Sending a new user a small amount, called credit to try on Growth that pays, so their first experience is holding real money, or paying for a first action you want them to take. The guide's onboarding advice already points here: the first thing a new user does should end with them holding money. See Learning by holding something.
For the user: a reason to start that costs them nothing. For you, a cost per new user that you set, and a target for anyone farming rewards. See The risks.
Unbundling a subscription into uses
Selling the same catalogue per item rather than per month. The occasional reader who would never subscribe can buy one article; the regular one can grant a monthly allowance that behaves like a subscription with a ceiling.
For the user: they pay for what they use. A regular user may pay more than a flat fee would have cost.
Do
Offer a cap that matches what the subscription used to cost, so a heavy user never pays more than they would have. "Never more than the monthly price" is a promise people understand.
Don't
Remove the flat price and leave only per-use pricing for a product people use daily. The ones who used it most are the ones the change punishes.
Models that do not need advertising
When a reader can pay a few satoshis for one article, the page does not have to be paid for by their attention. That is also an argument for keeping data collection small: a product paid per use has less reason to know who its users are. See Getting to know your users.
Do
Say on the paid page what the payment replaces: "No ads on this article, you paid about 1p (20 sats) for it." The connection between paying and the absence of ads is the product.
Don't
Charge per use and show advertising on the same page. The user paid to remove the thing you are still showing them.
Comparing them
| Model | The user decides | Hardest part |
|---|---|---|
| Pay per use | Each time | Arithmetic for heavy users |
| Metered | When to start and stop | A number moving on its own |
| Prepaid allowance | Once, then reviews | Showing what was spent |
| Tipping | Afterwards, if at all | Revenue nobody can forecast |
| Credit to try | Nothing | Fraud and fake accounts |
| Unbundled | Per item, or once a cap | Moving existing subscribers |
Recommendation
Pick one model as the default and add others as options. A product offering per-use, metered and tipping on the same screen has asked the user to choose a business model.
Charging while nobody is looking
The contested practice in these models is a charge that continues when the user's attention has moved on.
Keeping a meter running
- OK: the meter runs only while the content is on screen and in use, and stops when the user leaves.
- Grey area: it keeps running in a background tab or a minimised app, with a visible indicator and a ceiling the user set.
- Not OK: it runs until the allowance is exhausted, whether or not anybody is watching.
Open questions
- Do people prefer a per-item price or an allowance for content they use weekly? Nobody has published a comparison on BSV products.
- Does a visible "no ads, you paid" line change how people feel about paying, or only about the ads?
- What cap on an unbundled subscription feels fair to a heavy user without costing the business its regulars?
Related
- Charging per use: the design of the payments themselves
- Pricing
- Letting an agent spend: when software is the customer
- Growth that pays
- Pay-per-use reader: the per-use model as a full design
- Custody as a product decision
Written from: /guide/patterns/charging-per-use/, /guide/patterns/connecting-a-wallet/, /guide/patterns/letting-an-agent-spend/, /guide/how-it-works/payments/, /guide/designing-products/usage-life-cycle/, /guide/designing-products/getting-to-know-your-users/.
Checklist
The rules on this page, in a form you can work through.
9 rules