When a timeout becomes a state

Failure and uncertainty are different

A transport timeout tells us that one component stopped waiting. The switch may have accepted the instruction. The receiving participant may have posted it. A callback may be delayed while the financial event is already real.

Mapping every timeout to failed creates a dangerous fiction. It can invite a fresh payment attempt while the original transaction remains live. The safer model makes uncertainty explicit and gives operations a path to resolve it.

Operating principleNever convert missing evidence into a negative financial fact.

Persist the question

The gateway should retain the original identifiers, raw messages, last known status, attempt history, and the reason certainty was lost. A recovery worker can then issue status inquiries without manufacturing a second business instruction.

Store-and-forward belongs to the same design. When a dependency is unavailable, durable work survives the process and resumes under a bounded retry policy. The system recovers from a persisted intention rather than an operator's memory.

• Use an explicit indeterminate or recovery-pending state.
• Retry inquiries and delivery, not the original debit instruction.
• Keep retry budgets, intervals, and terminal escalation visible.
• Preserve correlation across gateway, switch, and CoreBank records.

Operations is part of correctness

Recovery is incomplete if only the code can see it. Health checks, metrics, query APIs, and dashboards make uncertain transactions an operating queue with ownership and evidence.

The result is a more honest payment system: it can say what it knows, what it does not yet know, and what controlled action will close the gap.