CoreBank callbacks need bounded time

What the public implementation shows

SIPS Connect isolates callback delivery in a CallbackClient and CallbackOrchestrator with dedicated tests for timeout and response behavior.

The orchestrator connects stored payment state to the participant CoreBank without embedding HTTP timing inside each payment handler. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleA callback is part of the workflow, but it must not become an unbounded lock on the workflow.

The decision behind the mechanism

A bounded callback budget lets transaction processing record what happened and hand unresolved delivery to a recovery path.

An unbounded callback can exhaust worker capacity, while an immediate retry loop can amplify a participant outage. The mechanism matters because it gives that failure a named boundary, durable evidence, and a controlled response instead of leaving the outcome to timing or operator guesswork.

• Set an explicit per-attempt timeout.
• Persist the business outcome before recoverable delivery work.
• Separate transient network failure from callback rejection.
• Bound retries and expose the unresolved delivery queue.

How the control should be operated

Callback attempts should carry correlation, elapsed time, target classification, response class, and the state that will drive later recovery.

The participant boundary becomes observable without allowing its latency to redefine switch-facing correctness. The reusable lesson is not to copy a class or endpoint in isolation, but to preserve the relationship between identity, state, authority, evidence, and operational ownership.