Participant availability is a payment capability

What the public implementation shows

SIPS Connect includes a LiveParticipantsService, participant status models, APIs, and implementation guides for exposing participant availability.

The availability surface gives channels and operators a participant-level signal separate from the health of the local gateway process. 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 reachable switch is not enough when the destination participant is unavailable.

The decision behind the mechanism

Participant readiness is modeled as operational data that can inform routing, user messaging, and incident response.

If all unavailability appears as a generic payment timeout, channels retry blindly and operations cannot distinguish local, switch, and destination failure. 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.

• Separate process health from participant readiness.
• Timestamp and expire stale availability observations.
• Use a stable participant identity across APIs.
• Expose uncertainty rather than defaulting stale state to available.

How the control should be operated

The signal should include observation time, source, participant identity, state, and freshness so consumers understand what it can and cannot prove.

Payment initiation becomes availability-aware without pretending monitoring is a settlement guarantee. 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.