Skip to main content
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.

​
The same delay, two different outcomes

Compare a data product and a payout product under the same conditions. 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.
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.

Next: Bitcoin and stablecoins

The opportunities and risks each asset brings to a payout product.

See it in the API

The states a real payout moves through, and where it can stop.