Payout Status

Overview

What it means

Payout status tells an operator where a money-transfer instruction stands between approval and completion or failure. It should describe an auditable lifecycle rather than a single vague “sent” label.

How it works

A payout may move through created, approved, queued, signing, broadcast, confirming, completed, failed or reversed states depending on the provider and rail. The service records a stable payout ID, destination, asset, network, attempts, transaction references and authoritative timestamps. External confirmation and beneficiary credit can be separate milestones.

Understanding the technical details

Make status names operationally actionable. “Queued” should tell the operator the payout is waiting for a local process; “broadcast” should link to the chain reference; “completed” should specify the finality condition applied. Keep each payout’s unique ID across retries and replacements. If a transaction fails on chain, show the actual network fee loss separately from the beneficiary amount. Support teams should not infer payout completion from an HTTP acknowledgment alone. A status API can be eventually consistent. When a payout confirmation appears on-chain before the provider updates its internal status, keep both observations with timestamps rather than forcing one to overwrite the other.

Common failures and limitations

API timeouts do not prove that a payout failed. Retrying without checking the original payout ID can duplicate funds. Out-of-order webhooks and manual reversals require guarded state transitions and reconciliation.

Related concepts

Crypto Settlement, Crypto Payout, Settlement Reconciliation.

Further reading

BIS — Committee on Payment and Market Infrastructures.