Why an AI agent can order the same thing twice

You ask an AI assistant to buy one pair of shoes. The shop accepts the order, but the confirmation never reaches the assistant. It tries again. Without a way to recognize that repeat, the shop could create a second order. Here’s how to avoid that mistake.

Reviewed October 5, 2026 · 7 min read

An AI agent is an assistant that can take actions for you, such as placing an order through a supported shopping service. If it sends the same purchase request twice, a shop needs to recognize the repeat. Otherwise, one intended purchase can become two orders, and sometimes two charges.

The usual safeguard is an idempotency key: a unique reference attached to one intended action. The same reference travels with each retry, so the shop can return the original result instead of repeating the purchase. Developers call this idempotency. In plain English, trying the same action again should not create another order.

Why an assistant might try again#

Think of a checkout page that keeps spinning after you press Buy. You do not know whether the order failed or the confirmation got lost. An assistant can face the same uncertainty: the shop may still be working, may have finished, or may never have received the request.

Sending the request again is called a retry. How and when an assistant retries depends on the service. A safe checkout must handle repeats, even when its own systems are fast, because connections can still fail.

Our guide to what a slow page costs you with an AI agent explains delays. What stops agents completing tasks covers the wider checkout journey. Here, the question is what happens when a purchase request arrives more than once.

Protect the order as well as the payment#

A payment service may recognize a repeated charge request. Your shop still needs to protect its own order records, stock updates and confirmation emails. Otherwise, it could collect payment once but create two orders or send two parcels.

Stripe’s documentation shows how one payment provider handles repeats. It saves the first result for a key after processing begins, including errors. Later requests with that key receive the stored result. It also checks that the request details match.

There are limits. Stripe can remove keys once they are at least 24 hours old. Reusing a removed key creates a new request, which could cause another charge depending on the action. It does not mean every retry the next day automatically charges the customer. Requests rejected before processing begins may not have a saved result.

What to ask your checkout team#

If you run a shop, you do not need to write the code yourself. Ask your developer or checkout provider to show you these checks in a test environment, without taking real payments:

1. Send the same purchase request twice. Once the first attempt has finished, the second should identify the original order rather than create another.
2. Send both attempts at almost the same time. The system must recognize a request that is still being processed, not just one that has already finished.
3. Reuse the reference with a different total or different items. The system should reject the mismatch rather than quietly treat it as the same purchase.
4. Retry after the payment provider’s key-storage period has passed. Check how your own checkout records prevent an old purchase from being repeated.
5. Interrupt the connection after payment succeeds but before confirmation arrives. Check that recovery finds the existing payment and order.
6. Inspect the order, payment, stock and delivery records. A clean result in one system does not prove the others are correct.

Ask how long the shop remembers each purchase reference and how it recovers after a crash. Two requests can arrive together, so a simple “look for the key, then create the order” check is not enough. Both could look before either has saved anything. The database must enforce uniqueness within the intended scope, and the system must coordinate order creation with payment and other actions.

For developers: follow your checkout’s rules#

The Agentic Commerce Protocol (ACP) and Universal Commerce Protocol (UCP) describe ways for shopping software and businesses to work together. Both address repeated requests. Our comparison of UCP, ACP and MCP explains how the protocols fit together.

The Agentic Checkout specification includes an Idempotency-Key header, a named field sent with a request. It also lists Request-Id for tracing and describes returning these fields in response headers. Check the requirements for each operation you support.

The UCP checkout specification tells the shopping platform to check the checkout’s current status after a lost completion response, spacing out checks and stopping when the checkout expires. Only if that check still cannot establish whether the original request was processed may it resend the identical request with the same key. A genuinely new completion operation, once the checkout is ready again, needs a fresh key even if its details are unchanged.

Keep the purchase reference separate from the identifiers used to trace attempts in your logs. The idempotency key stays the same for retries of one action. Each attempt also needs to be distinguishable for troubleshooting. Follow the integration’s rules for Request-Id rather than assuming every service uses it identically.

Store the key, its scope, the request details and the result. Define what happens while work is in progress, after a failure and after the key expires. Keep recovery tied to the existing checkout and payment instead of starting a fresh purchase whenever the outcome is uncertain.

The header name does not define every rule#

A familiar header name does not mean every service handles it the same way. The Internet Engineering Task Force proposal for the Idempotency-Key HTTP header is an expired draft, not a published internet standard. Use the checkout specification and payment provider documentation for your implementation.

The draft is still a useful reference. These are its suggested responses, not universal requirements. The numbers are HTTP status codes, short labels software uses to describe a result:

Confirm the response codes and retry rules your integration expects. Do not copy this table into a checkout without checking its documentation.

How to look for duplicate orders#

Start with orders from the same customer, for the same amount, placed close together. Compare their purchase references, items, checkout records and payment records. This gives you cases to investigate, not a reliable count of mistakes.

For a developer, this SQL database query is a starting point. It finds pairs with the same email and total, created less than ten minutes apart. Adapt it to your database and include your customer identifiers, currency and items when investigating. It can miss duplicates, including orders with identical timestamps.

-- Candidate duplicate orders: same customer and total, created close together
SELECT a.id AS first_id,
       b.id AS second_id,
       a.customer_email,
       a.total_cents,
       b.created_at - a.created_at AS gap,
       a.idempotency_key AS first_key,
       b.idempotency_key AS second_key
FROM orders a
JOIN orders b
  ON b.customer_email = a.customer_email
 AND b.total_cents = a.total_cents
 AND b.created_at > a.created_at
 AND b.created_at < a.created_at + INTERVAL '10 minutes'
ORDER BY gap;

Different keys could mean two genuine purchases or a retry that incorrectly received a new key. A missing key means this record alone cannot explain what happened. Check the request logs and payment records before drawing a conclusion.

The takeaway: one purchase, one order#

A lost confirmation should not become another purchase. Give each intended action a stable reference, handle repeats throughout the checkout, and test what happens when requests overlap or connections fail.

Your payment setup affects where those checks belong. Our guide to how AI agents pay explains the main payment paths and who handles each part of the sale.