Payout Retry

Overview

Context and purpose

It must use preserved evidence to decide whether to repeat safely, choose another route, obtain new authorization, or stop because external execution may already have occurred. The workflow should retain the beneficiary, source balance, destination, asset or currency, network or rail, gross amount, fees, approvals, external reference, and final delivery status. Payout Retry should remain distinct from Payout and Payment Retry , because each can represent a different stage, record, control, or financial outcome. The most consequential risks are lost events, duplicate financial effects, out-of-order updates, replay storms, stale consumers, non-atomic writes, unsafe failover, incorrect backfills, silently dropped work, and recovery that creates a second failure. Important failure modes include wrong destinations, duplicate execution, insufficient funding, bypassed approvals, unsupported routes, fee surprises, delayed returns, and submission being mistaken for receipt. Controls should validate the beneficiary and destination, reserve funds consistently, apply approval limits, make retries idempotent, and query authoritative status before another transfer is created.

How it works

A payout retry is a repeated attempt to obtain or complete the result of an outgoing transfer. An unsafe retry can accidentally initiate a second, irrevocable payment if the first attempt already succeeded.

Practical checks and failure points

Record destination, amount, client idempotency key, provider payout ID and on-chain hash. Escalate ambiguous outcomes rather than issuing a fresh instruction.

Related concepts

Duplicate Payout · Idempotency