Charging per use
Charging a few satoshis many times: the patterns that work, the prompt problem, and how to show hundreds of payments without making somebody anxious.
Charging per use means taking a few satoshis for each article, request or second. We recommend an allowance the person grants once, the price shown where they decide, and a running total with a stop control wherever the spending happens.
The network fee on a 20-sat payment is less than 1p, so charging per article, per request or per second is practical. It also creates a design problem subscriptions do not have: the payment happens hundreds of times, and a prompt each time would end the product.
The three models
Pay per use. A price on each thing. Honest and granular, but it makes the user do arithmetic if they use it a lot.
Allowance. The user grants a budget once, and payments inside it happen without a prompt. We suggest an allowance for most products.
Pay as you go. A running meter, charged continuously while something is used. Right for streams, compute and time-based services, and the hardest of the three to show honestly.
See Spending allowances for how an allowance is granted.
The prompt problem
A prompt per payment is correct and unusable. No prompt at all is usable and indefensible. An allowance resolves this, and it is only as good as what you show afterwards.
What the user actually agreed to
An allowance is consent to a budget, not to each payment. So the interface owes the person two things a prompt would have given: the ability to see what happened, and the ability to stop it. Both after the fact, both one tap away.
Do
Show the running total against the allowance wherever the spending is happening, not only in a settings screen.
Do
Put a stop control next to that total. One action, no confirmation, effective immediately.
Don't
Renew an allowance that has ended without asking the user again. A limit that starts again each month within a live grant is normal, provided the reset date is shown beside what is left.
Renewing an allowance
- OK: the limit starts again each month within a live grant, as the permissions standard's monthly limit does, with the reset date shown. When the grant ends, ask again, showing what the last one was spent on.
- Grey area: a reminder before the grant ends, with a one-tap renewal the person still has to press.
- Not OK: renew a grant that has ended without asking, so the user only finds out from their balance.
Price it where they decide
A price shown after the click is not a price. It is a receipt.
Do
Put the cost on the thing: "about 1p (20 sats)" on the article link, "5 sats per request" on the endpoint.
Do
Lead with local currency for anything a person chooses to buy, and with satoshis for anything software decides, with the other figure beside it. "About 1p" means something to a reader; "20 sats" means something to a developer.
Don't
Round a per-use price up to something tidy because the real number looks odd. The real number is the product's best argument.
See Amounts and units.
Showing hundreds of payments
The activity list is where charging per use goes wrong. Four hundred rows of "20 sats" is a record in theory and a wall in practice.
Do
Group by what the user was doing, not by transaction. "The Satoshi Vision, 14 articles, about 14p (280 sats)" is one row they understand.
Do
Let that row open into the individual payments, for the person who wants them and the accountant who needs them.
Do
Lead with the period total. "About 24p today" answers the question they actually have.
Don't
Show a notification per payment. The first one is informative, the fortieth is why the feature gets switched off.
See Activity.
Metered spending
A meter running while something is in use is the model most likely to frighten people, because the number moves on its own.
Do
Show the rate and the elapsed cost together, and update at a pace a person can read. A figure changing ten times a second is not information.
Do
Make stopping obvious and instantaneous, and confirm that it stopped. "Stopped. You spent 340 sats." closes the loop.
Do
Offer a ceiling before starting, not only an allowance. "Stop at 5,000 sats" is a different and more reassuring promise.
Failures
At this scale a failure is not an event. It is a rate.
Do
Decide what happens when one payment in a hundred fails: retry, skip, or stop. Then tell the user which, once, rather than reporting each one.
Do
Fail towards not charging. A user who got something free will forgive you; one charged twice will not.
What does not apply
| Pattern | Why |
|---|---|
| Minimum charge amounts | A one-satoshi payment is valid and economic |
| Batching to save fees | The fee is already less than 1p |
| Credit top-ups and in-app balances | The wallet is the balance; a float is a custody problem you created |
| Payment channels | Each payment is already an ordinary transaction at a fraction of a penny |
Open questions
- Does showing a running total reassure people, or make them use the product less? Either could be true, and the answer decides where the total belongs.
- What is a sensible first allowance, in amount and in period, and should the app propose it or the wallet?
- At what point does grouping payments hide something a person would have wanted to see one row at a time?
- When one payment in a hundred fails, do people expect a retry, a skip, or a stop?
- Is satoshis-for-software and local-currency-for-people a line people recognise, when the same person is both choosing and letting software decide?
Related
- Pay-per-use reader: this pattern as a whole product
- Permissions and allowances: granting, capping and revoking an allowance
- Amounts and units: which figure leads, and showing very small amounts
- Errors and failed payments: when one payment in a hundred fails
- Activity: grouping many small payments in a wallet
- Letting an agent spend: when software, not a person, does the spending
- Payments: how each payment works underneath
Written from: BRC-29, BRC-100, BRC-121.
Checklist
The rules on this page, in a form you can work through.
15 rules