> ## 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 1: Why moving money is different from moving data > Money movement fails differently from data movement. This module explains the difference and what it demands of your product. Most software moves data: messages, images, account updates, videos, and notifications. When data moves incorrectly, you resend it. The cost of a mistake is low. Money behaves differently. When a payout goes to the wrong account, you cannot resend it. The money is gone, and you must recover it from a person who did not expect to receive it. This module explains that difference, and what it demands from the product you build. ## What you will learn * Why a payout failure costs more than a data failure * Which product decisions this changes * How to measure whether your payout product is reliable ## Data movement and money movement The two differ in eight ways. Each row changes a decision you make later in this course. | Property | Data movement | Money movement | | - | - | - | | Error recovery | You resend or edit the record. | The transfer is often final. The funds can be lost. | | Finality | Eventual consistency is acceptable. | Settlement must be final and recorded correctly. | | User trust | Users tolerate small mistakes. | One failed payout can lose a customer permanently. | | Compliance | Requirements are usually light. | KYC, AML, sanctions screening, and reporting apply. | | Latency | Delivery time is flexible. | Each corridor has an expected settlement time. | | Risk | Operational risk only. | Financial, regulatory, and reputational risk. | | Monitoring | An improvement. | A requirement. | | Support | Users accept delays. | Users escalate quickly. | ## The same delay, two different outcomes Compare a data product and a payout product under the same conditions. | Event | In a data product | In a payout product | | - | - | - | | The action is delayed 30 minutes | The user waits. | The user panics, contacts support, and writes a review. | | The action fails | The user retries it. | The money can be in transit, and nobody knows where. | | The destination is wrong | You correct the record. | A stranger received the funds. You must ask for them back. | A failed payout is not only a bad experience. The user gave you money and did not get the result you promised. That is a failure of trust, and users rarely give a second chance. ## What this demands of your product Six rules follow from the table above. Apply each one from the first release. 1. **Make the system reliable before you make it larger.** Scale multiplies failures that already exist. 2. **Design for final transfers.** Do not depend on a retry to correct a mistake. 3. **Treat settlement as a feature.** Users care when the money arrives, not when the API responded. 4. **Monitor every payout.** You must detect a failure before the user reports it. 5. **Manage liquidity as part of the product.** An empty balance stops payouts, whatever the code does. 6. **Tell users the truth about timing.** An honest estimate creates fewer tickets than an optimistic one. > [!NOTE] > > Rule 4 is the one teams add last and need first. If your user tells you that a payout failed, you already lost the trust that the alert was there to protect. ## Exercise: calculate the cost of failure Assume your product sends \$1,000,000 each day across bitcoin and fiat corridors. If 0.5% of that volume fails, \$5,000 fails each day. The direct cost is not the loss. The cost is the support work, the refunds, and the users who leave. Answer these five questions about your own system: 1. Does the system detect a failed payout automatically? 2. Can your team respond in minutes rather than hours? 3. Do users see an accurate delivery estimate before they confirm? 4. Do you hold enough liquidity for tomorrow's volume? 5. Do you measure the success rate and the delivery time of every corridor? If you answered no to any question, the product still moves money. It does not yet control what happens when the money does not arrive. ## Checklist for product managers * Measure trust and reliability, not engagement. * Treat every payout as a transaction that you cannot reverse. * Build for finality first, and retries second. * Track liquidity, settlement success, and delivery time as product metrics. * Own treasury risk, compliance events, and payout delays. They are product problems. ## Summary You can copy data. You cannot copy money. A payout product earns trust one final transfer at a time, and loses it the same way. > [card] [Next: Bitcoin and stablecoins](https://www.bitnob.dev/learn/courses/payouts-for-product-managers/module-2.md) > > The opportunities and risks each asset brings to a payout product. > [card] [See it in the API](https://www.bitnob.dev/docs/payouts/payouts-lifecycle.md) > > The states a real payout moves through, and where it can stop. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.