Pricing
Setting prices for a BSV product: price in local currency and settle in satoshis, show the price before the action, round honestly, change prices without surprises, and refund with a new payment.
Set the price in the currency your users think in, settle it in satoshis at the moment of payment, and show it before they act. Skip any of those three steps and the price will surprise somebody.
Price in local currency, settle in satoshis
People think in their local currency, and the guide's advice on amounts and units is to lead with that figure for anything a person chooses to buy. Your price list should do the same, with satoshis beside it: "Read for about 1p (20 sats)", "£12.00 (24,000 sats)". The satoshi amount is worked out from the current rate when the user pays, and the payment itself is in satoshis.
Figures that software decides or enforces lead with satoshis instead, with local currency beside them: an allowance limit, what is left of it, an agent's budget.
The same goes for a price software pays. An API charging per request is read by a developer, and "5 sats per request" is the figure they budget with. See Price it where they decide.
Do
Decide which currency each price is set in, and write it down. A price set in local currency moves in satoshis as the rate moves; a price set in satoshis moves in local currency. Both are fine, and mixing them by accident is not.
Do
Fix the satoshi amount when you show the price, and hold it until the user pays or leaves the screen. A figure that changes between the quote and the payment reads as a bait and switch.
BSV's price moves, and the guide is plain that it is not where to keep next month's rent. What your business does with the satoshis it receives is a treasury decision outside this guide.
Show the price before the action
A price shown after the click is a receipt. For a product with many small payments, the price belongs on the thing being bought, and the running total belongs wherever the spending happens.
Do
Put the price on the button or link that spends it: "Read for about 1p (20 sats)". The user should never need to open a pricing page to know what one tap costs.
Do
Tell the user what their allowance buys in your units: "500 sats a day is about 25 articles." An allowance in satoshis alone leaves them to do the division.
Rounding
Satoshis are small enough that a price can be exact. The rounding question is about the local-currency figure that leads, and it should never look more precise than the rate behind it.
Do
Round the local-currency figure up, never down, and say it is approximate: "about 1p", "less than 1p". The user should never pay more than the figure suggested.
Do
Round totals, not each item. Twenty articles at "about 1p" each should add up to the true total, not to twenty rounded pennies.
Changing prices
With an allowance in place, a price change alters what the user's budget buys without them doing anything. That makes it more noticeable, not less.
A price set in local currency changes in satoshis as the rate moves, so an allowance buys a little more or less each day without anybody deciding it. Small drift needs no notice; tell users when what their allowance buys changes noticeably.
See the price-change notice in Receipts, refunds and leaving, part of the Pay-per-use reader.
Do
Announce a price rise before it applies, in the product, to people with an active allowance, and say what their allowance now buys.
Don't
Raise a price on users mid-allowance without telling them. They granted the budget against the old price, and spending it faster is a change to what they agreed to.
Free tiers
A free tier answers "is this worth paying for?" before the user has to connect a wallet. On BSV it can end with something better than an upgrade screen: a first paid item that costs a few satoshis.
Do
Make the step from free to paid one small payment, not a plan. "This article is about 1p (20 sats)" converts a reader; "Upgrade to Pro" asks them to commit before they know.
Don't
Ask for a wallet connection to use the free tier. Ask when the user first reaches something that costs money, as the permission advice says for every capability.
The network fee
The network fee on a BSV payment is less than 1p. In a peer-to-peer payment the payer's wallet adds it, and it belongs in the payment's details, not on the review screen. When you pay out, for a refund or a reward, you pay it.
Do
Leave the network fee out of your price list. The payer's wallet adds it; when you pay out, for a refund or a reward, pay it yourself and do not deduct it from the amount.
See Fees.
Refunds
A BSV payment is final once accepted. There is no chargeback and nothing to reverse, so a refund is a new payment from you to the user.
That has two product consequences. You need a way to pay the user back, and you need a refund policy before the first complaint, not during it. Your obligations to refund depend on where you and your users are; that part needs advice for your jurisdiction.
Do
Keep what you need to pay a customer back with each payment you take: their handle, or a way to reach their wallet, and what the payment was for. Keep it in your order records, not your analytics, and delete it when the refund window closes.
Do
Show a refund in the user's activity as a payment from you that names the original purchase: "Refund for 3 articles, 60 sats".
Don't
Promise to "reverse" or "cancel" a payment in support copy. The word teaches users something false about every other payment they make.
Open questions
- How long should a satoshi quote be held before it is recalculated? Too short frustrates, too long exposes the business to rate movement, and nobody has tested where people notice.
- How much rate drift should trigger a notice to users with an allowance?
- Do users read "about 1p" as a promise or as an estimate?
- For a per-use product, does a refund matter as much as a fast "you will not be charged for that" when something fails? See Failures.
Related
Written from: /guide/patterns/amounts-and-units/, /guide/patterns/charging-per-use/, /guide/patterns/connecting-a-wallet/, /guide/how-it-works/payments/, /guide/designing-products/getting-to-know-your-users/.
Checklist
The rules on this page, in a form you can work through.
14 rules