AI Agent Idempotency: Why the Same Payment Key Can Still Cost Twice

Research edition: 3 November 2026 · DN Retry Boundary Lab v0.1 · Local ordered simulations

The agent sends a payment request. Its connection times out. It retries with the same key and assumes the problem is solved. That assumption may be justified under the endpoint’s contract. It may also cross a boundary the integration never tested: expired retention, a new account scope, a changed operation or a service that only stores responses after completion.

The title describes a conditional risk, not a claim that DN observed a named provider charging twice. This article separates documented API rules from two abstract local models. Its purpose is to make the retry boundary inspectable before real authority depends on it.

It follows DN’s outcome-receipts research. A receipt helps reconstruct what was recorded. A retry policy determines whether another attempt is admitted. Those are different controls, and both matter to the economics of accepted outcomes.

The Signal: “Supports Idempotency” Is an Incomplete Specification

Stripe’s API v1 documentation describes storing the first execution result, including a server-error response. It allows pruning keys once they are at least 24 hours old and describes new processing when a pruned key is reused. Parameter mismatches are rejected. A validation failure or conflict with an executing request does not create a saved result.

Stripe’s API v2 overview documents a different contract: the same API, account or sandbox scope and a 30-day window define replay conditions. Successful work is not repeated, while failed or partially failed work can be retried toward completion with an updated response. The method support also differs from v1.

PayPal’s idempotency guidance says header support and retention depend on the API. It also warns that simultaneous requests using the same identifier can result in the second request failing. A retry can return the operation’s current status rather than an unchanged copy of the original response.

x402’s payment-identifier documentation describes request identifiers, response caching and fingerprint binding. It distinguishes retries within the cache window from processing after expiry. It recommends keeping the identifier at logical-request level rather than generating one per retry. A deployed service’s implementation and configuration still need their own evidence.

DN Alpha Thesis: Preserve the Economic Operation, Not Just the Transport Attempt

An agent can receive one instruction and create several technical attempts. If it invents a new payment key for each attempt, a per-key service may see several new requests even though the user intended one economic operation.

DN’s Retry Boundary Contract is a review framework for the link between that intent and the execution layer. It asks six questions:

1. Identity: which principal and account scope own the operation?
2. Logical operation: which stable identifier represents the authorized purchase, payment or other commitment?
3. Binding: which destination, amount, asset, route and other material parameters are fixed?
4. Admission: what prevents another worker from starting the same operation while it is already in flight?
5. Retention: what evidence remains when a response cache expires or a process restarts?
6. Uncertainty: what happens if the side effect occurred but its final result cannot be confirmed?

The framework does not assign a security score. A missing answer identifies work for the integration review. A completed questionnaire remains documentation until the relevant behavior is tested.

The Amazon Builders’ Library discussion of idempotent APIs explains why caller-provided request identity matters: identical parameters can represent a retry or a genuinely intended second operation. It also emphasizes the atomicity problem between recording a token and performing mutations. Extending that reasoning to agents means preserving a stable operation identity across orchestration changes, not asking the model to infer intent from similar payloads.

What a Completed-Response Cache Can Miss

Imagine a deliberately simplified service. It checks for a completed result. If no result is present, it admits an action. It writes the cache only when the action’s completion is recorded.

Now order the events this way: first request arrives, second request arrives, first request completes, second request completes. Both arrivals can encounter an empty completed-response cache. A lookup that works perfectly for a later serial retry has not, by itself, reserved the operation during that earlier interval.

This is a constructed schedule, not evidence that a particular payment provider uses that design. The point is to distinguish remembering completed work from controlling admission before an effect.

The alternative in DN’s lab assumes a retained logical-operation ledger. It reserves a scoped operation before admitting an abstract effect. Later arrivals replay a completed result or block an operation whose result is still pending or uncertain. The reservation, durability and stable identifiers are assumptions of this model. DN has not demonstrated those properties in a database or distributed payment system.

Explore the DN Retry Boundary Lab

Choose a fixed event sequence and a design model. Each admitted arrival represents one abstract action committed before its completion record. The trace shows the precise order used. No wallet, API key, live request or payment is involved.

Scenarios and assumptions JSONExecuted results JSONResults CSVStandalone modelMethodology

Counts describe these two local models only. They are not failure rates, financial losses or provider scores. The expiry event deletes response-cache entries while the ledger’s operation records and key bindings remain retained by assumption.

Four Results Worth Understanding

1. Overlapping arrivals expose an admission boundary

In the overlap schedule, the cache model admits two effects for the same scoped operation. The ledger model admits one and blocks the other arrival while the operation is in flight. This demonstrates the difference in the programmed models. It does not establish the behavior of real concurrent workers or storage transactions.

2. A lost completion creates uncertainty, not permission

The lost-completion schedule assumes that an effect happened but no completed response was stored. The cache model admits another effect. The ledger model keeps an uncertain operation and blocks another admission. Its final outcome remains unresolved.

That block has an availability cost: the workflow cannot simply announce success and continue. Someone or something must reconcile authoritative state. Blocking another payment is useful containment; it is not recovery, refund or proof of delivery.

3. A regenerated key can outrun per-key memory

The regenerated-key schedule keeps the principal and logical operation unchanged but supplies a new payment key. The cache model sees a new entry and admits another effect. The ledger model recognizes its retained logical operation and replays the known result.

The practical question for an agent framework is therefore larger than “does the HTTP client support idempotency?” Ask where the logical identifier is created, which workers share it, how it survives handoffs and who can authorize a genuinely new operation.

4. Two effects are sometimes the correct result

The two-principal control produces two effects under both models. They belong to different scoped operations, so duplicate effects remain zero. Treating every repeated key string or similar payload as a duplicate can suppress legitimate activity or mix unrelated customers’ records.

Both models also reject the completed-record fingerprint conflict in the changed-destination schedule. A useful evaluation includes controls that should pass and requests that should be rejected. Counting only fewer effects would reward systems that block everything.

The Production Boundary: An Application Ledger Cannot Magically Transact With Every Provider

A real integration may reserve local work, call an external service and then fail before saving the external result. Those steps do not become one atomic transaction because an application has an operation table.

Production review must cover the actual database, provider retry contract, reconciliation endpoint, worker lifecycle and recovery procedure. Test the interval between the external effect and the local completion write. Decide how to handle an unavailable ledger, a network partition, a revoked authorization and a delayed confirmation. This lab does not implement those mechanisms.

Keep authorization distinct from deduplication. A request can be unique and unauthorized. It can also be an authorized duplicate that must not create a second effect. Neither a stable key nor a ledger entry proves the user’s original intent.

For workflows involving funds, an uncertain original outcome should be escalated through the agreed reconciliation process before a new economic action is approved. Connect the resulting evidence to the outcome receipt, rather than treating an HTTP error as the final accounting state.

What to Request in an Agent Payment Pilot

Ask for a test record showing the exact endpoint, API namespace and version, principal scope, logical-operation identifier, native payment identifier, material request parameters, retry schedule and authoritative outcome. Keep secrets and personal data out of public artifacts.

Include a serial retry, overlapping arrivals, a lost response, a retained-key expiry case and a changed-payload case. Add a control representing a genuinely new authorized operation. Record both unintended extra effects and legitimate operations wrongly suppressed.

Then repeat the relevant cases across worker restart and the actual persistence boundary. A local demonstration and a provider document are useful inputs; neither substitutes for that integration test. Keep the evidence tied to the configuration that produced it.

Methodology, Limits and Reproduction

Evidence types: provider sections summarize official documentation reviewed on 3 November 2026. DN’s Retry Boundary Contract is an editorial review framework. The result table reports execution of two deliberately simplified local models under eight fixed event orders.

Execution: 16 case/design combinations matched their declared expected counts. There were no provider calls, paid requests, model calls, signature checks or real payments. Event order is supplied by the fixture, not measured from a running concurrent service. No latency or statistical reliability result is reported.

Critical assumptions: principals and authorizations are synthetic and assumed valid. Both designs scope keys by principal and compare material fingerprints. The ledger design assumes atomic admission and durable logical-operation state. Response-cache expiry does not erase those ledger records. Storage loss, actual process death and distributed consistency are outside the model.

Reproduce: download model.mjs, results.json and reproduce.mjs into one folder. Run node reproduce.mjs to recheck the declared expectations without dependencies or network calls. The results record the model source’s SHA-256, which identifies bytes rather than providing a trusted timestamp or signature.

Falsification: submit an event trace where the published implementation differs from a stated model rule or where the same scoped operation is counted incorrectly. Independent production evidence may support a different conclusion about an integration. Do not translate the local ledger result into a universal exactly-once guarantee.

Commercial disclosure: the Research Desk is DN’s own paid service. No provider is ranked, endorsed or assigned a security score here. The public model is explanatory research and is not a drop-in payment gate.

Reuse and corrections: DN’s model and synthetic data are available under CC BY 4.0. Attribute Decentralised News and retain the assumptions. Third-party documentation keeps its own terms. Send corrections with a scenario identifier and reproducible evidence; material changes should receive a new version.

Primary Sources

1. Stripe API v1 idempotent requests.
2. Stripe API v2 idempotency overview.
3. PayPal idempotency reference.
4. x402 payment-identifier extension.
5. Amazon Builders’ Library: Making retries safe with idempotent APIs.
6. DN executed local results and full model assumptions.

Frequently Asked Questions

What does idempotency mean for an AI-agent payment?

Within the relevant API contract, retrying the same logical request should not create additional unintended side effects. The key, endpoint, account scope, parameters, time window and implementation all matter.

Can the same idempotency key be processed as a new request later?

Yes, where the applicable contract allows that after retention ends. Stripe’s API v1 documentation describes new processing after an original key is pruned. Check the exact endpoint and version rather than assuming a permanent guarantee.

Are Stripe API v1 and v2 idempotency rules identical?

No. The documented namespaces differ in replay behavior, supported methods and time scope. The article separates the v1 and v2 rules; it does not measure either implementation.

Does DN show that a named provider charged twice?

No. The published results come from two abstract local models and eight fixed event schedules. No provider calls or payments were made, and the lab is not an implementation of Stripe, PayPal or x402.

Why can a cache-only model admit two overlapping effects?

In this model, it writes a response record only after completion. Two arrivals before that write both see no completed record. The alternative model assumes an atomic logical-operation reservation before admitting an effect.

Does an operation ledger guarantee exactly-once payment?

No. The lab assumes durable state and atomic admission. Real storage loss, network partitions, external settlement and failures between systems are outside the model. An uncertain prior effect requires reconciliation.

Should an agent create a new key after a timeout?

Do not treat a timeout alone as permission for a new economic action. Preserve the logical operation identity, follow the API’s documented retry contract and reconcile the original outcome before authorizing a genuinely new attempt.

Are two effects always a duplicate-payment failure?

No. The two-principal control produces two effects for two distinct scoped operations with zero duplicates. The lab counts additional effects for the same principal and logical operation as duplicates.

What can the browser lab access?

It runs fixed synthetic schedules locally. It asks for no wallet, API key or transaction payload and makes no provider calls. Its model output does not establish the safety of your production integration.

How can I reproduce the results?

Download model.mjs, results.json and reproduce.mjs into one folder, then run node reproduce.mjs. The sixteen declared expectations can be checked without dependencies or network calls. Retain the model assumptions when citing results.

Evidence cut-off: 3 November 2026. DN Retry Boundary Lab v0.1. Documentation contracts and local model results are different evidence types.