01 / Understand the scope
Does idempotency work across payment providers?
An idempotency key protects a request within the system and scope that recognize it. Sending the same key to another provider does not, by itself, connect their payment state. A separate path needs a shared, enforced control over the same payment obligation.
Do both routes consume the same permission to pay?
Follow the evidenceOne invoice. Two independent requests.
Suppose your team authorizes one USD 10,000 supplier payment. Provider A accepts a request, but the response never arrives. An operator proposes paying the same invoice through Provider B.
Request submitted
UNKNOWNThe original may still pay.
Another provider
NEW REQUESTIts own key does not resolve A.
Fictional scenario. Independent endpoints are assumed; no shared reservation has been established.
Both providers could correctly prevent repeated execution of their own request while the combined workflow still pays twice. This is a consequence of the assumed independent paths, not a claim that either provider violates its contract.
The question is whether every executable path checks and consumes the same remaining authority before release.
What does each control cover?
| Control | What it can establish | What to verify |
|---|---|---|
| Provider idempotency | Repeated calls represent one operation within the provider's documented scope. | Account, endpoint, parameters, retention window and retry rules. |
| A shared invoice ID | Records can refer to the same business payment. | Does the ID actually gate release, or only label records? |
| A common reservation | Paths can share one limit if each path enforces the reservation. | Concurrency, unresolved attempts, recovery and manual bypasses. |
| Reconciliation | Matched outcome evidence can support a subsequent decision. | Can another path release before that evidence is available? |
Provider contracts differ. Stripe documents reuse of the first result for a key and checks for changed parameters. Adyen documents company-account scope and a limit on deduplication across regional endpoints. These are reasons to inspect the exact contract for each route.1, 2
Four questions for your workflow.
- Identity. Which records identify the same underlying obligation across providers and operators?
- Reach. Which API, portal, file-upload or rescue path can independently move the money?
- Enforcement. Must every such path consult the same reservation before it releases?
- Recovery. What evidence establishes that an earlier attempt cannot produce a later effect?
A complete existing control may already be sufficient. A gap may call for an internal fix, a restricted path or a scoped assessment. The finding depends on the paths and conditions actually tested.
Inspect the basis
Put this question to the evidence.
- R02 · Original unresolved
A second route must account for the original's remaining ability to pay.
- Inspect R02
Inspect all four reference models, including the FAIL and INCONCLUSIVE findings.
Recorded synthetic examples. These findings do not establish the behavior of your workflow.
Sources and limits
- Stripe: Idempotent requests. Provider-defined request behavior.
- Adyen: API idempotency. Key scope and regional limitations.
Provider documentation reviewed September 27, 2026. Confirm the current contract for your exact API and integration. The cross-path analysis is HALTSEAL's reasoning about independently executable paths; it is not a provider integration test or endorsement.