educational
A timeout is not a failed refund.
Separate the intent, the attempt and the effect. Then reconcile what you actually know.
One intent, several attempts
A customer asks for one refund. That business intent can produce several network attempts, but it should not casually produce several financial effects. Give the intent, each attempt and each independently observed effect separate identities.
In an illustrative failure, a provider commits a refund and its reply disappears. The caller sees a timeout. It does not know whether the provider committed, rejected or never received the request. Treating all three cases as failure discards the uncertainty that matters.
Make uncertainty a state
Record the first attempt as unknown until a qualified receipt or lookup resolves it. Depending on the provider contract, the next permissible action might be a lookup, a delayed reconciliation or an operator escalation. Blindly creating a fresh refund intent is not reconciliation.
Idempotency helps only under the provider's actual operation, key scope and retention semantics. Reusing a key is not a universal exactly-once guarantee, and a successful HTTP response is not a substitute for understanding the effect.
Test both the defect and the control
A useful isolated test makes the provider commit before dropping the reply. Then it observes whether a retry creates another effect. The control case uses the same starting state and fault, holds the uncertain retry and resolves the original intent using a receipt.
The homepage interaction models this sequence. It is a synthetic explanation, not a live provider test or a measured production failure rate. An actual certificate must name its provider boundary, reset method, rule and evidence gaps.
Sources & corrections
Corrections: none recorded.
Related issued certificates: none. Examples are educational.