> ## Documentation Index
> Fetch the complete documentation index at: https://www.bitnob.dev/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Bitnob API requests authenticate with an `X-Auth-Client` API key header against https://api.bitnob.com.
> Always use the sandbox environment for testing. Never put live API keys in sample code.
> Money amounts are integers in the smallest unit of the currency (satoshis for BTC, cents for fiat). Never use floats.
> Every state-changing request takes a client-supplied `reference` and must be treated as idempotent on retry.
> Quotes expire. Re-quote rather than reusing a stale quote id.

# Module 3: Stored balances or per-payout funding

> Whether your users hold a balance with you or fund each payout separately. The decision sets your treasury, compliance, and support load.

Your users must pay you before you can pay someone on their behalf. There are two ways to arrange that, and the choice shapes every system you build afterwards.

* **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 module compares the two and gives you a way to choose.

> [!NOTE]
>
> 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](https://www.bitnob.dev/docs/payouts/settlement-models.md). 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.

1. The user deposits 0.5 BTC into their account with you.
2. Later, the user requests a payout of \$100 to a Nigerian bank account.
3. You deduct from the stored balance.
4. The payout starts at once.

**What you gain**

* 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.

**What it costs you**

* 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.

1. The user requests a \$100 payout to Kenya.
2. You return a funding address and an amount.
3. The user pays in bitcoin or USDT.
4. When the payment confirms, the payout starts.

**What you gain**

* 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.

**What it costs you**

* 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.

| Question | Stored balance | Per-payout |
| - | - | - |
| Do users expect a payout to start instantly? | Yes | No |
| Can you legally hold customer funds where you operate? | Yes | No |
| Do you want to batch payouts and manage float? | Yes | No |
| Do you need to onboard users quickly, with lighter checks? | No | Yes |
| Can your team secure and reconcile balances at scale? | Yes | No |
| Do you want to avoid treasury complexity? | No | Yes |

## 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.

> [card] [Next: The payout lifecycle](https://www.bitnob.dev/learn/courses/payouts-for-product-managers/module-4.md)
>
> Quote, funding, processing, and completion, in order.

> [card] [See it in the API](https://www.bitnob.dev/docs/payouts/settlement-models.md)
>
> How the two funding models work on Bitnob.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.