A connection timeout does not tell a business whether the provider created an object. Before approving a retry button, agree how the same business operation keeps its identity. This concerns outbound creation requests, separately from receiving duplicate webhooks.
Primary evidence and claim boundaries
Stripe API v1 can replay the saved response for the same idempotency key, including a 500; changed parameters are checked, and pruned keys can lead to a new request. Primary reference · Read 17 October 2026.
Filled acceptance example
Synthetic teaching scenario, not a client case, provider integration test or business result. Scroll the example table on narrow screens.
| Register entry | Observed condition | Decision |
|---|---|---|
| Order O41 / attempt K41 / AUD 120 | Timeout after send; result unknown | Retrieve/reconcile; retry same operation with K41 |
| K41 / original AUD 120 | User now requests AUD 150 | Parameter change; do not reuse as the same request |
| K42 / saved 500 | Second request returns 500 again | Escalate/reconcile; a new key is not a safe fix |
| K43 / historical attempt | Beyond provider retention; state unresolved | Manual reconciliation before creating anything new |
Practical handover procedure
- Allocate an opaque operation ID before sending and store its payload fingerprint, provider object ID when known, response and timestamps. Do not put customer email or card data in the key.
- Simulate a lost response after successful creation. The acceptance output must contain one business object after reconciliation, not two objects with different keys.
- Separate network retry, validation correction and a genuinely new order into different states. Define bounded retries and a human resolution path for unknown outcomes.
Interpret the outcome
The register makes an uncertain request resumable without treating uncertainty as failure. A same-key replay is not proof that downstream fulfilment happened, and an endpoint response is not a bank settlement. A useful supplier handover can trace O41 to its request identity and final provider object without exposing credentials.
Acceptance decision
Require a loss-of-response exercise, a changed-payload exercise and a retained 500 exercise against the documented API version. Record final object count and unresolved outcomes.
Limits and unverified work
Synthetic register, no Stripe request sent. This is specifically API v1 behaviour; API v2 differs. Keys do not provide permanent business deduplication or replace database constraints and reconciliation.
Download the filled bilingual acceptance record — Contains these inputs, steps, expectations and limits. This is a teaching record, not an executable integration.