Do agentic checkout protocols require idempotency keys?

A request is idempotent when sending it twice does the same thing as sending it once. A retried checkout that is not idempotent can place a second order. Both open agentic checkout protocols require protection against that. OpenAI’s Agentic Commerce Protocol (ACP) has required an idempotency key, a unique label the agent attaches to each request, on every write since its April 17, 2026 release.¹ Google’s Universal Commerce Protocol (UCP) marks the same key required on all seven of its write operations.⁴ The two protocols then disagree on what counts as the same request twice, so a merchant serving both cannot write one duplicate check and call it done.

Salesforce’s Agentforce Commerce has no retry rules of its own. It runs on ACP and UCP, and those two judge a retried request by different tests.

Do agentic checkout protocols require idempotency keys?

Both agentic checkout protocols require an idempotency key, with one caveat on Google’s side. OpenAI’s Agentic Commerce Protocol says clients “MUST include an Idempotency-Key header on every POST request,” covering create, update, complete and cancel.² Google’s Universal Commerce Protocol marks the header required in its machine-readable definition, while its written REST rules say only that state-changing operations “SHOULD support idempotency.”³

A POST request is the kind that changes something on the server, such as creating a checkout session or placing the order. Agents retry constantly. When a request times out, the agent has no way to know whether the merchant received it. With a key attached, the merchant can recognize the second copy and return the first answer, instead of charging the shopper again.

There are two specifications to compare, not three. The Search Engine Journal piece that raised the question names Google’s protocol, OpenAI’s, and Salesforce’s Agentforce Commerce as “three separate protocols,” then says in the same sentence that Salesforce “chose to align with UCP rather than build a competing standard.”¹² Salesforce’s own announcements show it implementing both of the others. So this article compares two specifications and one platform.

What changed in ACP’s April 2026 release?

The Agentic Commerce Protocol made the idempotency key mandatory in its release dated April 17, 2026, and before that it was optional. The release notes say the parameter “Changed from required: false to required: true” on both the checkout and payment APIs, and they give the reason plainly: “Agents retrying failed or timed-out requests had no protocol-level guarantee of safe replay.”¹

The same release wrote out what a merchant’s server must do with the key, in section 6 of the checkout RFC, the protocol’s formal rules document.² For each case, the RFC names an HTTP status code, the three-digit number a server returns to say how a request went.

• A POST with no key is rejected with status 400 and the code idempotency_key_required.
• The same key with an identical body returns the original response, and the server “MUST NOT re-execute side effects (e.g., payment capture, inventory reservation) on replay.”
• The same key with a different body is rejected with status 422, marked as permanent.
• The same key arriving while the first request is still running gets status 409 and a Retry-After header telling the agent how many seconds to wait.
• A server error, any status in the 500s, “MUST NOT be cached against the idempotency key,” so the retry runs as a fresh request.
• Keys are kept for at least 24 hours.

Decide what “identical” means before building any of this, because ACP defines it by meaning. Equivalence is “semantic JSON equality of the request body only,” so two bodies with their fields in a different order count as the same request.² One oddity for anyone reading the source directly: the RFC’s own change log still lists this rewrite as unreleased, while the dated release notes and the released schema both carry it.

Where does the Universal Commerce Protocol disagree with itself on retries?

The Universal Commerce Protocol’s release of August 25, 2026 states the idempotency key two ways. Its OpenAPI definition, the machine-readable file that code generators and validators read, marks the Idempotency-Key header "required": true on all seven write operations across checkout and cart.⁴ Its written REST rules say state-changing operations “SHOULD support idempotency” and describe what the server must do “When provided.”³

A third reading sits in the protocol’s binding for MCP, the Model Context Protocol that lets an AI assistant call tools directly. There, only two operations must carry the key: “The complete_checkout and cancel_checkout operations also require meta["idempotency-key"] for retry safety.”⁵

My read is that the schema reflects the intent and the prose lags it. The schema is also what a validator enforces. A merchant who builds from the prose alone would accept keyless retries and still match the text.

UCP compares a duplicate by bytes, where ACP compares by meaning. UCP’s check takes a fixed-length fingerprint of the exact bytes sent, called a SHA-256 hash. Reordering two fields changes that fingerprint.

Businesses “MUST detect whether the payload of a duplicate-key request matches the payload of the original by comparing the SHA-256 hash of the raw body bytes,” and a mismatch gets status 409.⁶ So a retry whose fields were reordered is a harmless replay under ACP and a rejected conflict under UCP. Neither specification mentions the other.

Beyond that, the same section adds rules ACP does not have. A key must carry at least 128 bits of randomness, storage is “Minimum 24 hours, recommended 48 hours,” and if the key store fails the server must “Fail closed (reject request with 503).”⁶

What happens when a retry arrives before the first request finishes?

The Universal Commerce Protocol does not say what a server should do when a second copy of a request arrives while the first is still running. Across every page and schema in the August 2026 release, a search for “in-flight”, “in flight” and “concurrent” found no rule on duplicates in progress. A search of its idempotency sections found no rule on whether a server error may be stored against a key either. The Agentic Commerce Protocol answers both.²

That gap matters most at the last step, since placing the order is where the payment moves. UCP handles a lost response at that step with a separate rule.

If the agent gets no answer to Complete Checkout, it “SHOULD use Get Checkout with bounded backoff to obtain the current state,” and only if that still cannot tell whether the order went through may it resend “the identical original Complete Checkout request again with the same idempotency key.”⁷ The agent “MUST NOT use a new idempotency key for that retry.”

That rule protects the merchant from a careful agent. A retry that fires before the first request finishes, the case load testing produces, is left to whatever the merchant’s server happens to do. The specification leaves it open.

The following table answers four questions for each of the two specifications and for Salesforce’s platform, citing the section each answer was read from.

Question	Agentic Commerce Protocol, 2026-04-17	Universal Commerce Protocol, v2026-08-25	Salesforce Agentforce Commerce
Must every write carry a key?	Yes, rejected with 400 without one (RFC section 6.1)2	Schema says yes on all seven writes (OpenAPI parameters)4; REST prose says SHOULD (Specific Header Requirements)3; MCP requires it on complete and cancel only (MCP binding)5	No specification of its own found. It implements ACP and UCP1011
Same key, different body?	422, compared by JSON meaning (sections 6.2 and 6.4)2	409, compared by a hash of the raw bytes (Replay Protection)6	Follows the protocol in use
Same key while the first is still running?	409 with a Retry-After wait (section 6.4)2	Not addressed. For a lost order response, check state with Get Checkout first (Complete Checkout)7	Follows the protocol in use
How long is a key kept, and are errors stored?	At least 24 hours; a 500-range error is never stored (sections 6.5 and 6.6)2	At least 24 hours, 48 recommended; reject with 503 if key storage fails; storing errors not addressed (Replay Protection)6	Follows the protocol in use

Does Salesforce Agentforce Commerce add its own retry rules?

Salesforce Agentforce Commerce is a commerce platform that implements OpenAI’s Agentic Commerce Protocol and Google’s Universal Commerce Protocol, and I found no retry rules it publishes for agent checkout. Salesforce announced an Instant Checkout integration “guided by the new Agentic Commerce Protocol” on October 14, 2025.¹⁰ On January 14, 2026, it announced it was “natively integrating UCP into Agentforce Commerce” for Google’s AI surfaces.¹¹

So a merchant on Agentforce Commerce inherits ACP’s rules for one channel and UCP’s for the other, including their different tests for a duplicate. Salesforce does publish an idempotency guide for its payments developer interface. I have not read it.

What happens to a retry after Google’s cart transfer?

Google’s cart transfer moves a shopper from Google to the merchant’s own site to finish buying, and Google’s announcement says nothing about retries. In its September 16, 2026 post, Google says merchants using its UCP integration hub “can also enable capabilities like cart transfer to a merchant site and enhanced checkout flow testing,” rolling out in the U.S. first.⁹

The UCP specification does cover the step where a cart becomes a checkout. “If an incomplete checkout already exists for the given cart_id, the business MUST return the existing checkout session rather than creating a new one.”⁸ So resubmitting that conversion should not open a second checkout. The same page also covers the link that sends a shopper on to the merchant’s site, a field called continue_url. A business “SHOULD provide continue_url for cart handoff.”⁸

My read, unconfirmed by Google: cart transfer is that handoff. After the shopper lands on the merchant’s own checkout, none of the protocol rules in this article govern it. The double-submit protection that site already has, the kind that stops a person clicking Place Order twice, is the only guard left.

What should a merchant build if both protocols apply?

A merchant who serves both agentic checkout protocols should build to the stricter rule on each question. That means requiring the key on every write, storing it with the order in one transaction, and comparing duplicates by each protocol’s own test. It also means deciding the in-flight case, keeping keys for 48 hours, and testing with parallel retries. Where a step cites neither protocol, it is my inference.

1. Reject a keyless POST with status 400 under both protocols, whatever UCP’s prose permits. Both schemas demand the key.¹⁴
2. Store the key, the response and the order in one database transaction. ACP recommends this, warning of “ghost keys (key stored, operation failed) or lost keys (operation succeeded, key not stored).”²
3. Compare bodies by each protocol’s own test. Use JSON meaning and status 422 for ACP traffic, and byte fingerprints and status 409 for UCP traffic. One shared check with one status code breaks one of the two.
4. Decide the in-flight case yourself. ACP says return 409 and a wait time. UCP says nothing, and its 409 already means a mismatched body. My read: hold the second request until the first finishes, then return the stored result, so the order never runs twice.
5. Keep keys for 48 hours, and never store a 500-range error against one. That meets ACP’s 24-hour floor, UCP’s recommendation and ACP’s error rule together. If the key store is down, reject with 503, as UCP requires.⁶
6. Test with the traffic an agent sends. Fire the same Complete Checkout request twice at once with one key, and confirm one order results. The Search Engine Journal piece lists “a timed-out request gets retried against an endpoint that isn’t properly idempotent” among the failures its interviewee expects. The same interviewee had not seen a verified production incident caused by an agent.¹²

UCP has already shipped breaking schema changes between releases, covered in the fourth UCP release breaks the schema you already integrated, which never mentions a cart or a retry. Re-read the replay rules at each release, since the gap on in-flight duplicates is the kind a later version closes.