- Stored balance. The user adds money to an account with you and spends it later.
- Per-payout funding. The user pays for each payout at the moment they send it.
This is a decision about how your users pay you. It is separate from how you fund Bitnob, which is covered in How payouts settle. You can run a stored balance for your users while funding Bitnob on the fly, or the reverse.
The stored balance model
The user adds money to a balance you hold. When they send a payout, you deduct from that balance immediately.- The user deposits 0.5 BTC into their account with you.
- Later, the user requests a payout of $100 to a Nigerian bank account.
- You deduct from the stored balance.
- The payout starts at once.
- Payouts start immediately, because you do not wait for funding to confirm.
- Users do not pay at the moment of sending, which removes friction from the flow.
- You control the float, so you can batch payouts and plan liquidity.
- Users can schedule payouts, because the money is already there.
- You hold other people’s money, so you must secure it and account for it exactly.
- Holding balances triggers licensing and reporting duties in many countries.
- You must reconcile balances continuously and prevent a balance from being spent twice.
- Weak balance tracking creates an opening for fraud.
The per-payout funding model
The user funds each payout separately. You hold no balance between transactions.- The user requests a $100 payout to Kenya.
- You return a funding address and an amount.
- The user pays in bitcoin or USDT.
- When the payment confirms, the payout starts.
- You do not hold user funds, except briefly while the payout runs.
- Your licensing burden is usually lighter.
- You do not reconcile balances or manage float.
- You can launch in a new market sooner.
- The user funds every payout, which adds a step and adds time.
- The price can move between your quote and the confirmed funding.
- If the user pays late or pays too little, the payout fails or needs adjustment.
- Blockchain confirmations delay the start of every payout.
Choosing between them
Answer each question about your own product. Most answers will point the same way.Running both
Some platforms use both models at once. Frequent users hold a balance and get instant payouts. New or occasional users fund each payout. This serves both groups well, but you now operate two funding paths, two reconciliation processes, and two failure modes. Choose it deliberately, not by accident.Two worked cases
A business platform paying merchant clients. Merchants deposit float each week, and payouts run instantly when their customers request money. A stored balance fits, because the volume is predictable and the merchants expect speed. A consumer app sending small cross-border payments. Each payout is funded over Lightning or with stablecoins. Per-payout funding fits, because the volume per user is low and the company avoids holding customer money.Checklist for product managers
- Ask whether your users expect instant payouts, or accept paying per payout.
- Confirm whether you may legally hold customer funds in each market you serve.
- Model the liquidity work: float forecasting for stored balances, confirmation windows for per-payout funding.
- Confirm your team can carry the security, monitoring, and reconciliation load a stored balance adds.
- Consider expansion. Per-payout funding is usually simpler to take into a new country.
Summary
Holding user balances gives you speed and control, and makes you responsible for other people’s money. Funding each payout keeps you lighter, and moves friction into the user’s flow. Decide early, because this choice sets the shape of your treasury, your compliance work, and your support team.Next: The payout lifecycle
Quote, funding, processing, and completion, in order.
See it in the API
How the two funding models work on Bitnob.