Store-and-forward is a controlled recovery lane

What the public implementation shows

SIPS Connect contains a dedicated SAFWorker registered through scheduled-service extensions, separating recovery work from synchronous payment handlers and giving it its own configuration and execution lifecycle.

The worker consumes durable transaction state after the original request path has ended, so recovery does not depend on a caller holding a connection open. This is the implementation fact behind the note; the architectural reading begins from that visible boundary rather than from an assumed production story.

Operating principleRecovery automation is safe only when eligibility, pacing, and terminal outcomes are explicit.

The decision behind the mechanism

A named worker creates one operational place to define which states are recoverable, how often work runs, and how retry results are persisted.

Retrying inside the request path can amplify outages; replaying every failed payment later can repeat terminal business rejections or duplicate external effects. 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.

• Select only explicitly recoverable transaction states.
• Prevent concurrent workers from claiming the same item.
• Bound attempts and separate terminal failure.
• Expose backlog age, volume, and retry outcomes.

How the control should be operated

Operate the lane with bounded batches, claim ownership, attempt counters, backoff, terminal classification, and queue-depth and oldest-item measures.

Transient failure can be recovered predictably while duplicate and permanently rejected transactions remain contained. 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.