02 / Decide with the evidence you have
When is a payment retry safe after a timeout?
A timeout alone does not establish that a payment failed. Repeating the same request may be safe under the provider's documented idempotency and retry rules. Releasing a new payment through another path requires resolving the earlier attempt and checking current authority.
Is this the same protected request, or another payment?
Follow the evidenceA missing response leaves a question.
In a fictional workflow, Provider A receives a USD 10,000 supplier payment request. The client times out. A bank-portal payment is proposed for the same invoice.
KNOWN: THE CLIENT DID NOT GET A RESPONSE
Still unknown: whether A paid, failed, or may pay later.
The passage of time does not, by itself, close the original attempt.
Stripe distinguishes network errors from server errors and documents idempotent retries. It also warns that a server error can leave side effects, so changing the idempotency key is not a general recovery fix.1
Match the action to the known state.
| Situation | Next action | Required check |
|---|---|---|
| Repeat the same request within a valid idempotency scope | Follow the provider's documented retry procedure. | Same operation and parameters; valid key scope and retention; applicable error and retry rules. |
| Original unresolved; a separate payment path is proposed | Keep the new payment on hold. Investigate and reconcile. | Could the original still produce the same economic effect? |
| Original paid the obligation in full | Refuse a second full payment against that obligation. | Match the authoritative outcome to this exact obligation and attempt. |
| Original did not pay and cannot pay later | Perform a fresh release review. | Exact payment, current authority, remaining capacity and the governed route. |
| Evidence is missing or conflicting | Keep uncertainty explicit; obtain reliable evidence. | A local “failed” label or an empty search result may not establish finality. |
The HOLD and REFUSE entries describe the proposed replacement under this control model. They do not prohibit a same-request retry that is protected by a verified provider contract. Adyen, for example, documents retrying with the same key after a timeout, subject to its scope and error-handling rules.2
What would make “no effect” final?
- Match the attempt. The record must identify the relevant provider operation and obligation.
- Establish authority. Use the source and status semantics that are authoritative for this route.
- Close later execution. Determine whether a delayed submission, queued retry or old executor could still act.
- Review the replacement. Closure can restore eligibility. It does not approve a changed destination, amount or expired authority.
In HALTSEAL's public model, FINAL_NOT_OCCURRED means the earlier attempt neither produced the effect nor remains able to produce it. A provider's status label is not automatically equivalent to that condition.
Inspect the public control model and its evidence conditions. If the replacement is a manual bank payment, review the AP-to-Treasury handoff and pre-release checks.
Inspect the basis
Put this question to the evidence.
- R02 · When to hold
The original can still take effect. Withholding the separate fallback passes this case.
- R04 · When recovery must work
When the modeled evidence permits recovery, always blocking fails.
Recorded synthetic examples. These findings do not establish the behavior of your workflow.
Sources and limits
- Stripe: Advanced error handling. Network errors, indeterminate server errors and retries.
- Adyen: API idempotency. Same-key retries, scope and transient errors.
Provider documentation reviewed September 27, 2026. The decision table is HALTSEAL's explanatory full-payment model, not a substitute for a route's contract. Partial payments, returns and changed obligations need separately defined accounting and authority. This fictional scenario contains no live provider test.