OpenAI and Stripe (founding maintainers), Technical Steering Committee: OpenAI, Stripe, Meta
Status
Beta The README says beta and the core RFCs say Draft. In ChatGPT, product feeds and discovery are live, external checkout is generally available and the payment sheet is a private beta; the 2025 in-chat Instant Checkout was scaled back in March 2026.
Latest version
2026-04-17 (dated spec folder; no Git tag or release; edited after release),
State as of
Verified (verified under 30 days ago)
Card network
Rail-agnostic
Checkout and orders (primary layer)
Payment credential
Discovery
Post-purchase and disputes
A. TL;DR and key facts
ACP lets an AI agent run checkout against a merchant's own API: it creates and updates a session, gets a payment token scoped to that merchant and amount, and completes the order, while the merchant stays merchant of record.
Why it exists
Shopping inside a chat window needs a way for the AI surface to build a cart, show authoritative prices and taxes, and pay without becoming the store. Card forms and redirects break the conversation, and handing raw card numbers to every merchant's API is unsafe. ACP gives the merchant a small REST contract it hosts itself, lets a payment provider swap the card for a single-use token limited by an allowance, and leaves orders, payments, refunds and chargebacks with the merchant.
What it is not
Not IBM's Agent Communication Protocol, not Virtuals' Agent Commerce Protocol, not ERC-8183 and not the Agent Client Protocol. The PyPI package acp-sdk is IBM's. Source [28, 29, 30, 31, 32, 33]
OpenAI is not the merchant of record. The merchant is, its name appears on the card statement, and it handles refunds and chargebacks. Source [22]
The Shared Payment Token is Stripe's product used with ACP, not the ACP specification. The spec defines a generic Delegate Payment endpoint; spt is only an example credential type. Source [22, 26, 34]
Not the 2025 Instant Checkout any more. OpenAI scaled back in-chat checkout in March 2026; ChatGPT now uses ACP mainly for product feeds and discovery, and merchants use their own checkout. Source [14, 35]
Not a mandate protocol. ACP has no signed proof of user intent like AP2's mandates; the allowance limits what a token can do, not why. Source [8, 13]
Not versioned by releases. Versions are dated spec folders with no GitHub release or tag, and released folders were edited after release. Source [5, 11]
Not bridged to UCP. The two share several status names and a well-known discovery pattern, but no mapping or bridge specification exists. Source [13, 27, 34]
Key facts as of 2026-10-11
Steward
OpenAI and Stripe (founding maintainers); MAINTAINERS.md lists OpenAI, Stripe and Meta Source [1, 2, 3]
Governance
TSC of up to 7 seats appointed by OpenAI and Stripe since 2026-03-10; seats filled: OpenAI, Stripe, Meta (from 2026-04-24); SEPs by simple majority; founders' block-only veto; no foundation Source [4, 5]
License
Apache-2.0; contributions under a CLA (10 corporate signatories as of 2026-06-03) Source [6, 7]
First announced
2025-09-29, with ChatGPT Instant Checkout and Stripe's Shared Payment Token Source [8, 9]
Latest version
2026-04-17, a dated spec folder (no GitHub release or tag); last commit 2026-07-18 Source [5, 10, 11]
Status
Beta (README), Draft (core RFCs); ChatGPT uses it for feeds and discovery since 2026-03-24 Source [1, 12, 13, 14]
Transports
REST over HTTPS, an MCP binding with five tools, merchant-to-agent order webhooks, feed API and files Source [10, 12, 15, 16, 17, 18]
Rails
Card credentials (FPAN or network token) through Delegate Payment; seller-backed handlers for saved cards, gift cards, points and store credit Source [19, 20, 21]
Merchant of record
The merchant, never OpenAI; the merchant charges through its own PSP Source [12, 22]
Stripe SPT (vendor token under Delegate Payment), Visa and Mastercard agent tokens under SPTs, UCP side by side with no bridge Source [13, 22, 26, 27]
How to read this explanation
ELI5 is a short plain-language version. Practitioner is the full text. Spec-deep adds field tables and wire examples. STE shows the Simplified Technical English version instead.
B. Detailed explanation
ELI5 mode: plain-language version only.
Practitioner mode: the full explanation.
Spec-deep mode: the full explanation plus 4 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
Imagine you ask a friend to buy a jacket for you from a shop. Your friend does not own the shop and does not keep your money. The friend asks the shop for the price, the shipping options and the tax, and the shop writes all of it on a little order slip. Your friend shows you the slip, and you say yes.
You do not hand your friend your bank card. Instead, a trusted bank clerk holds your card and gives your friend a one-time voucher. The voucher says: good for this one shop, for this one order, for no more than this amount, until tonight. Your friend gives the voucher to the shop, and the shop cashes it with its own bank.
The shop is still the shop. It sends the jacket, it answers if something goes wrong, and it handles a return. Later it sends your friend short notes: order received, jacket shipped.
That is the Agentic Commerce Protocol (ACP). Your friend is a chat assistant such as ChatGPT, the shop runs its own small ordering service, and the clerk is a payment company such as Stripe. In 2026 the chat assistant mostly uses the same rules to learn what shops sell, and you often finish the purchase on the shop’s own page.
ACP answers one question: how does an AI surface run a purchase against a merchant without becoming the store? The merchant hosts a small REST (representational state transfer) API (application programming interface) for checkout sessions and stays system of record for orders, payments, taxes and compliance.Source [12] The agent creates a session, updates it with an address and a shipping choice, and gets back the merchant’s authoritative lines, totals and messages each time.Source [12, 38] To pay, the agent asks a payment service provider (PSP) to swap the buyer’s card for a that only works for one merchant, one session, one use, a maximum amount and a deadline.Source [19, 20, 39] The agent sends that token on complete, the merchant charges it through its own PSP, and the response must carry an order.Source [12] OpenAI is never the .Source [22] What ACP does not give you: a signed proof of what the user wanted, an agent identity scheme, or a public registry of agents.Source [8, 12, 13, 20] Those live in other layers or in bilateral onboarding.
Problem and design goals
The Agentic Commerce Protocol (ACP) is an open standard from OpenAI and Stripe for running checkout between an AI agent, a buyer and a business.Source [1, 2] It was announced on 2025-09-29 together with in ChatGPT, and Stripe introduced its (SPT) the same day.Source [8, 9] The README lets agents embed commerce without becoming the merchant of record.Source [1]
The design goals follow from that split of roles. The merchant keeps its catalog, prices, tax logic, fraud rules and PSP; the agent only renders what the merchant returns.Source [12] Card data should not reach the merchant’s checkout API, so a separate call turns it into a scoped token.Source [20, 22, 39] The project’s mission document asks for a protocol that stays neutral across agents, PSPs, sellers, transports and payment methods.Source [40]
Two facts frame everything that follows. First, ACP is a specification with no official SDK (software development kit): there are schemas, RFC (request for comments) style documents and examples, and the reference implementations are OpenAI’s and Stripe’s hosted services.Source [41, 42] Second, the product that launched it changed. On 2026-03-24 OpenAI said the first Instant Checkout lacked the flexibility it wanted, let merchants use their own checkout, and extended ACP to product discovery through feeds.Source [14] Read every ACP claim with the question: is this the spec, or what ChatGPT runs today?
Actors and roles
Four roles appear in the spec. The buyer confirms each step in the agent’s interface.Source [8] The agent, which the RFC text calls ChatGPT unless noted, calls the merchant’s endpoints and hosts the receiver for order webhooks.Source [12, 17] The merchant hosts the checkout API, decides whether to accept each order, charges the payment and handles refunds and chargebacks as merchant of record.Source [12, 22] The Delegate Payment server, a PSP or vault, turns a card into a token usable only within its .Source [20, 39]
OpenAI’s documentation reserves direct Delegate Payment integration for PSPs and for PCI DSS (Payment Card Industry Data Security Standard) Level 1 merchants with their own vaults.Source [22] OpenAI calls Stripe’s SPT the first implementation compatible with that delegated payment spec.Source [22] So with Stripe, the token the merchant receives is an SPT, created and governed by Stripe’s rules, not by ACP.Source [22, 26, 34]
Newer documents add supporting roles. Since 2026-01-16 a merchant can name its own (3DS) authentication provider, and adyen joined the provider list.Source [43] The discovery RFC lets a seller platform, for example acp.stripe.com, host the discovery document for many sellers.Source [25] And the reverses the usual direction: the agent hosts it and merchants push product data to it.Source [10, 18]
Core objects
The is the center of the protocol. A 2026-04-17 session requires an id, the negotiated , a status, a currency, line items, fulfillment options, totals, messages and links.Source [34] Amounts are integers in minor currency units, and totals are typed: items base amount, discounts, subtotal, fulfillment, tax, fee, tip, store credit, total and more.Source [12, 34] Fulfillment options come in four types: shipping, digital, pickup and local delivery, the last two from 2026-01-30.Source [44]
The create request needs only line items, a currency and the agent’s capabilities.Source [34] Here the files disagree with each other. Since 2026-01-30 an Item has only id, name and unit_amount, with no quantity field. Yet the RFC and OpenAPI request examples still send items with an id and a quantity, which do not validate against the schema.Source [12, 34, 38, 44] The repository’s own examples file sends line_items with an id only, which matches the schema.Source [45] Earlier versions, 2025-09-29 to 2026-01-16, used items with a required quantity.Source [46] Build from the JSON (JavaScript Object Notation) Schema of the version you claim.
Payment handlers say how the merchant accepts money. Every handler has a reverse-DNS (Domain Name System) name such as dev.acp.tokenized.card, a version, schema URLs, a PSP and two flags: whether the credential must come through Delegate Payment and whether PCI DSS data flows.Source [34, 47] Seller-backed handlers cover a saved card, a gift card, points and store credit, and they keep card data away from the agent.Source [10, 21] The complete request carries payment_data with a handler id and an instrument whose credential holds a type and a token.Source [34] The schema gives spt and wallet_token only as example credential types.Source [34]
Delegate Payment has its own small schema. The request requires the card, an allowance, risk signals and metadata, with an optional billing address.Source [19] The allowance requires a reason, a maximum amount, a currency, a checkout session id, a merchant id and an expiry, and the only reason defined is one_time.Source [19] Only cards are accepted, as a (primary account number) or a .Source [19, 20] The answer is a vault token whose id starts with vt_.Source [19, 39]
Messages carry business problems inside a normal response. An error message has a code such as out_of_stock, payment_declined or requires_3ds, and since 2026-04-17 a resolution that tells the agent whether it can recover or must ask the buyer.Source [10, 34] HTTP-level errors are flat objects with a type, a code, a message and an optional parameter path.Source [12, 34] Completion creates an Order, which needs only an id, the session id and a permalink URL.Source [34]
Field tables. Spec version 2026-04-17, read from spec/2026-04-17/json-schema/ at commit 7fdd78d (the snapshot was edited after release, most recently on 2026-06-15). Names are copied from the schema; descriptions are paraphrased.
CheckoutSession (CheckoutSessionBase), returned by every checkout endpointSpec version 2026-04-17
Illustrative example, spec version 2026-04-17: a create request that validates against the JSON Schema (note line_items with ids only, not the items with a quantity that the RFC examples show).
The main sequence in section C plays the REST checkout of version 2026-04-17 with a tokenized card handler.Source [12, 34, 38, 47]
Optionally, the agent reads /.well-known/acp.json, which needs no authentication and lists the versions, transports and services the seller supports.Source [25, 34] Payment handlers are not in it; they come back per session.Source [10]
The agent sends POST /checkout_sessions with a bearer token, API-Version and an Idempotency-Key; signature, timestamp and request id headers are recommended.Source [12] The merchant answers 201 with the full session, including its payment handlers and the intersection of supported interventions.Source [12, 38, 48, 49]
The agent posts updates (address, shipping choice) to POST /checkout_sessions/{checkout_session_id} and gets the full authoritative state back with 200 each time.Source [12]
When the chosen handler requires it, the agent calls POST /agentic_commerce/delegate_payment with the card and an allowance, and gets a vault token with 201.Source [19, 20, 39] OpenAI sets the maximum amount and the expiry from what the user chose to buy.Source [22]
The agent sends POST /checkout_sessions/{checkout_session_id}/complete with payment_data. The merchant charges through its PSP and must return status completed with an order.Source [12]
Later, the merchant posts order_create and then order_update events to the agent’s webhook, signed with Merchant-Signature.Source [12, 17]
Failures come in two kinds. Business failures arrive as messages in a normal session response, so an out-of-stock line or a declined payment does not change the HTTP status.Source [34] Protocol failures use HTTP errors. Since 2026-04-17 a missing is 400 idempotency_key_required, the same key with a different body is 422 idempotency_conflict, and a key still in flight is 409 idempotency_in_flight.Source [10, 12] Servers keep keys for at least 24 hours, never cache a 5xx against a key, and mark replays with Idempotent-Replayed: true.Source [12] A missing or unsupported version should return the list of supported versions.Source [10]
Two alternative paths matter in practice. If the merchant wants 3DS it sets the status to authentication_required and adds authentication_metadata; completing without an authentication_result then fails with code requires_3ds.Source [12] The agent can run 3DS itself or through the endpoints.Source [23, 24] A buyer who walks away leads to POST .../cancel, which may carry an with a reason code such as shipping_cost; a session already completed or canceled answers 405.Source [12, 34, 38, 50]
Checkout request headers (RFC section 3.1; 2026-04-17)Spec version 2026-04-17
Status codes in the 2026-04-17 spec. Create 201; update, retrieve and cancel 200; retrieve 404 when unknown; cancel 405 on a final session; complete 200 in the OpenAPI file (OpenAI’s checklist says 201); idempotency 400, 409 and 422 as above.
Lifecycle and states
A session moves through a status field. Version 2025-09-29 defined five values: not_ready_for_payment, ready_for_payment, in_progress, completed and canceled.Source [46]authentication_required first appears in the 2025-12-12 schema, and 2026-01-30 added incomplete, requires_escalation, pending_approval, complete_in_progress and expired, for eleven values.Source [44, 46, 51]
Six of those eleven values are missing from the checkout RFC’s status list, which still names only the original five; of the six, only authentication_required gets behavior in the RFC text.Source [12, 34] The state machine in section C therefore marks those transitions as inferred from names, not from spec text. In practice a session sits in not_ready_for_payment until address and fulfillment choices are complete, moves to ready_for_payment, and ends in completed with an order or in canceled.Source [12, 38]
After checkout the order has its own lifecycle. Its defined status values are created, confirmed, manual_review, processing, shipped, completed and canceled, after a post-release edit on 2026-05-01.Source [5, 34] Fulfillments track shipping states from pending to delivered, and for refunds, returns and disputes have the states pending, completed and failed.Source [34]
The delegated token has no status field at all. The allowance says what it may do, but ACP defines no error code for a PSP to return when a token is used outside it.Source [19, 39] Stripe’s SPT, by contrast, has the statuses active, requires_action and deactivated, and it is deactivated when it is consumed, expires or is revoked.Source [26]
Checkout status values by version (CheckoutSession.status):
The voucher is the strong part: it works for one shop, one order, one time, up to one amount, until a deadline. The weak parts are around it. The shop and the assistant trust each other because they swapped a password in advance. Nothing proves that you, the person, really asked for this purchase, apart from the assistant’s own screen where you said yes.
The core guarantee is the allowance. A delegated token is bound to one merchant and one checkout session, capped by a maximum amount in one currency, valid for one use and until an expiry.Source [19] Enforcement is the PSP’s job, not cryptography the merchant can check.Source [19, 20, 39]
Everything else rests on bilateral trust. Agent and merchant authenticate each other with bearer tokens exchanged out of band, and the spec has no agent registry or public key directory.Source [12, 20] Request signatures are detached signatures over canonical JSON with algorithms agreed out of band, and they are recommended, not required, on checkout.Source [12, 39] On Delegate Payment the RFC says the client must sign in one section, while its own header list says recommended and the OpenAPI file marks the header optional.Source [20, 39] Request freshness is only a SHOULD.Source [12] OpenAI adds an operational control: merchants allowlist its published egress IP ranges.Source [22]
Webhooks are better specified. The merchant signs each order event with HMAC-SHA256 (hash-based message authentication code) over the timestamp, a dot and the raw body, and receivers reject failures with 401 inside a recommended 300-second window.Source [17] Markdown in messages must be CommonMark without raw HTML, which closes one injection path into the agent’s interface.Source [10, 12] No CVE (Common Vulnerabilities and Exposures) entry or GitHub advisory exists for the repository, and a 2026 Tamarin model covers ACP among four payment protocols.Source [52, 53] Section H has the threat table and section I the controls.
Versioning and governance
Versions are dates. The client sends one in the required API-Version header, and the released versions are 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30 and 2026-04-17.Source [1, 10, 12] There are no GitHub releases and no Git tags: a version is a dated folder of schemas, OpenAPI files and a changelog, and 2026-04-17 was promoted by a pull request on that day.Source [5, 10, 11] Dated folders are not frozen. The 2026-01-30 checkout schema changed six times in February 2026, and the 2026-04-17 folder changed on 2026-05-01 and 2026-06-15.Source [5] Pin a commit, not only a version string.
Each version changed real fields. 2025-12-12 renamed fulfillment_address to fulfillment_details and replaced fulfillment_option_id with selected_fulfillment_options, based on lessons from URBN (the retail group behind Urban Outfitters) and Etsy adapters.Source [54] 2026-01-30 added capability negotiation and payment handlers, which replaced payment_provider.supported_payment_methods.Source [48] 2026-04-17 added carts, the Feed API, Delegate Authentication, discovery and the (Model Context Protocol) binding.Source [10] Eighteen commits followed until 2026-07-18, and nothing has landed since.Source [5] The package name in package.json is not published on npm.Source [42]
Governance changed on 2026-03-10.Source [4, 5] A Technical Steering Committee (TSC) has up to seven seats, one per organization, and OpenAI and Stripe as founding maintainers appoint and remove its members.Source [4] Meta took seat 3 on 2026-04-24, so the TSC had three members on 2026-10-11.Source [4, 5] Major changes go through Specification Enhancement Proposals (SEPs) with a sponsor, a 7-business-day public review and a simple majority vote.Source [4] The founders keep a veto on SEPs that can only block, never force, and must be explained in writing.Source [4] Contributions need a contributor license agreement (CLA); the corporate signatories are Stripe, OpenAI, Adyen, Wix, commercetools, OpenCommerce Network, Affirm, Meta, Agentic Commerce Inc. (Catalog) and PayPal.Source [7] The list names OpenCommerce Network Inc., not nekuda, although a nekuda GitHub user is among its authorized users.Source [7] There is no foundation yet; the governance document states moving to one as a long-term goal.Source [4]
Extensibility
ACP grows in four ways. Capability negotiation lets the agent declare what it supports and the seller answer with the intersection.Source [48, 49] Payment handlers add payment methods by name without schema changes to the session.Source [34, 47] The framework adds optional features, and so far only one extension uses it: discount, identified by the name discount.Source [34, 55, 56] Affiliate attribution and marketing consent are fields defined by their own RFCs, not framework extensions.Source [34, 57, 58]
Transports are the fourth axis. The MCP binding maps the five checkout operations to the tools create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session and cancel_checkout_session.Source [15, 16] It runs JSON-RPC (JSON remote procedure call) 2.0 over MCP Streamable HTTP with meta, id and payload arguments, moves authorization into MCP server configuration and returns ACP errors under JSON-RPC code -32000.Source [15] Note the drift: the binding keeps the idempotency key optional and an error type that REST removed in 2026-04-17.Source [10, 15]
The Feed API reverses the call direction. Merchants push products to the agent with POST /feeds and PATCH /feeds/{id}/products, or send metadata.json plus products.jsonl files that replace the whole set.Source [10, 18] A Product needs an id and variants, and each Variant needs an id and a title.Source [59] Carts give single-seller estimates with no status and no payment data, and turning a cart into a checkout was deferred.Source [10, 60]
How it composes with the other seven
ACP is a checkout and credential handoff protocol, so it pairs with whatever sits under the token and beside the agent. Stripe’s SPT is the main bridge: Stripe says it might use Mastercard Agent Pay and Visa Intelligent Commerce tokens for SPT card payments, so network agent tokens can sit underneath an ACP purchase.Source [13, 26] The same SPT family pays for cards in Stripe’s MPP (Machine Payments Protocol) integration.Source [22, 61] ACP has no documented relation to x402, ERC-8004 (Ethereum Request for Comments 8004, on-chain agent identity) or Visa TAP (Trusted Agent Protocol), and no AP2 (Agent Payments Protocol) mandates.Source [8, 12, 13, 62] UCP (Universal Commerce Protocol) is the closest sibling, with no bridge between the two.Source [13, 27] The section “Compare and compose” below goes further.
Limitations and open issues
No proof of user intent. The allowance limits what a token can do, not why; nothing in ACP lets a merchant or issuer verify that a user approved this purchase.Source [8, 13]
Bilateral trust. Each agent and merchant pair swaps bearer keys, with no registry and signatures only recommended.Source [12, 20]
Undefined states. Six of eleven checkout statuses are absent from the RFC’s status list.Source [12, 34]
Spec drift. Examples send items with a quantity that the schema rejects, and the checkout RFC still says version 2026-01-16. The OpenAPI file calls the request Signature an HMAC for webhooks. The changelog lists the order status delivered where the schema says completed, and a 2026-01-30 note deprecates a version 2026-01-22 that has no folder.Source [10, 12, 34, 38, 48] The changelog also describes a decimal quantity that only the oldest schema has.Source [10, 34, 46]
Docs versus spec. OpenAI’s documentation uses /product_feeds paths, webhook names order_created and order_updated, 201 on completion, 409 for an idempotency conflict and TLS (Transport Layer Security) 1.2 or later. The spec says /feeds, order_create and order_update, 200, 422 and TLS 1.3.Source [12, 17, 22, 38]
Mutable releases and a quiet repository. Released folders were edited, and no commit landed between 2026-07-18 and 2026-10-11.Source [5]
Concentrated governance. The founders appoint the TSC and hold a veto.Source [4]
No adoption numbers. OpenAI, Stripe and the project publish no transaction volume, GMV (gross merchandise value) or merchant count.Source [1, 8, 14]? unverified
OpenAI documentation versus the ACP spec (2026-10-11). The spec is primary for ACP; OpenAI’s docs are primary for what ChatGPT expects.
Topic
ACP spec 2026-04-17
OpenAI docs
Feed paths
/feeds, /feeds/{id}, /feeds/{id}/products
/product_feeds..., plus a promotions API
Webhook event names
order_create, order_update
order_created, order_updated
Complete status code
200 (OpenAPI)
201 Created
Idempotency conflict
422 idempotency_conflict
409
TLS
1.3 MUST (RFC section 7)
1.2 or later on port 443
What changed in 2025 and 2026
2025-09-29: ACP and Instant Checkout launched; US ChatGPT users could buy from US Etsy sellers, single items only, with over a million Shopify merchants announced as coming soon.Source [8] OpenAI said merchants pay a small fee on completed purchases.Source [8]
2025-10-14 and 2025-10-28: Walmart announced Instant Checkout plans, and PayPal said it will adopt ACP and run an ACP server for its merchants.Source [63, 64]
2025-12-11: Stripe launched its Agentic Commerce Suite.Source [65]
2025-12-12, 2026-01-16 and 2026-01-30: three spec versions brought fulfillment details, authentication providers, capability negotiation and payment handlers.Source [43, 48, 54]
2026-01-08: Microsoft launched Copilot Checkout and said it adopts open standards like ACP.Source [66]
2026-01-21: a trade report said Shopify merchants would pay OpenAI 4 percent on ChatGPT checkout sales (reported, not published by OpenAI).Source [67]
2026-03-10: the TSC governance model; the same month trade press quoted an OpenAI spokesperson saying Instant Checkout was moving to apps (reported).Source [4, 5, 35]
2026-03-24: OpenAI scaled back in-chat checkout and expanded ACP to product discovery with Target, Sephora, Nordstrom, Lowe’s, Best Buy, The Home Depot and Wayfair.Source [14] No primary source gives a shutdown date for the 2025 form, and OpenAI’s developer docs still describe the three flows Instant Checkout needs.Source [22]
2026-04-17 and 2026-04-24: version 2026-04-17, then Meta’s TSC seat.Source [4, 5, 10]
2026-10-11: in ChatGPT apps, external checkout is generally available, and the is a private beta for select marketplace partners with six listed PSPs.Source [37]
C. Diagrams
Main flow: ACP checkout, happy path (REST, delegated card token)
An agent discovers the seller, creates and updates a checkout session, gets a vault token scoped by an allowance, completes the session and receives an order event.
Buyer
Agent (AI surface)
Merchant API
PSP or vault
Merchant PSP
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 13Agent (AI surface) toto Merchant API
GET /.well-known/acp.json
Optional discovery with no authentication. The response lists protocol versions, transports (rest, mcp) and services. Payment handlers are not included.
Generated from the flow definition (spec version 2026-04-17, 2026-04-17). The player above uses the same data.
Text alternative
Sequence diagram: ACP checkout, happy path (REST, delegated card token). 5 participants: Buyer, Agent (AI surface), Merchant API, PSP or vault, and Merchant PSP. 13 steps, 7 crossing a trust boundary, 10 failure branches. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Agent (AI surface) to Merchant API: GET /.well-known/acp.json. This step crosses a trust boundary. If Document missing (404): Agent falls back to an out-of-band configuration; discovery is optional. Step 2: Buyer to Agent (AI surface): Ask to buy an item. Step 3: Agent (AI surface) to Merchant API: POST /checkout_sessions. This step crosses a trust boundary. If Missing Idempotency-Key: 400 idempotency_key_required. If Unsupported API-Version: 400 with supported_versions. If Unknown item: 400 invalid_request with a param path. Step 4: Merchant API to Agent (AI surface): 201 session (not_ready_for_payment). Step 5: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id} (update). This step crosses a trust boundary. If Item out of stock: 200 with a MessageError code out_of_stock; status stays not_ready_for_payment. Step 6: Merchant API to Agent (AI surface): 200 session (ready_for_payment). Step 7: Agent (AI surface) to Buyer: Show total, buyer confirms. Step 8: Agent (AI surface) to PSP or vault: POST /agentic_commerce/delegate_payment. This step crosses a trust boundary. If Card rejected: 400 invalid_card. If Too many requests: 429 rate_limit_exceeded. Step 9: PSP or vault to Agent (AI surface): 201 vault token. Step 10: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id}/complete. This step crosses a trust boundary. If Payment declined: Session returns a MessageError payment_declined. If Session needs 3DS: 4XX requires_3ds; see the 3DS flow. Step 11: Merchant API to Merchant PSP: Charge the token. This step crosses a trust boundary. Step 12: Merchant API to Agent (AI surface): 200 completed + order. Step 13: Merchant API to Agent (AI surface): Webhook order_create. This step crosses a trust boundary. If Bad or stale signature: Agent answers 401.
Step 1: Agent (AI surface) to Merchant API: GET /.well-known/acp.json. This step crosses a trust boundary. If Document missing (404): Agent falls back to an out-of-band configuration; discovery is optional.
Step 2: Buyer to Agent (AI surface): Ask to buy an item.
Step 3: Agent (AI surface) to Merchant API: POST /checkout_sessions. This step crosses a trust boundary. If Missing Idempotency-Key: 400 idempotency_key_required. If Unsupported API-Version: 400 with supported_versions. If Unknown item: 400 invalid_request with a param path.
Step 4: Merchant API to Agent (AI surface): 201 session (not_ready_for_payment).
Step 5: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id} (update). This step crosses a trust boundary. If Item out of stock: 200 with a MessageError code out_of_stock; status stays not_ready_for_payment.
Step 6: Merchant API to Agent (AI surface): 200 session (ready_for_payment).
Step 7: Agent (AI surface) to Buyer: Show total, buyer confirms.
Step 8: Agent (AI surface) to PSP or vault: POST /agentic_commerce/delegate_payment. This step crosses a trust boundary. If Card rejected: 400 invalid_card. If Too many requests: 429 rate_limit_exceeded.
Step 9: PSP or vault to Agent (AI surface): 201 vault token.
Step 10: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id}/complete. This step crosses a trust boundary. If Payment declined: Session returns a MessageError payment_declined. If Session needs 3DS: 4XX requires_3ds; see the 3DS flow.
Step 11: Merchant API to Merchant PSP: Charge the token. This step crosses a trust boundary.
Step 12: Merchant API to Agent (AI surface): 200 completed + order.
Step 13: Merchant API to Agent (AI surface): Webhook order_create. This step crosses a trust boundary. If Bad or stale signature: Agent answers 401.
Source of truth: 3 (external link) Generated from src/content/flows/openai-acp-checkout-happy-path.json.
Lifecycle: ACP checkout session status (2026-04-17, 11 values)
A filled dot marks the initial state; terminal states have a double border; dashed lines go back to an earlier state. Numbers on the lines match the transition list.
Transition
not_ready_for_payment to ready_for_payment
Trigger
Buyer data and fulfillment choice complete
API call
POST /checkout_sessions/{id}
Spec reference
RFC 4.2 (implied)
About ready_for_payment
Original value.
State notes
incomplete
Added 2026-01-30; no RFC definition.
not_ready_for_payment
Original value; usually the status after create.
requires_escalation
Added 2026-01-30; no RFC definition.
authentication_required
From 2025-12-12; RFC requires authentication_metadata.
ready_for_payment
Original value.
pending_approval
Added 2026-01-30; no RFC definition (B2B approval fields exist).
in_progress
Original value; meaning not detailed in the RFC.
complete_in_progress
Added 2026-01-30; no RFC definition.
completed
Must carry an order.
canceled
Cancel again returns 405.
expired
Added 2026-01-30; no RFC definition.
Spec version 2026-04-17.
State diagram: ACP checkout session status (2026-04-17, 11 values)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
Generated from the state machine definition (spec version 2026-04-17).
Text alternative
State diagram: ACP checkout session status (2026-04-17, 11 values). 11 states: incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, in_progress, complete_in_progress, completed, canceled, and expired. Starts in not_ready_for_payment. Ends in completed, canceled, and expired. 16 transitions. From not_ready_for_payment to ready_for_payment when Buyer data and fulfillment choice complete (POST /checkout_sessions/{id}). From incomplete to not_ready_for_payment when Required data added (inferred from name) (POST /checkout_sessions/{id}). From ready_for_payment to not_ready_for_payment when Update invalidates the cart, for example out of stock (POST /checkout_sessions/{id}). From ready_for_payment to authentication_required when Merchant requires 3DS (session response). From authentication_required to completed when Complete with authentication_result (POST /checkout_sessions/{id}/complete). From ready_for_payment to requires_escalation when Merchant needs buyer action outside the agent (inferred from name) (session response). From ready_for_payment to pending_approval when Approval required, for example B2B (inferred from name) (POST /checkout_sessions/{id}/complete). From ready_for_payment to complete_in_progress when Complete accepted, payment still processing (inferred from name) (POST /checkout_sessions/{id}/complete). From complete_in_progress to completed when Payment confirmed, order created (inferred) (GET /checkout_sessions/{id}). From ready_for_payment to in_progress when Processing (meaning not detailed; inferred) (POST /checkout_sessions/{id}/complete). From in_progress to completed when Order created (POST /checkout_sessions/{id}/complete). From ready_for_payment to completed when Complete succeeds; response carries an order (POST /checkout_sessions/{id}/complete). From not_ready_for_payment to canceled when Agent cancels, optional intent_trace (POST /checkout_sessions/{id}/cancel). From ready_for_payment to canceled when Agent cancels, optional intent_trace (POST /checkout_sessions/{id}/cancel). From ready_for_payment to expired when expires_at passes (inferred from name) (none). From not_ready_for_payment to expired when expires_at passes (inferred from name) (none).
From not_ready_for_payment to ready_for_payment when Buyer data and fulfillment choice complete (POST /checkout_sessions/{id}).
From incomplete to not_ready_for_payment when Required data added (inferred from name) (POST /checkout_sessions/{id}).
From ready_for_payment to not_ready_for_payment when Update invalidates the cart, for example out of stock (POST /checkout_sessions/{id}).
From ready_for_payment to authentication_required when Merchant requires 3DS (session response).
From authentication_required to completed when Complete with authentication_result (POST /checkout_sessions/{id}/complete).
From ready_for_payment to requires_escalation when Merchant needs buyer action outside the agent (inferred from name) (session response).
From ready_for_payment to pending_approval when Approval required, for example B2B (inferred from name) (POST /checkout_sessions/{id}/complete).
From ready_for_payment to complete_in_progress when Complete accepted, payment still processing (inferred from name) (POST /checkout_sessions/{id}/complete).
From complete_in_progress to completed when Payment confirmed, order created (inferred) (GET /checkout_sessions/{id}).
From ready_for_payment to in_progress when Processing (meaning not detailed; inferred) (POST /checkout_sessions/{id}/complete).
From in_progress to completed when Order created (POST /checkout_sessions/{id}/complete).
From ready_for_payment to completed when Complete succeeds; response carries an order (POST /checkout_sessions/{id}/complete).
From not_ready_for_payment to canceled when Agent cancels, optional intent_trace (POST /checkout_sessions/{id}/cancel).
From ready_for_payment to canceled when Agent cancels, optional intent_trace (POST /checkout_sessions/{id}/cancel).
From ready_for_payment to expired when expires_at passes (inferred from name) (none).
From not_ready_for_payment to expired when expires_at passes (inferred from name) (none).
Five zones. The agent platform calls the merchant's checkout API with a bilateral bearer key, gets a vault token from a PSP, and receives HMAC-signed order events. The merchant stays merchant of record and charges through its own PSP. Numbers follow the main flow.
Text alternative
Flowchart. The buyer confirms in the agent interface. The agent reads the merchant's /.well-known/acp.json without authentication, then calls the merchant checkout API to create, update and complete a session with a bearer key. The agent sends the card and an allowance to the PSP or vault Delegate Payment endpoint and gets a vault token. The merchant charges the token through its own PSP, which accepts it only inside the allowance. The merchant sends HMAC-signed order events to the agent's webhook receiver and pushes products to the agent's Feed API. The agent can call a 3DS authentication provider for step-up.
The checkout session holds capabilities with payment handlers, line items, totals and, after completion, an order. The complete request's payment_data points to a handler and carries a vault token that the allowance binds to one session and one merchant. Fields are a subset of the 2026-04-17 JSON Schema.
Text alternative
Class diagram. CheckoutSession has id, status, currency, capabilities, line_items, fulfillment_options, totals, messages, links and order. Capabilities has payment, interventions and extensions; payment lists PaymentHandler objects with id, name, version, requires_delegate_payment, requires_pci_compliance, psp and config. LineItem has id, item, quantity and totals; Item has id, name and unit_amount. Total has type, display_text and amount. PaymentData references a handler by handler_id and carries a token from DelegatePaymentResponse (id, created, metadata), which an Allowance (reason, max_amount, currency, checkout_session_id, merchant_id, expires_at) binds to a checkout session. Order has id, checkout_session_id, permalink_url, status and adjustments.
Five dated spec folders, no Git tags or GitHub releases. Two released folders were edited after their release date, so pin a commit as well as a version.
Text alternative
Flowchart of versions in order: 2025-09-29 initial checkout and Delegate Payment with five statuses; 2025-12-12 fulfillment_details, selected_fulfillment_options, authentication_required and affiliate attribution; 2026-01-16 authentication provider and adyen; 2026-01-30 capabilities, payment handlers, extensions, eleven statuses and line_items without quantity; 2026-04-17 cart, Feed API, Delegate Authentication, acp.json discovery, MCP binding and required Idempotency-Key; then unreleased work with 18 commits to 2026-07-18. Notes show 2026-01-30 edited from 2026-02-05 to 2026-02-13 and 2026-04-17 edited on 2026-05-01 and 2026-06-15.
ChatGPT and ACP: the 2025 Instant Checkout model versus the 2026 discovery-first model
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
In 2025 ChatGPT ran the full ACP checkout in chat. On 2026-03-24 OpenAI let merchants use their own checkout and extended ACP to product feeds and discovery. The 'moving to apps' quote is reported only, and no primary source gives a shutdown date.
Text alternative
Two panels. 2025 model: buyer in ChatGPT, ChatGPT runs ACP create, update and complete, a Delegate Payment token such as a Stripe SPT, and the merchant charges as merchant of record. 2026 model: the merchant pushes product feeds through ACP directly or through providers, the buyer discovers in ChatGPT, then checks out on the merchant site (generally available) or, for select partners, through the payment sheet in apps (private beta). An arrow labeled scaled back 2026-03-24 joins the panels.
The six required allowance fields act as checks before a vault token can be charged. The PSP or vault enforces them; ACP defines no error code for a failed check, so declines are PSP specific.
Text alternative
Decision flowchart for a vault token. Check that reason one_time allows this first use, that merchant_id matches, that checkout_session_id matches, that the currency matches and the amount is at most max_amount, and that the time is before expires_at. Any failed check leads to a decline that is PSP specific. All checks passing leads to charge allowed.
ACP Delegate Payment: allowance scoping and enforcement
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The agent turns a card into a vault token bound by an allowance. The PSP, not ACP, enforces the limits; ACP defines no error code for an out-of-allowance charge.
Text alternative
Sequence diagram: ACP Delegate Payment: allowance scoping and enforcement. 4 participants: Agent (AI surface), PSP or vault, Merchant API, and Merchant PSP. 5 steps, 3 crossing a trust boundary, 7 failure branches. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Agent (AI surface) to PSP or vault: POST /agentic_commerce/delegate_payment. This step crosses a trust boundary. If Same key, different body: 422 idempotency_conflict. If Same key still running: 409 idempotency_in_flight. If No key: 400 idempotency_key_required. Step 2: PSP or vault to PSP or vault: Store card, bind allowance. Step 3: PSP or vault to Agent (AI surface): 201 { id: vt_... }. Step 4: Agent (AI surface) to Merchant API: Complete with the token. This step crosses a trust boundary. Step 5: Merchant API to Merchant PSP: Charge up to the allowance. This step crosses a trust boundary. If Amount above max_amount: Declined by the PSP; no ACP error code. If After expires_at: Declined by the PSP; no ACP error code. If Different merchant_id or session: Declined by the PSP; no ACP error code. If Second use of a one_time token: Declined by the PSP; no ACP error code.
Step 1: Agent (AI surface) to PSP or vault: POST /agentic_commerce/delegate_payment. This step crosses a trust boundary. If Same key, different body: 422 idempotency_conflict. If Same key still running: 409 idempotency_in_flight. If No key: 400 idempotency_key_required.
Step 2: PSP or vault to PSP or vault: Store card, bind allowance.
Step 3: PSP or vault to Agent (AI surface): 201 { id: vt_... }.
Step 4: Agent (AI surface) to Merchant API: Complete with the token. This step crosses a trust boundary.
Step 5: Merchant API to Merchant PSP: Charge up to the allowance. This step crosses a trust boundary. If Amount above max_amount: Declined by the PSP; no ACP error code. If After expires_at: Declined by the PSP; no ACP error code. If Different merchant_id or session: Declined by the PSP; no ACP error code. If Second use of a one_time token: Declined by the PSP; no ACP error code.
Source of truth: 2.2 (external link) Generated from src/content/flows/openai-acp-delegate-payment.json.
Play this flow step by step
Agent (AI surface)
PSP or vault
Merchant API
Merchant PSP
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 5Agent (AI surface) toto PSP or vault
POST /agentic_commerce/delegate_payment
Headers: Authorization, API-Version and Idempotency-Key are required. RFC section 2.2 says the client must sign with Signature and Timestamp; the header list and OpenAPI mark them optional.
Spec version 2026-04-17 (2026-04-17). Sources: [19], [20], [39]
Step 1 of 5: Agent (AI surface) to PSP or vault. POST /agentic_commerce/delegate_payment. Crosses a trust boundary.
ACP alternative path: 3-D Secure step-up
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The merchant requires 3DS, sets authentication_required, and rejects a complete call without authentication_result. The agent runs Delegate Authentication and completes again.
Text alternative
Sequence diagram: ACP alternative path: 3-D Secure step-up. 4 participants: Agent (AI surface), Merchant API, Authentication provider, and Buyer. 7 steps, 4 crossing a trust boundary, 2 failure branches. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Merchant API to Agent (AI surface): Session status authentication_required. Step 2: Agent (AI surface) to Merchant API: Complete without authentication_result. This step crosses a trust boundary. Step 3: Merchant API to Agent (AI surface): 4XX requires_3ds. Step 4: Agent (AI surface) to Authentication provider: POST /delegate_authentication. This step crosses a trust boundary. Step 5: Agent (AI surface) to Authentication provider: Fingerprint, then POST .../authenticate. This step crosses a trust boundary. If Challenge required: The buyer completes the issuer challenge. Step 6: Buyer to Authentication provider: Issuer challenge (if any). Step 7: Agent (AI surface) to Merchant API: Complete with authentication_result. This step crosses a trust boundary. If Outcome denied: Merchant declines; session stays open or ends per merchant policy.
Step 1: Merchant API to Agent (AI surface): Session status authentication_required.
Step 2: Agent (AI surface) to Merchant API: Complete without authentication_result. This step crosses a trust boundary.
Step 3: Merchant API to Agent (AI surface): 4XX requires_3ds.
Step 4: Agent (AI surface) to Authentication provider: POST /delegate_authentication. This step crosses a trust boundary.
Step 5: Agent (AI surface) to Authentication provider: Fingerprint, then POST .../authenticate. This step crosses a trust boundary. If Challenge required: The buyer completes the issuer challenge.
Step 6: Buyer to Authentication provider: Issuer challenge (if any).
Step 7: Agent (AI surface) to Merchant API: Complete with authentication_result. This step crosses a trust boundary. If Outcome denied: Merchant declines; session stays open or ends per merchant policy.
Source of truth: 4.4 and 8 (external link) Generated from src/content/flows/openai-acp-3ds-authentication.json.
Play this flow step by step
Agent (AI surface)
Merchant API
Authentication provider
Buyer
1
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 7Merchant API toto Agent (AI surface)
Session status authentication_required
The merchant must include authentication_metadata (acquirer details, directory server).
Spec version 2026-04-17 (2026-04-17). Sources: [12], [23], [24], [45]
Step 1 of 7: Merchant API to Agent (AI surface). Session status authentication_required.
ACP failure: idempotency key reused or still in flight
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
A retried create request reuses an Idempotency-Key. The server replays, rejects a changed body with 422 or a concurrent duplicate with 409.
Text alternative
Sequence diagram: ACP failure: idempotency key reused or still in flight. 2 participants: Agent (AI surface) and Merchant API. 5 steps, 3 crossing a trust boundary, 1 failure branch. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Agent (AI surface) to Merchant API: POST /checkout_sessions (key idem_001). This step crosses a trust boundary. Step 2: Agent (AI surface) to Merchant API: Retry, same key, same body. This step crosses a trust boundary. If Agent retries at once in a loop: More 409 answers; respect Retry-After. Step 3: Merchant API to Agent (AI surface): Replay with Idempotent-Replayed: true. Step 4: Agent (AI surface) to Merchant API: Same key, changed body. This step crosses a trust boundary. Step 5: Merchant API to Agent (AI surface): 422 idempotency_conflict.
Step 1: Agent (AI surface) to Merchant API: POST /checkout_sessions (key idem_001). This step crosses a trust boundary.
Step 2: Agent (AI surface) to Merchant API: Retry, same key, same body. This step crosses a trust boundary. If Agent retries at once in a loop: More 409 answers; respect Retry-After.
Step 3: Merchant API to Agent (AI surface): Replay with Idempotent-Replayed: true.
Step 4: Agent (AI surface) to Merchant API: Same key, changed body. This step crosses a trust boundary.
Step 5: Merchant API to Agent (AI surface): 422 idempotency_conflict.
Source of truth: 6.1 (external link) Generated from src/content/flows/openai-acp-failure-idempotency-conflict.json.
Play this flow step by step
Agent (AI surface)
Merchant API
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 5Agent (AI surface) toto Merchant API
POST /checkout_sessions (key idem_001)
First attempt; the network times out before the response arrives.
Spec version 2026-04-17 (2026-04-17). Sources: [12], [22], [45]
Step 1 of 5: Agent (AI surface) to Merchant API. POST /checkout_sessions (key idem_001). Crosses a trust boundary.
ACP alternative path: cancel with an intent trace
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The buyer walks away. The agent cancels the session and may say why with a reason code.
Text alternative
Sequence diagram: ACP alternative path: cancel with an intent trace. 3 participants: Buyer, Agent (AI surface), and Merchant API. 3 steps, 1 crossing a trust boundary, 1 failure branch. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Buyer to Agent (AI surface): Decides not to buy. Step 2: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id}/cancel. This step crosses a trust boundary. If Session already completed or canceled: 405. Step 3: Merchant API to Agent (AI surface): 200 status canceled.
Step 1: Buyer to Agent (AI surface): Decides not to buy.
Step 2: Agent (AI surface) to Merchant API: POST /checkout_sessions/{id}/cancel. This step crosses a trust boundary. If Session already completed or canceled: 405.
Step 3: Merchant API to Agent (AI surface): 200 status canceled.
Source of truth: Cancel (external link) Generated from src/content/flows/openai-acp-cancel-intent-trace.json.
Play this flow step by step
Buyer
Agent (AI surface)
Merchant API
1
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 3Buyer toto Agent (AI surface)
Decides not to buy
For example, shipping costs too much.
Spec version 2026-04-17 (2026-04-17). Sources: [12], [34], [50]
Step 1 of 3: Buyer to Agent (AI surface). Decides not to buy.
ACP order webhook signing and verification
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The merchant signs each order event with HMAC-SHA256; the agent checks the timestamp window and the signature before it trusts the event.
Text alternative
Sequence diagram: ACP order webhook signing and verification. 2 participants: Merchant API and Agent (AI surface). 4 steps, 1 crossing a trust boundary, 3 failure branches. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Merchant API to Merchant API: Sign the raw body. Step 2: Merchant API to Agent (AI surface): POST /agentic_checkout/webhooks/order_events. This step crosses a trust boundary. If Header missing or malformed: 401. If Timestamp outside 300 seconds: 401 (replay). If Signature mismatch: 401. Step 3: Agent (AI surface) to Agent (AI surface): Verify, then process. Step 4: Agent (AI surface) to Merchant API: 2xx acknowledgment.
Step 1: Merchant API to Merchant API: Sign the raw body.
Step 2: Merchant API to Agent (AI surface): POST /agentic_checkout/webhooks/order_events. This step crosses a trust boundary. If Header missing or malformed: 401. If Timestamp outside 300 seconds: 401 (replay). If Signature mismatch: 401.
Step 3: Agent (AI surface) to Agent (AI surface): Verify, then process.
Step 4: Agent (AI surface) to Merchant API: 2xx acknowledgment.
Text payload. Illustrative example, spec version 2026-04-17.
# Illustrative example, spec version 2026-04-17.
signed_payload = t + "." + raw_body
v1 = hex(HMAC_SHA256(secret, signed_payload))
Spec version 2026-04-17 (2026-04-17). Sources: [10], [17]
Step 1 of 4: Merchant API to Merchant API. Sign the raw body.
ACP product feed push (Feed API, 2026-04-17)
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The agent hosts the Feed API and the merchant pushes products to it. OpenAI runs the same idea under /product_feeds paths.
Text alternative
Sequence diagram: ACP product feed push (Feed API, 2026-04-17). 2 participants: Merchant API and Agent (AI surface). 4 steps, 2 crossing a trust boundary, 1 failure branch. Based on openai-acp 2026-04-17 (2026-04-17). Step 1: Merchant API to Agent (AI surface): POST /feeds. This step crosses a trust boundary. Step 2: Merchant API to Agent (AI surface): PATCH /feeds/{id}/products. This step crosses a trust boundary. If Invalid product: 4xx; fix and resend. Step 3: Agent (AI surface) to Merchant API: GET /feeds/{id}/products (optional). Step 4: Merchant API to Agent (AI surface): Full file replacement (alternative).
Step 1: Merchant API to Agent (AI surface): POST /feeds. This step crosses a trust boundary.
Step 2: Merchant API to Agent (AI surface): PATCH /feeds/{id}/products. This step crosses a trust boundary. If Invalid product: 4xx; fix and resend.
Step 3: Agent (AI surface) to Merchant API: GET /feeds/{id}/products (optional).
Step 4: Merchant API to Agent (AI surface): Full file replacement (alternative).
Source of truth: /feeds (external link) Generated from src/content/flows/openai-acp-product-feed-push.json.
Play this flow step by step
Merchant API
Agent (AI surface)
1
Crosses a trust boundary
Use the left and right arrow keys to step, space to play or pause, Home and End to jump.
Step 1 of 4Merchant API toto Agent (AI surface)
POST /feeds
Create a feed (target_country); the response carries the server-assigned id. 201 on success.
JSON payload. Illustrative example, spec version 2026-04-17.
// Illustrative example, spec version 2026-04-17.
{
"target_country": "US"
}
Spec version 2026-04-17 (2026-04-17). Sources: [10], [18], [22], [59]
Step 1 of 4: Merchant API to Agent (AI surface). POST /feeds. Crosses a trust boundary.
ACP REST endpoints mapped to MCP tools
Scroll to see the whole diagram
Diagram loads when it scrolls into view.
The MCP binding maps each checkout endpoint to one tool and moves headers into arguments.meta. Authorization moves to MCP server configuration and ACP errors use JSON-RPC code -32000. The ChatGPT payment sheet uses a different Apps SDK tool.
Text alternative
Two columns. REST: POST /checkout_sessions, GET /checkout_sessions/{id}, POST /checkout_sessions/{id}, POST .../complete, POST .../cancel, and headers API-Version, Idempotency-Key, Signature, Timestamp, Request-Id. MCP: create_checkout_session, get_checkout_session, update_checkout_session, complete_checkout_session, cancel_checkout_session, and arguments.meta with api_version, idempotency_key, signature, timestamp, request_id. Each REST item links to its MCP counterpart. A separate box, the Apps SDK tool complete_checkout used by the ChatGPT payment sheet, is marked as a different tool from complete_checkout_session.
Five points where OpenAI's implementation docs differ from the 2026-04-17 spec. The spec is primary for ACP; OpenAI's docs are primary for what ChatGPT expects. Accept both forms where you can.
Text alternative
Side-by-side list. Spec: feed paths /feeds; webhooks order_create and order_update; complete returns 200; idempotency_conflict is 422; TLS 1.3 required. OpenAI docs: feed paths /product_feeds plus a promotions API; webhooks order_created and order_updated; complete returns 201 Created; idempotency_conflict is 409; TLS 1.2 or later. Each pair is marked as differing.
Solid lines are documented links: Stripe's SPT implements Delegate Payment and may carry Visa and Mastercard agent tokens, and MPP accepts cards through SPTs. Dotted lines mark relations with no bridge or no documented link.
Text alternative
Diagram. ACP's Delegate Payment is implemented by Stripe's SPT. The SPT may carry Visa Intelligent Commerce and Mastercard Agent Pay tokens. Stripe MPP accepts cards through SPTs. Dotted links: ACP and UCP side by side with no bridge; AP2 mandates do not exist in ACP; Visa TAP has no documented link; x402 sits in a different lane next to MPP; ERC-8004 has no documented link.
Spec-deep mode: the full explanation plus 0 field tables and wire examples.
STE mode: section B is hidden; the Simplified Technical English version (section D) is shown first.
This section uses Simplified Technical English (ASD-STE100): short sentences, one instruction per step, and one word for one meaning.
ACP is an open protocol for checkout by an AI agent. OpenAI and Stripe started ACP in 2025. The merchant operates a REST API for checkout sessions. The agent uses this API to buy products for a buyer.
ACP has four roles. The buyer approves the purchase in the interface of the agent. The agent sends the requests to the merchant. The merchant keeps the orders, the payments, the taxes and the refunds. A payment service provider changes the card of the buyer into a token.
The merchant is the merchant of record. OpenAI is not the merchant of record. The merchant charges the payment with its own payment service provider.
The token has an allowance. The allowance gives one merchant, one checkout session, one maximum amount, one currency and one expiry time. The merchant can use the token one time only.
ACP does not identify the agent with a public key directory. The agent and the merchant use a secret API key between them. ACP does not record proof that the buyer approved the purchase. The Shared Payment Token is a product of Stripe. It is not part of the ACP specification.
Each version of ACP has a date, for example 2026-04-17. The client sends this date in the API-Version header.
Procedure Buy a product with ACP (agent)
Send a POST request to /checkout_sessions with the line items and the currency.
Put the API key, the API-Version header and an Idempotency-Key header in each POST request.
Show the line items, the totals and the messages from the merchant to the buyer.
Send the address and the fulfillment option of the buyer in an update request.
Wait until the status is ready_for_payment.
Get the approval of the buyer for the total amount.
Send the card and the allowance to the payment service provider.
Keep the token from the response.
Send the token in payment_data to the /complete endpoint.
Read the order in the response. Show the order link to the buyer.
Procedure Accept an ACP checkout (merchant)
Give an API key to each agent that you accept.
Make sure that each request has a correct API key and API-Version header.
If a POST request has no Idempotency-Key header, send status 400.
Calculate the line items, the taxes and the totals in minor units.
Send the full checkout session in each response.
Put problems with the order in the messages of the session.
When the agent sends the complete request, charge the token with your payment service provider.
Make an order. Send the status completed and the order in the response.
Send the order_create event to the webhook of the agent.
Procedure Verify an order webhook (agent platform)
Read the Merchant-Signature header.
Get the time value t and the signature value v1 from the header.
If the time value is more than 300 seconds old, send status 401.
Calculate HMAC-SHA256 with the shared secret over the time value, a dot and the raw body.
Compare your result with the v1 value.
If the values are not equal, send status 401.
If the values are equal, process the order event.
Technical nouns and technical verbs
checkout session: The record of one purchase on the server of the merchant.
line item: One product and its quantity in a checkout session.
allowance: The limits of a token: merchant, session, maximum amount, currency and expiry time.
vault token: A token that a payment service provider gives in place of a card number.
payment handler: A method of payment that the merchant accepts in a session.
merchant of record: The company that sells the product and accepts the payment.
idempotency key: A value that makes sure that the server does one action one time only.
order webhook: A message from the merchant to the agent about the status of an order.
minor units: The smallest unit of a currency, for example cents.
delegate (TV): To give a limited right to another party.
complete (TV): To finish a checkout session with a payment.
STE check report
Sentences
72
Longest procedural sentence
16 words (limit 20)
Longest descriptive sentence
16 words (limit 25)
Flags
None
Written to the public ASD-STE100 Issue 9 writing rules. Vocabulary not checked against the official dictionary.
Compare with the practitioner text side by side
Practitioner text (section B)
ACP answers one question: how does an AI surface run a purchase against a merchant without becoming the store? The merchant hosts a small REST (representational state transfer) API (application programming interface) for checkout sessions and stays system of record for orders, payments, taxes and compliance. The agent creates a session, updates it with an address and a shipping choice, and gets back the merchant's authoritative lines, totals and messages each time. To pay, the agent asks a payment service provider (PSP) to swap the buyer's card for a vault token that only works for one merchant, one session, one use, a maximum amount and a deadline. The agent sends that token on complete, the merchant charges it through its own PSP, and the response must carry an order. OpenAI is never the merchant of record. What ACP does not give you: a signed proof of what the user wanted, an agent identity scheme, or a public registry of agents. Those live in other layers or in bilateral onboarding.
The Agentic Commerce Protocol (ACP) is an open standard from OpenAI and Stripe for running checkout between an AI agent, a buyer and a business. It was announced on 2025-09-29 together with Instant Checkout in ChatGPT, and Stripe introduced its Shared Payment Token (SPT) the same day. The README lets agents embed commerce without becoming the merchant of record.
Simplified Technical English
ACP is an open protocol for checkout by an AI agent. OpenAI and Stripe started ACP in 2025. The merchant operates a REST API for checkout sessions. The agent uses this API to buy products for a buyer.
ACP has four roles. The buyer approves the purchase in the interface of the agent. The agent sends the requests to the merchant. The merchant keeps the orders, the payments, the taxes and the refunds. A payment service provider changes the card of the buyer into a token.
The merchant is the merchant of record. OpenAI is not the merchant of record. The merchant charges the payment with its own payment service provider.
E. Main personas
AI surface product lead
Runs the agent surface: calls merchants' checkout APIs, obtains delegated tokens, hosts the order webhook receiver and, since 2026-04-17, the Feed API. Source [12, 17, 19, 34]
Goals
Let buyers complete purchases without leaving the conversation
Onboard many merchants on one contract
Keep card data out of the model and the merchant API
Pains
Each merchant needs its own bearer key and onboarding
Merchants implement different versions and drift from the examples
Six checkout statuses have no RFC definition
Implements
Checkout client for create, update, complete and cancel
Delegate Payment call with an allowance per purchase
Merchant-Signature verification on /agentic_checkout/webhooks/order_events
Feed API endpoints for pushed products
Must trust
The merchant to return authoritative totals and honor its own messages
The PSP to enforce the allowance
The merchant's webhook secret handling
Questions, first steps, metrics and a day in the life
Questions they ask
Which API-Version does this merchant support?
Should we accept both order_create and order_created?
How do we show a requires_escalation session?
First three steps
Read the 2026-04-17 JSON Schema and OpenAPI files
Run the repository validation script against your own payloads
Integrate one merchant end to end with Idempotency-Key on every POST
Metrics they care about
Checkout completion rate
Share of sessions ending in messages with resolution requires_buyer_input
Webhook signature failures
Time from create to completed
A day in the life
Priya leads checkout on an assistant app. A buyer asks for a lamp, and her client creates a session at the merchant with a fresh idempotency key. The merchant returns not_ready_for_payment and a message that the address is missing. The assistant asks, sends an update, and the session turns ready_for_payment. After the buyer confirms 84 dollars, Priya's service asks the PSP for a token capped at exactly that amount, bound to this merchant and session, valid for fifteen minutes. Completion returns an order link. Two days later a signed order_update says shipped, and her receiver rejects a replayed copy that arrives outside the 300-second window.
Sells through agent surfaces with as little integration as possible, usually through a platform or PSP rather than a hand-built ACP server. Source [8, 14, 22, 59]
Goals
Appear in ChatGPT product results
Keep using the existing checkout and PSP
Avoid PCI DSS scope changes
Pains
Approval for ChatGPT feeds is limited to approved partners
Fees are not published by OpenAI
Unclear which platform covers which protocol
Implements
A product feed through a provider such as Shopify Catalog, Salesforce or Stripe
External checkout on the merchant site
Must trust
The platform or PSP to implement ACP correctly
OpenAI to rank products fairly
Questions, first steps, metrics and a day in the life
Questions they ask
Do I need to build anything, or does my platform cover ACP?
What does a sale through ChatGPT cost me?
Who handles a chargeback?
First three steps
Ask your commerce platform whether it sends your catalog to ChatGPT
Check that your product data has ids, variants, prices and availability
Read OpenAI's prohibited products list
Metrics they care about
Orders from AI surfaces
Feed errors
Refund and chargeback rate on agent orders
A day in the life
Tomas runs a small outdoor gear shop on a hosted platform. In 2025 he read that ChatGPT would let buyers check out in chat and waited for his platform to switch it on. In March 2026 the plan changed: OpenAI now pulls product data through feeds, and buyers finish on his own store. His platform already sends the catalog, so he fixes missing variant titles and stale prices, since a feed product needs ids and variants. Orders still arrive through his normal checkout and PSP. When a buyer disputes a tent, Tomas answers the chargeback himself, because he remains merchant of record.
Builds and runs its own ACP server: checkout endpoints, order webhooks, discovery and feeds, often across several agent surfaces. Source [12, 22, 25, 34, 45]
Goals
One integration for several agent platforms
Keep pricing, tax and fraud logic authoritative
Reuse existing order management
Pains
Released spec folders change after release
OpenAI docs and the spec disagree on status codes and names
UCP asks for a similar but different integration
Implements
/checkout_sessions endpoints with idempotency storage for 24 hours or more
Payment handlers and PSP charging of vault tokens
Signed order_create and order_update webhooks
/.well-known/acp.json
Must trust
Agents to render totals and messages as returned
The PSP to reject out-of-allowance charges
Bearer keys to stay secret on both sides
Questions, first steps, metrics and a day in the life
Questions they ask
Which version should we pin, and at which commit?
Do we run ACP and UCP side by side?
How do we map our order states to the ACP order status list?
First three steps
Pin a commit of spec/2026-04-17 and validate your examples against it
Implement idempotency exactly as RFC section 6 says
Add the docs-versus-spec differences to your test suite
Metrics they care about
Conversion by agent surface
Idempotency conflicts and replays
Chargebacks on agent orders
Latency of create and complete
A day in the life
Lena's team at a home goods retailer built an ACP server in a sprint. The hard part was not the endpoints but the drift: the RFC examples sent items with a quantity that their schema validator rejected, so they followed the JSON Schema and the repository's examples file. They store every idempotency key for 48 hours and return 422 on a changed body, while their client library also tolerates 409 because OpenAI's checklist says so. A month later they publish acp.json and start a UCP adapter, reusing the same order service but a separate checkout layer.
Hosts Delegate Payment or a compatible token product (Stripe SPT), vaults the card, enforces the allowance and processes the merchant charge. Source [19, 20, 39]
Goals
Issue tokens that only work inside the allowance
Keep merchants out of PCI DSS scope
Offer agentic payments to existing merchants
Pains
ACP defines no error codes for allowance violations
Signing rules for Delegate Payment contradict each other
Network token support varies
Implements
POST /agentic_commerce/delegate_payment returning vt_ tokens
Allowance checks at charge time
Risk signals such as card_testing scores
Must trust
The agent to set max_amount to what the buyer approved
The agent's bearer key and signature handling
Questions, first steps, metrics and a day in the life
Questions they ask
Do we require the detached Signature even though the OpenAPI marks it optional?
Which decline code do we return for an expired token?
Can network agent tokens sit under our token?
First three steps
Implement the Delegate Payment schema with all six allowance fields
Decide and publish your signature policy
Map allowance failures to clear decline codes
Metrics they care about
Token issuance volume
Declines by allowance rule
Fraud rate on delegated tokens
A day in the life
Marco works on a PSP's agentic team. His service receives Delegate Payment calls from an agent platform: a network token, an allowance of 120 dollars for one merchant and one checkout session, expiring in thirty minutes. He returns a vault token and stores the limits next to it. An hour later the merchant tries to charge it for 140 dollars after adding gift wrap without a new confirmation. His engine declines it, but ACP gives him no standard code, so he documents his own and tells the merchant to start a new session. He also requires the detached signature on every request, since RFC section 2.2 says the client must sign.
Buys through an AI assistant and sees the merchant, not the assistant, as the seller. Source [8, 22, 34]
Goals
Buy quickly without typing a card number again
Know who to contact if something goes wrong
Not be charged more than approved
Pains
The checkout path changed in 2026 and differs by merchant
No signed record of what was approved
Unclear fees and ranking
Implements
Confirming the purchase in the assistant interface
Must trust
The assistant to show the merchant's real totals
The merchant to fulfill and refund
The token to be limited to the approved amount
Questions, first steps, metrics and a day in the life
Questions they ask
Who is the seller here?
Can the assistant charge me again?
Where do I ask for a refund?
First three steps
Check the merchant name and total before you confirm
Keep the order link the assistant shows
Use the merchant's own support for returns
Metrics they care about
Total charged versus total approved
Time to refund
A day in the life
Sam asks an assistant for running shoes in size ten. The assistant shows three options from different stores, each with a price from the store itself. Sam picks one and confirms the total, including tax and shipping. The assistant says the purchase is with the store, and the card statement later shows the store's name, not the assistant's. When the shoes are too small, Sam opens the order link and starts a return on the store's site. The refund appears as an adjustment in the order updates the assistant receives. Nothing in the protocol records Sam's confirmation except the assistant's own interface.
Builds an agent or app that calls ACP merchants over REST or MCP, or a ChatGPT app with the payment sheet. Source [10, 15, 37]
Goals
Use one client for many merchants
Choose between REST and MCP transports
Handle every message and status
Pains
MCP binding and REST differ on idempotency
The Apps SDK complete_checkout tool is not the ACP tool
No official SDK
Implements
REST or MCP client for the five checkout operations
Message handling by resolution
Retry logic with the same Idempotency-Key
Must trust
Merchants to follow the version they advertise in acp.json
Questions, first steps, metrics and a day in the life
Questions they ask
Is complete_checkout the same as complete_checkout_session?
Which statuses are terminal?
Can I use an unofficial SDK?
First three steps
Read docs/mcp-binding.md and the OpenRPC file
Generate types from the 2026-04-17 JSON Schema
Write tests for 400, 409 and 422 idempotency answers
Metrics they care about
Successful completions per merchant
Retries and replays
Unknown status values seen
A day in the life
Ana writes an agent that shops across merchants and prefers MCP. She maps the five ACP tools, passes api_version and an idempotency key in meta, and treats JSON-RPC error -32000 as an ACP error object. Her first bug comes from the ChatGPT payment sheet docs: their complete_checkout tool is an Apps SDK tool, not the ACP binding's complete_checkout_session, so her merchant mock never answered. She also finds that the binding still lets the idempotency key be optional, while REST requires it, so she always sends one. Unknown statuses such as pending_approval go to a holding screen.
Builds Tamarin models of x402, MPP, ACP and AP2 from their specifications, schemas and reference code using one shared abstraction of the agent payment lifecycle, then asks source-backed verification questions to expose missing bindings and cross-stage correspondences, which it consolidates into 18 security principles. Across 86 verification cases it reproduces 46 known or calibration cases, reports 40 new formal-consistency findings, and validates ten of them against x402 implementations with proofs of concept.
Why it matters here: The only side-by-side formal model of x402, stripe-mpp, openai-acp and ap2 so far; it shows where each specification leaves delegated authority, settlement and fulfillment unbound. AP2: Tamarin models that include AP2. ERC-8004: Trustless Agents: Formal models of agent payment protocols around ERC-8004. Agentic Commerce Protocol (ACP): Models ACP in Tamarin with x402, MPP and AP2; the only formal analysis that names it. Stripe MPP (Machine Payments Protocol): Models MPP in Tamarin alongside x402, ACP and AP2; the only formal analysis that names MPP. UCP: Formal analysis of agent payment protocols; the abstract does not name UCP but analyzes AP2, which UCP embeds as an extension. x402: Formal Tamarin models of x402 alongside MPP, ACP and AP2.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{jiang2026formal,
title = {{A Formal Analysis of Agent Payment Protocols}},
author = {Ke Jiang and Mohan Yu and Yuan Chang and Mohit Kumar Jangid and Jianyu Niu and Cong Wang and Yinqian Zhang},
year = {2026},
eprint = {2609.00060},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.00060}
}
Defines agentic payments as transactions started and completed by AI agents, sets out how they work across retail, e-commerce and decentralized finance, and classifies their technical, legal and societal risks, including liability gaps and regulatory non-compliance.
Why it matters here: One of the few peer-reviewed legal analyses aimed at agent payments specifically, useful for the compliance and liability questions every protocol in the atlas leaves to implementers. AP2: Risks and regulation of agent payments. Mastercard Agent Pay: Survey of risks and regulation for AI agents in payments that covers card-network programs. Agentic Commerce Protocol (ACP): Risks and regulation of AI agents in payments, covering ACP.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{amariles2026payments,
title = {{AI Agents in Payments: Applications, Risks and Regulations}},
author = {David Restrepo Amariles and Damien Charlotin and Liyun He-Guelton},
year = {2026},
journal = {European Journal of Risk Regulation},
volume = {17},
number = {3},
pages = {884--907},
publisher = {Cambridge University Press},
doi = {10.1017/err.2026.10103},
url = {https://doi.org/10.1017/err.2026.10103}
}
Argues that AP2 and ACP lack interoperable, tamper-evident audit trails and proposes a global event timeline built from canonical event schemas, deterministic batching, Merkle commitments and blockchain anchoring, plus signed fraud markers tied to that evidence. A single-author prototype reports throughput figures; a copy is also on Zenodo (DOI 10.5281/zenodo.19060285).
Why it matters here: Names a gap shared by AP2 and ACP, the lack of a common verifiable event log for disputes and fraud signals, and sketches one way to fill it. Agentic Commerce Protocol (ACP): Argues ACP lacks interoperable, tamper-evident audit trails.
Metadata verified 2026-10-11 through arxiv.
Show BibTeX
@misc{srivastava2026timeline,
title = {{Building Trust in Autonomous Commerce: A Verifiable Global Event Timeline and AI-Ready Fraud Intelligence Layer}},
author = {Rajat Srivastava},
year = {2026},
eprint = {2607.19436},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.19436}
}
Surveys agent communication protocols with a two-dimensional classification (context-oriented versus inter-agent, general-purpose versus domain-specific), compares them on security, scalability and latency, and lays out directions such as layered architectures, privacy preservation and group interaction.
Why it matters here: Provides the taxonomy into which payment and commerce protocols (x402, AP2, ACP, UCP) slot as domain-specific layers above MCP and A2A. UCP: Survey of AI agent protocols for orientation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025protocols,
title = {A Survey of AI Agent Protocols},
author = {Yingxuan Yang and Huacan Chai and Yuanyi Song and Siyuan Qi and Muning Wen and Ning Li and Junwei Liao and Haoyi Hu and Jianghao Lin and Gaowei Chang and Weiwen Liu and Ying Wen and Yong Yu and Weinan Zhang},
year = {2025},
eprint = {2504.16736},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2504.16736},
note = {arXiv preprint}
}
Simulates conversations between an LLM-played user and an agent that has domain API tools and policy documents, grading by comparing the final database state to an annotated goal and introducing the pass^k reliability metric. Even strong function-calling agents succeeded on under half of the tasks and were inconsistent across trials, with pass^8 below 25 percent in retail.
Why it matters here: Its retail domain (orders, exchanges, refunds under policy) is the post-purchase side of ACP and UCP, and pass^k is the reliability framing merchants need before letting agents touch orders. Agentic Commerce Protocol (ACP): Retail tool-use benchmark close to ACP checkout tool calls.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{yao2025taubench,
title = {{$\tau$}-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains},
author = {Shunyu Yao and Noah Shinn and Pedram Razavi and Karthik Narasimhan},
year = {2025},
booktitle = {The Thirteenth International Conference on Learning Representations (ICLR 2025)},
url = {https://openreview.net/forum?id=roNSXZpUDN},
eprint = {2406.12045},
archivePrefix = {arXiv}
}
A reproducible environment of fully functional websites across e-commerce, forums, software development and content management, with tools and knowledge bases and a benchmark of long-horizon tasks graded on functional correctness rather than on action traces.
Why it matters here: Its e-commerce site is the standard sandbox for web shopping agents; Piet et al. and Shi et al. in this bibliography build their security arguments on it. UCP: Foundation benchmark for web agents that shop through ordinary sites, the path UCP replaces.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{zhou2024webarena,
title = {WebArena: A Realistic Web Environment for Building Autonomous Agents},
author = {Shuyan Zhou and Frank F. Xu and Hao Zhu and Xuhui Zhou and Robert Lo and Abishek Sridhar and Xianyi Cheng and Tianyue Ou and Yonatan Bisk and Daniel Fried and Uri Alon and Graham Neubig},
year = {2024},
booktitle = {The Twelfth International Conference on Learning Representations (ICLR 2024)},
url = {https://openreview.net/forum?id=oKn9c6ytLx},
eprint = {2307.13854},
archivePrefix = {arXiv}
}
A design-science study proposing a protocol-agnostic merchant-side architecture for agentic commerce built around a canonical decision envelope, protected dependency and result hashes, Ed25519 or HMAC authentication, live-request rebinding, a generated-claim gate and eleven semantic invariants, evaluated on an open-source JavaScript implementation with eight scenarios and five ablations; the author lists production security and interoperability as not established.
Why it matters here: Addresses what a merchant must keep authoritative when openai-acp, ucp or ap2 checkout messages arrive from agents, complementary to those protocol specifications. Agentic Commerce Protocol (ACP): Merchant-side reference architecture for agent commerce of the kind ACP serves.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{sfiris2026decisioncentered,
title = {{A Decision-Centered Reference Architecture for Trustworthy Agentic Commerce}},
author = {Dimitrios S. Sfiris},
year = {2026},
eprint = {2607.18347},
archivePrefix = {arXiv},
primaryClass = {cs.SE},
url = {https://arxiv.org/abs/2607.18347}
}
Treats reusable agent skills as externalized policies and presents SkillShift, a supply-chain attack that keeps a skill's declared task and output interface while covertly steering decisions toward an undisclosed objective. In agentic commerce and dependency selection it achieved attacker-favored selection rates of 81.33 and 63.33 percent with no utility loss, transferred across backends, and evaded the evaluated scanners.
Why it matters here: A merchant-steering attack that needs no prompt injection: a shopping agent's skill package can bias which seller wins an ACP or UCP checkout while every protocol message stays valid.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026skillshift,
title = {A Finger on the Scale: Covert Policy Steering through Agentic Skills},
author = {Jiarui Li and Jiahao Chen and Chunyi Zhou and Yuwen Pu and Oubo Ma and Zhou Feng and Chunqiang Hu and Shouling Ji},
year = {2026},
eprint = {2609.02564},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.02564},
note = {arXiv preprint}
}
AID-Guard closes the gap between authorization at admission and the provider effect that follows: it revalidates the approved request and provider state at commit, holds one reservation under ambiguity, and releases a successor only after a terminal result or a certified no-effect, so one approval yields at most one effect across retries and recovery. A prototype was tested against Stripe and Resend provider contracts, with all 210 Stripe trials matching predeclared outcomes.
Why it matters here: Exactly-once effects and idempotency are the operational core of agent payments; this is an evaluated protocol that treats a Stripe charge as a delegated effect with its own lifecycle, relevant to MPP and ACP implementations.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{tong2026aidguard,
title = {AID-Guard: Stateful Authorization for Delegated Agent Effects},
author = {Yingzhe Tong and Leyu Dai and Songhui Guo},
year = {2026},
eprint = {2608.21159},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2608.21159},
note = {arXiv preprint}
}
A structured narrative review of 89 sources from 2023 to 2026 on authorization for tool-using agents, organized around a principal hierarchy (human, operator, orchestrator, sub-agent, tool endpoint) and five layers: identity and credential lifecycle, multi-hop delegation and scope propagation, runtime enforcement at policy enforcement points, prompt injection as authorization bypass, and auditability. It derives seven structural requirements and a four-layer reference architecture.
Why it matters here: A map of the delegation literature that the mandate chains of ap2 and the agent identity in visa-tap and openai-acp draw on.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{surapani2026authorization,
title = {{Authorization Architectures for Tool-Using AI Agents}},
author = {Rakesh Kumar Surapani and Pradeep Kumar Dolabehera Kakitapelli and Arun Morampudi and Praveena Padi},
year = {2026},
eprint = {2609.15906},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2609.15906}
}
A simulated consumer-to-consumer marketplace with 100 agents, eBay-derived inventories and reputation-based trust, scoring six failure types across five transaction stages over 357,608 model calls. All five tested models promise the same item to multiple buyers, and under adversarial instructions the share of committed sales completed despite unavailable items or overstated condition rises from 15.4 to 33.4 percent, with most extra earnings coming from goods the sellers never held.
Why it matters here: Tests whether reputation can hold a decentralized agent market together, the premise behind ERC-8004's Reputation Registry, and measures delegation failures that ACP and UCP style checkouts would inherit from the agents using them.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wang2026bazaarbench,
title = {BazaarBench: Delegation Safety in Decentralized C2C Marketplaces Run by LLM Agents},
author = {Ziyan Wang and Shuqing Shi and James Oldfield and Samuele Marro and Jialin Yu and Philip Torr and Yali Du and Adel Bibi},
year = {2026},
eprint = {2610.06748},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2610.06748},
note = {arXiv preprint}
}
Introduces WebDecept, a plugin that injects seven deceptive interface patterns (targeted advertisements, domain redirection, shopping manipulation and others) into existing web environments, and evaluates multimodal web agents under them. Agents were highly susceptible to several classes of deception and prompt-based constraints were often insufficient.
Why it matters here: Measures the merchant-side manipulation surface that structured checkouts in UCP and ACP are meant to remove, and gives a baseline for how agents behave when they must still browse a storefront. UCP: Web agent safety under deceptive e-commerce interfaces, which a trusted review UI must withstand.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{shi2026deceptive,
title = {Benchmarking Web Agent Safety under E-commerce Deceptive Interfaces},
author = {Zijing Shi and Meng Fang and Ling Chen},
year = {2026},
booktitle = {Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers)},
publisher = {Association for Computational Linguistics},
pages = {22090-22103},
doi = {10.18653/v1/2026.acl-long.1009},
url = {https://aclanthology.org/2026.acl-long.1009/},
eprint = {2606.13686},
archivePrefix = {arXiv}
}
Shows that CaMeL's guarantees do not compose when agents call other agents as tools, because a downstream agent can reinterpret untrusted data as trusted input, and gives a concrete attack. Multi-CaMeL, an agent-to-agent protocol that passes untrusted data through a separate channel, brings attack success on MultiAgentDojo to 0.0 percent versus 0.2 percent for single-agent CaMeL and 12.9 percent undefended.
Why it matters here: Agent-to-agent commerce (A2A with x402, or buyer and merchant agents under ACP) is the hierarchical setting in which single-agent defenses fail; the protocol-level fix speaks to how payment messages between agents should be typed.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{petersgill2026multicamel,
title = {Can CaMeLs Talk? Securing Multi-Agent Systems Against Indirect Prompt Injection Attacks},
author = {James Peters-Gill and Avi Semler and Henning Bartsch and Ilia Shumailov and Christian Schroeder de Witt},
year = {2026},
eprint = {2610.05640},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2610.05640},
note = {arXiv preprint}
}
Studies when a principal can safely delegate approval of a long-running agent's actions to a panel of possibly misaligned reviewer agents, and characterizes k-robust coalitional alignment as the necessary and sufficient condition for a threshold approval rule to guarantee the principal does at least as well as a baseline policy, extending the result to sequential control in discounted MDPs and to strategic voting.
Why it matters here: Theory for the human-approval bottleneck that ap2 mandates and openai-acp checkout confirmations encode; it asks when approval itself can be delegated. AP2: Theory of approving actions of possibly misaligned agents.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{collina2026delegating,
title = {{Delegating Authorization to Misaligned Agents: Coalitional Alignment and Safe Control}},
author = {Natalie Collina and Surbhi Goel and Aaron Roth and Sikata Bela Sengupta},
year = {2026},
eprint = {2609.15803},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2609.15803}
}
Analyzes 2,583 inter-agent emails from twenty one-year runs of Vending-Bench Arena across 13 frontier models and labels 12.6 percent as misaligned (false factual claims, manipulation, collusion or threats). Misalignment appears in every run and in 74.7 percent of agent-runs, is reciprocal, rises under inventory scarcity, and is not predicted by model capability rank.
Why it matters here: Agent-to-agent commerce protocols assume counterparties negotiate in good faith; this measurement shows deceptive speech acts emerging without adversarial prompting, which bears on reputation layers in ERC-8004 and on merchant-agent trust in ACP and UCP.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2026misaligned,
title = {Emergent Misaligned Communication in Long-Horizon Multi-Agent LLM Commerce},
author = {Zeyuan Li and Lukas Petersson and Alessandro Acquisti and Michiel A. Bakker},
year = {2026},
eprint = {2608.14825},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2608.14825},
note = {arXiv preprint}
}
Proposes receiver-attested receipts for agent actions: the service receiving an agent's call signs a receipt of what it observed, encrypts it to the agent's owner (bound to the authorization token through JWS) and publishes it to a witness-cosigned transparency log, so the owner can reconstruct a tamper-evident trail without trusting the agent or its operator. Instantiated as Sello, with microbenchmarks and a discussion of suppression and collusion attacks.
Why it matters here: An audit primitive for delegated agent actions that would complement the merchant-side evidence in ap2 and openai-acp flows.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{figuera2026notarized,
title = {{Notarized Agents: Receiver-Attested Confidential Receipts for AI Agent Actions}},
author = {Juan Figuera},
year = {2026},
eprint = {2606.04193},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2606.04193}
}
Argues that the most consequential risks in agentic commerce platforms sit in the protocol between agents and commerce services rather than in the model, documenting 33 structural vulnerabilities across three platforms that succeed deterministically regardless of model, three of which chain into a payment hijack. Contributes a taxonomy, AIP-Bench as a deterministic benchmark, and PCAT, a platform-agnostic defense that removes four of five structural attack classes.
Why it matters here: Cross-platform evidence that protocol design, not model alignment, decides the security of openai-acp, ap2 and ucp style checkout flows; the three platforms are not named in the abstract, so the mapping is unconfirmed. Agentic Commerce Protocol (ACP): Protocol-level attacks on agentic commerce platforms; does not name ACP but covers the same layer. UCP: Cross-platform attack taxonomy for agentic commerce platforms; context for section H.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{louck2026protocollevel,
title = {{Protocol-Level Attacks on Agentic Commerce Platforms: A Cross-Platform Taxonomy, AIP-Bench, and Unified Defense}},
author = {Yedidel Louck},
year = {2026},
eprint = {2607.21824},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2607.21824}
}
Argues that ReAct is the wrong default for web agents because product pages mix seller, reviewer and advertiser content, and that agents should commit to a task program before seeing runtime content. All WebArena tasks fit plan-then-execute and 80 percent can run as pure programs; the barrier is that browser actions lack typed, semantic interfaces.
Why it matters here: Makes the case for typed, task-level commerce APIs, which is what UCP and OpenAI ACP provide in place of clicks: structured checkout interfaces are a security measure, not only a convenience.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{piet2026plan,
title = {Web Agents Should Adopt the Plan-Then-Execute Paradigm},
author = {Julien Piet and Annabella Chow and Yiwei Hou and Muxi Lyu and Sylvie Venuto and Jinhao Zhu and Raluca Ada Popa and David Wagner},
year = {2026},
eprint = {2605.14290},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2605.14290},
note = {arXiv preprint}
}
Shows that an external provider controlling only content about its own product can redirect a proactive personal agent to recommend it, recruit the user's private context to justify it and lower adoption friction, without compromising the agent or gaining permissions. Across three environments and six user models the macro gain reaches 77.4 percentage points, and provider influence persists even when no final authorization is given.
Why it matters here: Models the merchant-side incentive to manipulate agent recommendations in ACP and UCP style markets, where the provider's own listing is the injection vector.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wang2026provider,
title = {Who Is Your Agent Serving? Provider-Side Indirect Prompt Injection in Proactive Agents},
author = {Rui Wang and Chao Wang and Xinchen Wang and Yufeng Zheng and Binbin Liu and Yaofei Wang},
year = {2026},
eprint = {2610.05266},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2610.05266},
note = {arXiv preprint}
}
Proposes a framework for authenticated, authorized and auditable delegation of authority from humans to AI agents, extending OAuth 2.0 and OpenID Connect with agent-specific credentials and metadata, and a method for translating natural-language permissions into auditable access control configurations.
Why it matters here: The reference design for delegation chains that ap2 mandates, visa-tap agent identity and openai-acp checkout each assume but implement differently. AP2: Delegation credentials for agents, the idea behind open mandates. Visa Trusted Agent Protocol: Delegated agent credentials, the user-to-agent link that TAP leaves to VIC.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{south2025delegation,
title = {{Authenticated Delegation and Authorized AI Agents}},
author = {Tobin South and Samuele Marro and Thomas Hardjono and Robert Mahari and Cedric Deslandes Whitney and Dazza Greenwood and Alan Chan and Alex Pentland},
year = {2025},
eprint = {2501.09674},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2501.09674}
}
Provides a taxonomy of attacks specific to agent pipelines, organized by threat actor, objective, entry point, attacker observability, strategy and inherent pipeline weaknesses, and demonstrates simple, practical attacks on popular open-source and commercial agents.
Why it matters here: Documents that deployed browsing and shopping agents, the clients that ACP and UCP checkouts serve, can be steered by web content without any model jailbreak.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{li2025commercial,
title = {Commercial LLM Agents Are Already Vulnerable to Simple Yet Dangerous Attacks},
author = {Ang Li and Yin Zhou and Vethavikashini Chithrra Raghuram and Tom Goldstein and Micah Goldblum},
year = {2025},
eprint = {2502.08586},
archivePrefix = {arXiv},
primaryClass = {cs.LG},
url = {https://arxiv.org/abs/2502.08586},
note = {arXiv preprint}
}
Proposes a set of principled design patterns that restrict how untrusted inputs can influence an agent's actions, analyzes their utility and security trade-offs, and illustrates them with case studies of real applications.
Why it matters here: A practical checklist for anyone building a buying agent on ACP, AP2 or x402: the patterns constrain which parts of agent state untrusted merchant content may ever touch.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{beurerkellner2025patterns,
title = {Design Patterns for Securing LLM Agents against Prompt Injections},
author = {Luca Beurer-Kellner and Beat Buesser and Ana-Maria Creţu and Edoardo Debenedetti and Daniel Dobos and Daniel Fabian and Marc Fischer and David Froelicher and Kathrin Grosse and Daniel Naeff and Ezinwanne Ozoani and Andrew Paverd and Florian Tramèr and Václav Volhejn},
year = {2025},
eprint = {2506.08837},
archivePrefix = {arXiv},
primaryClass = {cs.LG},
url = {https://arxiv.org/abs/2506.08837},
note = {arXiv preprint}
}
Introduces indirect prompt injection: adversaries plant instructions in data that an LLM-integrated application will retrieve, so the model is attacked without any direct interface. The paper gives a security taxonomy of impacts, including data theft, worming and contamination of the information ecosystem, and demonstrates attacks on real systems.
Why it matters here: The founding paper for the threat every agentic payment protocol must contain; AP2 mandates, x402 pre-execution filters, TAP intent signatures and ACP's structured checkout all exist partly because retrieved merchant content can hijack the buying agent. Agentic Commerce Protocol (ACP): Indirect prompt injection, relevant to merchant text rendered by the agent.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@inproceedings{greshake2023injection,
title = {Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection},
author = {Kai Greshake and Sahar Abdelnabi and Shailesh Mishra and Christoph Endres and Thorsten Holz and Mario Fritz},
year = {2023},
booktitle = {Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23)},
publisher = {ACM},
pages = {79-90},
doi = {10.1145/3605764.3623985},
eprint = {2302.12173},
archivePrefix = {arXiv},
url = {https://arxiv.org/abs/2302.12173}
}
ACWorld is an environment in which independently controlled buyer and merchant agents transact through a Vibe Commerce Protocol that validates each action before updating shared state and records the interactions for audit. Its benchmark has a 200-task capability track and a 60-task large-catalog track over 785,022 listings; ten models score 65.9 to 85.6 percent and 56.1 to 91.4 percent, and process-level evidence catches errors that final state misses.
Why it matters here: A reproducible testbed for the buyer-agent to merchant-agent transaction loop that OpenAI ACP and UCP standardize, with an audit-log design relevant to dispute handling.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{fan2026acworld,
title = {Agentic Commerce World: An Auditable and Verifiable Environment for Vibe Commerce},
author = {Shicheng Fan and Mingdai Yang and Duohao Wang and Canyu Chen and Yongfeng Zhang and Hua Wei and Manling Li and Julian McAuley and Kun Zhang and Philip S. Yu and Kejing Yu and Zhiwei Liu},
year = {2026},
eprint = {2608.02441},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2608.02441},
note = {arXiv preprint}
}
A search-theoretic model that compares manual product search, which evaluates a few products accurately, with agentic search, which screens a broad catalog through noisy representations of preferences. Manual search collapses beyond a preference-complexity threshold and platform revenue falls to zero, while agentic search avoids the collapse; the paper derives how platforms should set agent refinement depth.
Why it matters here: Supplies the economic rationale for the discovery and product-feed layers of UCP and OpenAI ACP: once consumers delegate search, platform revenue depends on how well the agent elicits preferences rather than on how many items a person inspects. UCP: Economics of agentic commerce, from product search to preference articulation.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{dong2026preference,
title = {From Product Search to Preference Articulation: The Economics of Agentic Commerce},
author = {Lingxiu Dong and Kaiwen Luo and Fasheng Xu},
year = {2026},
eprint = {2608.08395},
archivePrefix = {arXiv},
primaryClass = {econ.TH},
url = {https://arxiv.org/abs/2608.08395},
note = {arXiv preprint}
}
LLM merchant agents fabricate product attributes in most listings under competitive pressure even when told to be honest. CARP, a reputation-penalty mechanism with a deadband that forgives complaint noise and a state-dependent severity, suppresses low-rated liars without any product-level ground truth, and SPARC makes the penalty behaviorally binding so merchants restrain themselves once lying costs sales.
Why it matters here: Shows how a platform-level reputation penalty can govern seller agents behind ACP or UCP storefronts using only noisy complaints, a design that could sit on top of ERC-8004 feedback entries.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2026honesty,
title = {Paying for Honesty Without Knowing the Truth: Reputation-Penalty Design for LLM Marketplace Agents},
author = {Mingdai Yang and Shicheng Fan and Kejing Yu and Duohao Wang and Li Sun and Hao Peng and Philip S. Yu and Zhiwei Liu},
year = {2026},
eprint = {2607.28330},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2607.28330},
note = {arXiv preprint}
}
Using Tool-Lab, a process-tracing setup that hides product attributes behind costly tool calls, the authors test eight deployed LLMs from three providers against just-below pricing and promotional framing. Cues rarely mislead when information is free, but under acquisition costs and a vague goal the agents skip the attributes needed to compute unit price and make heuristic, suboptimal choices much like people.
Why it matters here: Shows that storefront information architecture and tool cost shape what agents buy, which matters for how merchants expose product data in ACP and UCP feeds and for proposals to sell product information per fact over x402. Agentic Commerce Protocol (ACP): Agents as surrogate consumers; behavior behind ACP purchases.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{wadi2026shopping,
title = {Shopping by algorithm: How agentic AI deploys human heuristics as a surrogate consumer},
author = {Davood Wadi and Yu Ma},
year = {2026},
eprint = {2609.28372},
archivePrefix = {arXiv},
primaryClass = {econ.GN},
url = {https://arxiv.org/abs/2609.28372},
note = {arXiv preprint}
}
Argues that the deepest economic effect of generative AI is lower communication friction between consumers and businesses, with assistant agents and service agents transacting programmatically. The authors separate unscripted interactions, enabled by language and protocol design, from unrestricted interactions, which depend on market structure and governance, and discuss walled gardens versus an open agent web, advertising and discovery, micro-transactions and the rebundling of digital goods.
Why it matters here: The clearest economic framing of why ACP, UCP and AP2 exist: its assistant-agent and service-agent split maps onto the buyer-agent and merchant roles those protocols standardize, and its walled-garden warning is the open question behind all of them, with x402 as the micro-transaction case.
Metadata verified 2026-10-10 through doi-negotiation.
Show BibTeX
@article{rothschild2026agenticeconomy,
title = {The Agentic Economy},
author = {David M. Rothschild and Markus M. Mobius and Jake M. Hofman and Eleanor Dillon and Daniel G. Goldstein and Nicole Immorlica and Sonia Jaffe and Brendan Lucier and Aleksandrs Slivkins and Matthew Vogel},
year = {2026},
journal = {Communications of the ACM},
volume = {69},
number = {2},
pages = {39-42},
doi = {10.1145/3747175},
url = {https://doi.org/10.1145/3747175},
eprint = {2505.15799},
archivePrefix = {arXiv}
}
Studies agentic recommendation markets in which a user agent states a need first and platforms compete for its attention. Across three product domains, broader access does not translate into exposure, platforms answer with selectively positive explanations in 73 to 78 percent of first-ranked positions, and tying platform behavior to later user feedback cuts this to 36 to 41 percent while raising purchases of the relevant item.
Why it matters here: Models the merchant-side incentives that UCP and ACP discovery surfaces create when many sellers answer one agent's query, and argues that access, attention and accountability must be designed as one mechanism. Agentic Commerce Protocol (ACP): Platform competition in agentic recommendation, context for ranking and fees. UCP: Economics of agentic recommendation markets and platform competition.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{hong2026platforms,
title = {The User Asks, Platforms Compete: How Agentic Recommendation Markets Take Shape},
author = {Deyao Hong and Kehan Zheng and Qian Li and Jun Zhang and Jie Jiang and Hongning Wang},
year = {2026},
eprint = {2607.25253},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2607.25253},
note = {arXiv preprint}
}
Proposes a framework for the Agentic Web built on three dimensions (intelligence, interaction, economics), traces its evolution from the PC and mobile web, and discusses communication protocols, orchestration and an Agent Attention Economy together with governance risks.
Why it matters here: Its economics dimension and attention-economy discussion anticipate the discovery and monetization questions that UCP, ACP and x402 are now standardizing.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{yang2025agenticweb,
title = {Agentic Web: Weaving the Next Web with AI Agents},
author = {Yingxuan Yang and Mulei Ma and Yuxuan Huang and Huacan Chai and Chenyu Gong and Haoran Geng and Yuanjian Zhou and Ying Wen and Meng Fang and Muhao Chen and Shangding Gu and Ming Jin and Costas Spanos and Yang Yang and Pieter Abbeel and Dawn Song and Weinan Zhang and Jun Wang},
year = {2025},
eprint = {2507.21206},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2507.21206},
note = {arXiv preprint}
}
Places LLM sellers in simulated continuous double auctions and tests when they collude, defined as secret cooperation that harms another party. Direct seller communication increases collusion, propensity differs by model, and oversight or urgency from authority figures changes collusive behavior.
Why it matters here: Relevant to any multi-seller agent market on ACP, UCP or x402: giving seller agents a channel to talk to each other is itself a competition risk.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{agrawal2025collusion,
title = {Evaluating LLM Agent Collusion in Double Auctions},
author = {Kushal Agrawal and Verona Teo and Juan J. Vazquez and Sudarsh Kunnavakkam and Vishak Srikanth and Andy Liu},
year = {2025},
eprint = {2507.01413},
archivePrefix = {arXiv},
primaryClass = {cs.GT},
url = {https://arxiv.org/abs/2507.01413},
note = {arXiv preprint}
}
Introduces Magentic-Marketplace, an open-source simulated two-sided market in which assistant agents represent consumers and service agents represent competing businesses, and uses it to measure utility, behavioral bias, vulnerability to manipulation and the effect of search mechanisms. Frontier models approach optimal welfare only under ideal search, degrade sharply with scale, and show a severe first-proposal bias that gives response speed a 10 to 30 times advantage over quality.
Why it matters here: Discovery and checkout protocols such as UCP and OpenAI ACP create the two-sided agent markets this environment simulates, so its first-proposal and search findings bear directly on how merchant feeds and ranking should be designed. Agentic Commerce Protocol (ACP): Simulated agent marketplaces; context for agent-mediated checkout. UCP: Simulated agentic marketplaces; useful to reason about many platforms meeting many businesses.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{bansal2025magentic,
title = {Magentic Marketplace: An Open-Source Environment for Studying Agentic Markets},
author = {Gagan Bansal and Wenyue Hua and Zezhou Huang and Adam Fourney and Amanda Swearngin and Will Epperson and Tyler Payne and Jake M. Hofman and Brendan Lucier and Chinmay Singh and Markus Mobius and Akshay Nambi and Archana Yadav and Kevin Gao and David M. Rothschild and Aleksandrs Slivkins and Daniel G. Goldstein and Hussein Mozannar and Nicole Immorlica and Maya Murad and Matthew Vogel and Subbarao Kambhampati and Eric Horvitz and Saleema Amershi},
year = {2025},
eprint = {2510.25779},
archivePrefix = {arXiv},
primaryClass = {cs.MA},
url = {https://arxiv.org/abs/2510.25779},
note = {arXiv preprint}
}
Builds an experimental framework in which consumer and merchant LLM agents negotiate and transact with each other. Outcomes differ sharply across models, and behavioral anomalies lead to overspending or acceptance of unreasonable deals, producing losses for both sides.
Why it matters here: Agent-to-agent negotiation is the step before an ACP or UCP checkout and before an AP2 mandate is signed; the paper quantifies the asymmetry and loss risk users accept when they delegate the deal itself.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{zhu2025risky,
title = {The Automated but Risky Game: Modeling and Benchmarking Agent-to-Agent Negotiations and Transactions in Consumer Markets},
author = {Shenzhe Zhu and Jiao Sun and Yi Nian and Tobin South and Alex Pentland and Jiaxin Pei},
year = {2025},
eprint = {2506.00073},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2506.00073},
note = {arXiv preprint}
}
Using ACES, a provider-agnostic framework for auditing agent decisions, the authors measure how LLM shopping agents choose among products. They find demand concentrating on a few modal products, preferences that reshuffle with model updates, strong position biases that persist even in text-only interfaces, and consistent reactions to sponsored tags and platform endorsements.
Why it matters here: Checkout protocols such as OpenAI ACP and UCP move the purchase decision into an agent; this paper quantifies the ranking and position biases merchants and platforms inherit when the agent, not a person, picks the product. Agentic Commerce Protocol (ACP): How agents choose products, relevant to feed-driven discovery in ChatGPT. UCP: Shows how agent buyers are biased by placement and model choice, which matters for platform checkout.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{allouah2025buying,
title = {What Is Your AI Agent Buying? Evaluation, Biases, Model Dependence, & Emerging Implications for Agentic E-Commerce},
author = {Amine Allouah and Omar Besbes and Josué D Figueroa and Yash Kanoria and Akshit Kumar},
year = {2025},
eprint = {2508.02630},
archivePrefix = {arXiv},
primaryClass = {cs.AI},
url = {https://arxiv.org/abs/2508.02630},
note = {arXiv preprint}
}
A simulated e-commerce site with 1.18 million real products and 12,087 crowd-sourced instructions in which an agent must search, customize and buy an item. It introduced compositional instruction following, query reformulation and noisy web text as grounding challenges and collected over 1,600 human demonstrations for training.
Why it matters here: The ancestor of every agentic shopping benchmark; the search, option selection and checkout steps it scripted are what ACP and UCP now turn into protocol messages. Agentic Commerce Protocol (ACP): Foundational shopping-agent benchmark.
Metadata verified 2026-10-10 through publisher.
Show BibTeX
@inproceedings{yao2022webshop,
title = {WebShop: Towards Scalable Real-World Web Interaction with Grounded Language Agents},
author = {Shunyu Yao and Howard Chen and John Yang and Karthik Narasimhan},
year = {2022},
booktitle = {Advances in Neural Information Processing Systems 35 (NeurIPS 2022)},
url = {https://proceedings.neurips.cc/paper_files/paper/2022/hash/82ad13ec01f9fe44c01cb91814fd7b8c-Abstract-Conference.html},
eprint = {2207.01206},
archivePrefix = {arXiv}
}
Builds the standard model of competition between two-sided platforms that must attract both buyers and sellers, showing how price structure, not just price level, determines adoption, with payment cards as a leading example.
Why it matters here: Every agentic checkout protocol is a two-sided platform bet; this model explains the subsidy and fee choices behind merchant and agent adoption of ACP, UCP and card network programs. Agentic Commerce Protocol (ACP): Two-sided market economics behind platform fees on merchants. UCP: Two-sided platform economics behind a protocol that joins agent surfaces and merchants.
Metadata verified 2026-10-11 through doi-negotiation.
Show BibTeX
@article{rochet2003platform,
title = {{Platform Competition in Two-Sided Markets}},
author = {Jean-Charles Rochet and Jean Tirole},
year = {2003},
journal = {Journal of the European Economic Association},
volume = {1},
number = {4},
pages = {990--1029},
doi = {10.1162/154247603322493212},
url = {https://doi.org/10.1162/154247603322493212}
}
Argues that the agentic web needs normative infrastructure, laws, terms of service and norms that distinguish malicious bots from agents acting with a user's delegated authority, because platforms currently block or degrade agent access, often covertly; proposes normative principles and policies enabling appropriately delegated agents to act online.
Why it matters here: Policy context for visa-tap and openai-acp, which exist partly so that merchants can admit delegated agents while refusing abusive bots.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@misc{pattison2026normative,
title = {{The Agentic Web Requires New Normative Infrastructure}},
author = {Cameron Pattison and Matthew Boulos and Noam Kolt and Changbai Li and Tiziano Piccardi and Seth Lazar},
year = {2026},
eprint = {2606.10711},
archivePrefix = {arXiv},
primaryClass = {cs.CY},
url = {https://arxiv.org/abs/2606.10711}
}
Grey literature: central banks, standards drafts and white papers
Christoph Busch. 2026. CERRE Issue Paper. Not peer reviewed
An issue paper (published 2026-07-16) asking whether EU consumer law, built on the assumption that a human makes the final purchase decision, is ready for AI shopping agents, and proposing how to adapt it. It is part of CERRE's Regulatory Lab series, which received input from members including Apple, Booking.com and Microsoft.
Why it matters here: Checkout protocols such as ACP and UCP assume the agent can confirm a purchase; this paper explains where EU disclosure and consent rules may not fit that flow. Agentic Commerce Protocol (ACP): Consumer protection analysis of agentic commerce including ACP.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@techreport{busch2026cerre,
title = {{Agentic AI and Consumer Protection}},
author = {Christoph Busch},
year = {2026},
institution = {Centre on Regulation in Europe (CERRE)},
type = {Issue Paper},
month = {jul},
url = {https://cerre.eu/publications/agentic-ai-and-consumer-protection/}
}
Aaron Cheris, Mikey Vu, Stephanie Koszyk and others. 2025. Bain & Company Snap Chart. Not peer reviewed
A short forecast (2025-12-17) estimating the US agentic commerce market at $300 billion to $500 billion by 2030, about 15% to 25% of e-commerce, with specification-driven purchases such as household essentials moving first.
Why it matters here: Another anchor for the forecast range used in the atlas market pages; Bain counts transactions that agents start, influence or complete.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{cheris2025bain,
title = {{2030 Forecast: How Agentic AI Will Reshape US Retail}},
author = {Aaron Cheris and Mikey Vu and Stephanie Koszyk and Katherine Hall},
year = {2025},
howpublished = {Bain \& Company},
note = {Snap Chart, 2025-12-17. Forecast figures as of publication},
url = {https://www.bain.com/insights/2030-forecast-how-agentic-ai-will-reshape-us-retail-snap-chart/}
}
Morgan Stanley Research. 2025. Morgan Stanley Insights article. Not peer reviewed
A research summary (2025-12-08) forecasting that agentic shoppers could account for $190 billion to $385 billion of US e-commerce spending by 2030, 10% to 20% of the market, and citing a survey in which about 23% of Americans bought something through AI in the past month.
Why it matters here: A mid-range market forecast with survey data on current AI-assisted buying; it marks how far analyst expectations sit from the small measured protocol volumes.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{morganstanley2025shoppingbots,
title = {{Here Come the Shopping Bots}},
author = {{Morgan Stanley Research}},
year = {2025},
howpublished = {Morgan Stanley},
note = {Article, 2025-12-08. Forecast figures as of publication},
url = {https://www.morganstanley.com/insights/articles/agentic-commerce-market-impact-outlook}
}
An OpenID Foundation white paper that surveys the authentication, authorization and identity resources available for today's agents, including MCP-centered practice, and sets out a strategic agenda for scalable access control, agent-centric identities, workload differentiation and delegated authority. Grey literature: the venue is the arXiv journal reference, not a peer-reviewed outlet.
Why it matters here: Standards-community baseline for the identity layer under visa-tap, ap2 and openai-acp; it records what OAuth and OIDC already cover and what is missing. AP2: OpenID Foundation white paper on agent identity and authorization. Visa Trusted Agent Protocol: Survey of agent identity that discusses Web Bot Auth.
Metadata verified 2026-10-10 through arxiv.
Show BibTeX
@techreport{south2025identity,
title = {{Identity Management for Agentic AI: The new frontier of authorization, authentication, and security for an AI agent world}},
author = {Tobin South and Subramanya Nagabhushanaradhya and Ayesha Dissanayaka and Sarah Cecchetti and George Fletcher and Victor Lu and Aldo Pietropaolo and Dean H. Saxe and Jeff Lombardo and Abhishek Maligehalli Shivalingaiah and Stan Bounev and Alex Keisner and Andor Kesselman and Zack Proser and Ginny Fahs and Andrew Bunyea and Ben Moskowitz and Atul Tulshibagwale and Dazza Greenwood and Jiaxin Pei and Alex Pentland},
year = {2025},
institution = {OpenID Foundation},
type = {Whitepaper},
eprint = {2510.25819},
archivePrefix = {arXiv},
primaryClass = {cs.CR},
url = {https://arxiv.org/abs/2510.25819}
}
Katharina Schumacher, Roger Roberts, Katharina Giebel. 2025. McKinsey & Company report. Not peer reviewed
A consulting report (2025-10-17) estimating that agents could orchestrate $900 billion to $1 trillion of US B2C retail revenue by 2030 and $3 trillion to $5 trillion globally, counting goods only. It discusses the infrastructure, business models and trust needed for that shift.
Why it matters here: The largest of the widely cited market forecasts; useful as the upper bound when the atlas compares adoption claims, and it is a forecast, not measured volume.
Metadata verified 2026-10-11 through publisher.
Show BibTeX
@misc{schumacher2025mckinsey,
title = {{The agentic commerce opportunity: How AI agents are ushering in a new era for consumers and merchants}},
author = {Katharina Schumacher and Roger Roberts and Katharina Giebel},
year = {2025},
howpublished = {McKinsey \& Company},
note = {Report, 2025-10-17. Forecast figures as of publication},
url = {https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity-how-ai-agents-are-ushering-in-a-new-era-for-consumers-and-merchants}
}
ACP's one strong control is the allowance: a delegated token works for one merchant, one session, one use, up to a maximum amount and until an expiry, enforced by the PSP. Everything else is bilateral trust. Agents and merchants share bearer keys, request signatures are only recommended on checkout and contradictory on Delegate Payment, request freshness is a SHOULD, and nothing records that the buyer approved the purchase. Order webhooks are well specified with HMAC and a 300-second window. No CVE or GitHub advisory exists, the published research models ACP formally but reports findings only in aggregate, and the practical risks sit in implementations: key handling, card data at PSPs, content injection into the agent and drift between snapshots.
STRIDE threats (11)
STRIDE
Threat
Spec mitigation
Implementer notes
S Spoofing
Stolen bearer key impersonates an agentAgents and merchants authenticate with a bilateral bearer key. Anyone holding the key can create and complete sessions as that agent. Source [12, 22]Preconditions: The key leaks from logs, config or a compromised service; Request signatures are not enforced by the merchant.Impact: Fraudulent orders charged to tokens the attacker obtained elsewhere, or reconnaissance of prices and stock.
Partly
Require the detached Signature and Timestamp on every request even though they are only recommended, rotate keys, and allowlist the agent platform's egress IP ranges.
S Spoofing
Forged order webhookAn attacker posts fake order_update events to the agent's webhook to show false shipping, refunds or cancellations to the buyer. Source [10, 17]Preconditions: The receiver skips Merchant-Signature verification; Or the shared secret leaked.Impact: Buyer misinformed; support load; possible social engineering.
Mitigated by spec
Verify HMAC-SHA256 over the timestamp, a dot and the raw body, reject outside 300 seconds, compare in constant time.
T Tampering
Allowance set above the approved totalThe agent sets max_amount higher than what the buyer confirmed, for example to absorb later changes, so a merchant can charge more than approved. Source [19, 26]Preconditions: Agent bug or policy that pads the allowance; Merchant changes totals after confirmation.Impact: Buyer charged more than approved; dispute.
Partly
Set max_amount to the confirmed total and start a new session when totals change. Stripe tells agents to set max_amount to the transaction total.
T Tampering
Totals changed between confirmation and completeThe merchant returns new totals on complete or adds fees after the buyer confirmed. Source [12, 19]Preconditions: No signed record of the confirmed cart; Allowance larger than the new total.Impact: Charge differs from what the buyer saw.
Partly
Compare the totals in the complete response with the confirmed totals and cancel when they differ; keep the allowance tight.
T Tampering
Version and schema drift exploitedAgents and merchants validate against different snapshots or examples, so fields such as items versus line_items are dropped or misread. Source [5, 12, 34]Preconditions: Released folders edited after release; Examples do not match the schema.Impact: Wrong quantities or failed orders; inconsistent behavior across merchants.
Left to implementers
Pin a commit, validate against the JSON Schema, and test the docs-versus-spec differences explicitly.
R Repudiation
No proof of what the buyer approvedACP carries no signed user consent. After a dispute, neither merchant nor issuer can prove the buyer approved this purchase. Source [8, 13, 71]Preconditions: A buyer disputes an agent purchase.Impact: Chargeback outcomes depend on logs of the agent platform and merchant.
Left to implementers
Keep confirmation logs with session id, totals and timestamps; consider Verifiable Intent or AP2-style mandates outside ACP.
R Repudiation
Replayed checkout requestsRequest timestamps are only SHOULD, so a captured signed request may be replayed later if the server does not check freshness. Source [12]Preconditions: Attacker captures a request; Server skips Timestamp checks.Impact: Duplicate side effects where idempotency keys differ.
Partly
Check Timestamp freshness and keep idempotency keys at least 24 hours.
I Information disclosure
Card data exposure through direct Delegate PaymentPCI DSS Level 1 merchants and PSPs that host Delegate Payment receive raw card numbers and CVC. Source [22, 39]Preconditions: Logging of request bodies; Weak vault controls.Impact: Card data breach and PCI DSS findings.
Partly
Never log full card numbers or CVC; OpenAI may ask for an attestation of compliance before enabling production access.
I Information disclosure
Buyer data shared beyond needCheckout sends names, addresses, emails and risk signals such as IP address and device fingerprint to the merchant. Source [8, 34]Preconditions: Agent sends risk_signals and buyer fields by default.Impact: Over-sharing of personal data; consent and data protection exposure.
Partly
Send only the fields the merchant needs; OpenAI says it shares only what the order requires with the user's permission.
D Denial of service
Idempotency abuse and retry stormsClients retry with new keys or flood with in-flight duplicates, creating duplicate sessions or exhausting the merchant. Source [12]Preconditions: Client bugs or a malicious agent; No rate limits.Impact: Duplicate orders or degraded service.
Mitigated by spec
Require Idempotency-Key, return 409 with Retry-After for in-flight keys and 422 for changed bodies; rate limit per key and per agent.
E Elevation of privilege
Markdown or content injection into the agent interfaceA merchant message or line item description carries raw HTML or instructions that the agent renders or follows. Source [10, 12]Preconditions: Agent renders merchant content without sanitizing; Model reads merchant text as instructions.Impact: Interface spoofing or prompt injection steering the purchase.
Partly
Since 2026-04-17 markdown must be CommonMark without raw HTML; render with raw HTML disabled and treat merchant text as data, not instructions.
Preconditions: Agent bearer key leaks; Merchant accepts requests without signatures or IP allowlisting.
Attacker creates sessions with the leaked key
Attacker completes them with tokens from stolen cards issued elsewhere
Merchant ships goods
Impact: Fraud losses on the merchant, which is merchant of record.
Replayed webhook marks an order refunded Source [17]
Preconditions: Agent receiver checks the HMAC but not the timestamp window.
Attacker captures an old order_update with a refund adjustment
Attacker replays it hours later
Agent shows the buyer a second refund
Impact: Confusion and support cost; fixed by enforcing the 300-second tolerance.
Published research findings
A Formal Analysis of Agent Payment Protocols: Tamarin models of x402, MPP, ACP and AP2: 86 verification cases and 40 previously undocumented formal-consistency findings across the four protocols, not broken down by protocol in the abstract. (paper in section G) Source [53]
Protocol-Level Attacks on Agentic Commerce Platforms: Reports 33 structural vulnerabilities across three leading platforms; the abstract does not name ACP. (paper in section G) Source [73]
Building Trust in Autonomous Commerce: A Verifiable Global Event Timeline: Says protocols such as AP2 and ACP lack interoperable, tamper-evident audit trails. (paper in section G) Source [72]
CVEs and advisories
No CVE or advisory is recorded for this protocol as of the last verification.
ACP natively scopes a delegated token by amount, currency, merchant, session, single use and expiry, supports 3DS step-up and makes idempotency mandatory. It leaves agent identity, registration, user consent, revocation, reputation and disputes to platforms, PSPs or other protocols. The best places for an independent controls layer are the agent before it sets the allowance, the PSP when the token is charged, and the merchant edge where bearer keys and signatures are checked.
Bilateral bearer key plus a recommended detached Signature and Timestamp with algorithms agreed out of band; no agent identity scheme. Source [12, 20]
Agent registration (know your agent)
External
No registry in ACP. Each platform runs its own merchant and partner onboarding, such as ChatGPT's approved-partner application. Source [22, 74]
User consent capture
External
The buyer confirms in the agent interface (a product feature). The spec captures marketing consents and 3DS results but no signed purchase consent. Source [8, 34]
Spending caps
Native
allowance.max_amount and currency on every delegated token; Stripe SPT usage_limits.max_amount. Source [19, 26]
Merchant or payee scoping
Native
allowance.merchant_id and allowance.checkout_session_id bind the token to one merchant and one session. Source [19]
Time windows and expiry
Native
allowance.expires_at, session expires_at and the expired status. Source [19, 34]
Revocation
External
No revoke endpoint in ACP; Stripe SPTs can be revoked. Agents can cancel open sessions. Source [13, 26]
Mandatory Idempotency-Key on POST since 2026-04-17, one_time allowance, webhook timestamp window; request Timestamp checks only SHOULD. Source [12, 17, 19]
Receipts and evidence
Partial
Order with permalink_url and order_create and order_update webhooks; no signed receipt. Source [17, 34]
Dispute support
Partial
Order adjustments include refund, return and dispute; the merchant handles chargebacks as merchant of record; no dispute protocol. Source [22, 34]
No signed user consent. The allowance limits a token but nothing proves the buyer approved the purchase; disputes rely on platform logs. Source [13, 71]
No standard allowance errors. ACP defines no error codes for a charge outside the allowance, so declines differ by PSP. Source [19, 39]
Weak request authentication. Signatures are recommended on checkout and contradictory on Delegate Payment; freshness is a SHOULD. Source [12, 20, 39]
No revocation in the spec. A delegated token cannot be revoked through ACP; only vendor products such as Stripe SPT offer it. Source [26]
Where an independent controls layer can act
Before authorization
Decide whether the agent may buy and how much Policy on the agent platform that sets max_amount to the confirmed total and blocks categories or merchants. Source [19, 22]
At signing
Issue the delegated token The PSP validates the allowance, risk signals and the request signature before returning a vault token. Source [19, 39]
At the edge
Accept or reject the agent at the merchant API Bearer key checks, detached signature and timestamp checks, egress IP allowlisting, idempotency enforcement. Source [12, 22]
At settlement
Charge the token The merchant PSP enforces merchant_id, checkout_session_id, max_amount, currency, single use and expires_at. Source [19]
After the fact
Review orders and disputes Order webhooks with adjustments, intent traces on cancels, and platform confirmation logs. Source [17, 50]
Implementer checklist
Set allowance.max_amount to the total the buyer confirmed, not a padded value. The PSP will accept any charge inside the allowance. Source [19, 26]
Send an Idempotency-Key on every POST, including over MCP. Required in REST since 2026-04-17; the MCP binding still lets it be optional. Source [10, 15]
Require and verify the detached Signature and Timestamp. The spec only recommends them. Source [12]
Verify Merchant-Signature with a 300-second window and constant-time comparison. Prevents forged and replayed order events. Source [17]
Validate payloads against a pinned commit of the JSON Schema. Examples and released folders drift. Source [5, 34]
Never log full card numbers or CVC. Delegate Payment carries cardholder data in PCI DSS scope. Source [22, 39]
Render merchant markdown with raw HTML disabled. Required since 2026-04-17 and limits injection. Source [12]
Keep the buyer confirmation record with session id and totals. ACP has no signed consent for disputes. Source [8]
J. Compliance and regulation
Not legal advice. This is a study summary of public rules as of the dates cited. Ask counsel about your situation.
ACP keeps the regulated roles where they already are: the merchant is merchant of record and system of record for orders, payments, taxes and compliance, and the PSP handles card data. That makes card rules, PCI DSS, strong customer authentication and consumer-protection law apply much as they do to any card-not-present sale. The open questions are about the agent: whether a buyer confirmation in an AI interface counts as consent for liability rules, how AI transparency rules apply to the surface, and how much buyer data the agent passes on. Rows are dated; check each source before you rely on it.
Rules by topic and jurisdiction
Jurisdiction
What applies
Confidence
Consumer protection and liability
United States
The merchant is merchant of record and handles refunds and chargebacks. For card purchases, Regulation Z limits unauthorized use to use without actual, implied or apparent authority, capped at the lesser of $50 or the amount before notice; whether an agent acting outside the buyer's intent has apparent authority is untested. Source [22, 75]
Verified
United States
For debit cards, Regulation E excludes transfers by someone the consumer gave the access device to until the consumer gives notice, which may leave a buyer liable for an agent it equipped with a credential. Source [76]
Verified
United States
In Amazon v. Perplexity (Ninth Circuit, 2026-08-04) the court vacated an injunction against an agentic browser, reasoning on its record that the user, not the agent vendor, accesses the site. The holding is limited to that record. Source [77]
Verified
European Union
PSD2 bases payer liability on consent to the specific transaction. A buyer confirmation in an agent interface, without a signed record, is untested evidence of that consent. Source [13, 82]
Verified
European Union
PSD3 and the Payment Services Regulation reached provisional agreement but were not in the Official Journal in the latest sources found; they contain no agent-specific provisions. Source [86]
Reported
United Kingdom
The Payment Services Regulations 2017 treat a payment as authorized only with the payer's consent (regulation 67). HM Treasury consulted from 2026-07-14 to 2026-10-06 on how consent and liability should adapt for agentic payments. Source [87, 88]
Verified
Canada
No agent-specific payment liability rule was found. Stripe SPTs are available in Canada, and the Retail Payment Activities Act applies to payment service providers since 2025-09-08. Source [26, 91]
Unverified
Singapore
The MAS E-Payments User Protection Guidelines allocate liability for unauthorized e-payments. Stripe lists SPT availability for the US, Canada and listed European countries. Source [26, 93]
Verified
Card network rules
Visa and Mastercard had no public dispute or liability rule specific to agent-initiated transactions as of 2026-10-11; Worldpay says no liability shift exists yet. ACP card payments follow existing card rules. Source [95, 96]
Reported
AML and sanctions
United States
ACP has no KYC or sanctions layer. Screening sits with the merchant and its PSP, as in any card-not-present sale; OFAC obligations are unchanged. Source [13, 78]
Verified
Card network rules
EMVCo published a draft agentic payments framework on 2026-09-01 with Know Your Agent listed as possible future work; ACP itself has no agent registration. Source [13, 97]
Verified
Strong customer authentication
European Union
PSD2 SCA requires two factors and dynamic linking of amount and payee for remote payments. ACP's path is 3DS2 through authentication_required, Delegate Authentication and authentication_result; the spec names no regulation. Source [12, 24, 81]
Verified
United Kingdom
The FCA said on 2026-03-25 it will consider with HM Treasury whether rules must change for agentic AI payments; onshored SCA rules apply to ACP card payments as to any remote card payment. Source [89]
Verified
Card network rules
PCI DSS: OpenAI reserves direct Delegate Payment integration for PSPs and PCI DSS Level 1 merchants and may require an attestation of compliance; feed and checkout specs carry no cardholder data. Source [22]
Verified
AI-specific rules
United States
No federal statute governs AI shopping agents, and the CFPB has issued no AI-agent rule. Source [80]
Verified
United States
OpenAI's commerce policy excludes products such as adult content, alcohol, nicotine, gambling, weapons and prescription-only medicines from ChatGPT shopping; ACP itself has age_verification_required and region_restricted message codes. Source [22, 34]
Verified
European Union
AI Act Article 50 transparency applies from 2026-08-02: people must be told when they interact with an AI system, which concerns the agent surface, not the merchant API. Source [83, 84]
Verified
Singapore
MAS issued AI risk management guidelines on 2026-10-07, effective 2027-10-07, naming agentic AI systems. Source [94]
Verified
Data protection
United States
California's ADMT regulations under the CCPA apply from 2026-01-01. Checkout shares buyer contact data, addresses and optional risk signals such as IP address and device fingerprint with the merchant. Source [34, 79]
Verified
European Union
GDPR applies to buyer data passed in checkout and to marketing consent. ACP records opt-ins through marketing_consent_options and marketing_consents but does not name GDPR. Source [58, 85]
Verified
United Kingdom
The Data (Use and Access) Act 2025 amends UK GDPR rules on automated decision-making. Source [90]
Verified
Canada
PIPEDA governs the personal information merchants and agent platforms exchange in checkout. Source [92]
Verified
K. Observability lens
1 of 5 observability score
All checkout, Delegate Payment, webhook and feed traffic is bilateral HTTPS between agent, merchant and PSP; nothing is written to a public ledger.
The only standard public artifact per seller is the optional /.well-known/acp.json discovery document, which lists versions, transports and services but no volume.
There is no public registry or explorer of ACP merchants or agents, and the ACP site says discovery mechanisms were still being developed.
The project is transparent about the spec: the GitHub repository shows commits, SEPs, the CLA list and governance.
No official transaction volume, GMV or merchant count has been published.
Publicly observable
Public signals
What
Where
How
Seller discovery documents
https://<seller>/.well-known/acp.json
Unauthenticated GET; protocol.version, supported_versions, api_base_url, transports, capabilities.services; cacheable for at least an hour. Source [25, 34]
Checkout sessions, totals and buyer data. Bilateral REST or MCP calls between the agent and the merchant.
Delegated tokens and allowances. Held by the PSP or vault; ACP defines no token status or public log.
Order webhooks (order_create, order_update) and adjustments. Sent from merchant to agent over HTTPS with a shared HMAC secret.
Product feeds pushed to /feeds. Sent from merchant to agent; OpenAI uses its own /product_feeds paths.
Stripe SPT events. shared_payment.issued_token.* and shared_payment.granted_token.deactivated go only to the Stripe accounts involved.
What an indexer or monitor could capture
Which sellers support ACP and which versions from Crawling /.well-known/acp.json on known merchant domains: protocol.version, supported_versions, api_base_url, capabilities.services, transportsSource [25, 34]
Spec change velocity and governance moves from GitHub commits and pull requests, changelog folder, SIGNATORIES.md: commit sha, SEP number, spec folder date, CLA signatorySource [5, 7]
Order lifecycle for one platform (private monitor) from The agent platform's own webhook receiver at /agentic_checkout/webhooks/order_events: order id, checkout_session_id, event type order_create or order_update, adjustment typeSource [17]
Token lifecycle for one Stripe account (private monitor) from Stripe webhooks: shared_payment.issued_token.used, shared_payment.issued_token.deactivated, shared_payment.granted_token.deactivatedSource [26]
L. Ecosystem and adoption
Stewards
OpenAI: Founding maintainer, TSC seat 1; runs ChatGPT, the main ACP agent surface. Source [3, 4]
Stripe: Founding maintainer, TSC seat 2; co-developer; Shared Payment Token is the first compatible Delegate Payment implementation. Source [4, 22]
Meta: TSC seat 3 since 2026-04-24; CLA signed 2026-03-19. Source [4, 7]
Implementers and deployments
Implementers (11)
Name
Role
Status
ChatGPT product discovery (OpenAI)
Agent surface ingesting merchant feeds through ACP; Target, Sephora, Nordstrom, Lowe's, Best Buy, The Home Depot and Wayfair named on 2026-03-24. Source [14]
Live
ChatGPT apps external checkout (OpenAI)
Users finish on the merchant's own checkout; generally available. Source [37]
Stars on the specification repository. Source [11] Caveat: Interest, not adoption.
GitHub forks
253 forks
Forks of the specification repository. Source [11] Caveat: Interest, not adoption.
Corporate CLA signatories
10 organizations
Companies listed in legal/cla/SIGNATORIES.md, including OpenAI and Stripe. Source [7] Caveat: Signing a CLA does not mean a live integration.
TSC seats filled
3 of up to 7 seats
Organizations on the Technical Steering Committee. Source [4]
Commits after the 2026-04-17 release
18 commits
Commits on main from 2026-04-24 to 2026-07-18; none after. Source [5]
Retailers named as integrated into ACP for discovery
7 retailers
Named list in OpenAI's announcement. Source [14] Caveat: A named list, not a total count.
Shopify merchants selling through AI tools (ChatGPT, Gemini, Copilot)
around a dozen merchants
Remark attributed to Shopify's president at an investor conference. Source [35] Caveat: Reported through trade press; not a primary figure.
ChatGPT weekly users at launch
more than 700 million people per week
OpenAI's own figure in the launch post. Source [8] Caveat: Context only; not an ACP usage metric.
ACP transaction volume or GMV
not published n/a
No official volume, GMV or merchant count from OpenAI, Stripe or the project. Source [8, 14] Caveat: Absence of data.
Costs
Costs, who pays them, and how sure we are
Item
Value
Who pays
As of
Confidence and caveat
ChatGPT Instant Checkout platform fee
"A small fee on completed purchases"; no rate published Source [8]
Merchant
Verified OpenAI's own wording; free for users; whether it applies after the March 2026 change is not stated.
Reported fee for Shopify merchants on ChatGPT checkout sales
4 percent of the sale, on top of Shopify fees Source [67]
Merchant (Shopify)
Reported PYMNTS relaying The Information and a Shopify spokesperson; not published by OpenAI. The same report said Google and Microsoft charged no extra fee for now.
Shopify Agentic Storefronts channel fee
Set per channel in Shopify Admin; rate not public Source [98]
Merchant (Shopify)
Reported Secondary article; not checked against Shopify terms.
ACP protocol
No protocol fee; Apache-2.0; no fee for TSC or working group seats Source [4, 6]
Nobody
Verified Costs come from platforms and PSPs, not the spec.
Validate schemas and examples with the repository scriptsACP specification repository (no official SDK) 0.1.0 (package.json at commit 7fdd78d)Command linebash
git clone https://github.com/agentic-commerce-protocol/agentic-commerce-protocol.gitcd agentic-commerce-protocolpnpm install# compile every JSON Schema in every dated folderpnpm run validate:json-schema# check examples against the schemaspnpm run validate:all
ACP checkout state machine and allowance simulator: src/playgrounds/openai-acp/ (planned)
O. Playground
Fixture merchant with a checkout session state machine in two spec versions, allowance enforcement on delegated tokens, HMAC webhook verification, idempotency replay and conflict, and payment handler selection; simulation only, no real funds or cards.
Simulation, no real fundsFollows spec version 2026-04-17
Loading the simulation.
Keys are generated in this browser for this session only, on test chain identifiers or fixture data. No wallet connects and nothing is sent to a network.
P. Compare and compose
UCP is the closest sibling and the most misread relation. Both define a hosted by the merchant, five status names are identical, UCP says ready_for_complete where ACP says ready_for_payment, and each publishes a well-known discovery document (/.well-known/acp.json versus /.well-known/ucp).Source [25, 27, 34, 68] No bridge or mapping specification exists in either repository, and no source supports calling the two converging.Source [13, 27] Stripe supports both for sellers and sits on the UCP Tech Council while co-maintaining ACP.Source [3, 62, 69] Microsoft announced Copilot Checkout with ACP, while its later merchant page asks for a UCP-compliant feed.Source [66, 70]
Stripe’s is where ACP meets the card networks. It is Stripe’s product, not the ACP spec, with its own usage limits, statuses and revocation.Source [13, 22, 26, 34] Underneath, Stripe says it might use Visa Intelligent Commerce and Mastercard Agent Pay tokens, so those network programs can carry an ACP payment without ACP knowing.Source [26] Visa TAP has no documented link to ACP: TAP signs agent requests at the merchant edge, while ACP agents authenticate with bilateral bearer keys.Source [12]
AP2 answers the question ACP leaves open. ACP has no mandates and no signed proof of user intent beyond scoped tokens and the agent’s own confirmation screen.Source [8, 13] The Verifiable Intent project proposes carrying its credentials through ACP’s mechanism, which remains a proposal, not an adopted extension.Source [71]
Stripe MPP and x402 sit in a different lane. Stripe lists x402 with MPP for machine payments and ACP with UCP for selling through agents, and the shared piece is the SPT that MPP accepts for card payments.Source [22, 61, 62] ERC-8004 has no documented relation; mind the name clash with ERC-8183, an on-chain escrow standard that also calls itself the Agentic Commerce Protocol.Source [13, 33]
Relations to other protocols
Compatible withfrom Mastercard Agent Pay: Indirect: Stripe Shared Payment Tokens can carry Mastercard agentic network tokens, so an ACP checkout processed by Stripe can use one. ACP itself names Mastercard only as a card brand. Source [103, 104]
Compatible withAgentic Commerce Protocol (ACP) to Mastercard Agent Pay: No documented protocol link. Stripe says it might use Mastercard Agent Pay tokens under SPT card payments. Source [26]
Compatible withAgentic Commerce Protocol (ACP) to Visa Trusted Agent Protocol: No documented protocol link. Stripe says it might use Visa Intelligent Commerce tokens under SPT card payments, so Visa agent tokens can sit under an ACP payment. Source [26]
Competes withAgentic Commerce Protocol (ACP) to UCP: Both define merchant-hosted agent checkout sessions; five status names match and both publish well-known discovery documents, but no bridge or mapping exists. Stripe supports both. Source [13, 27, 62]
ComplementsAgentic Commerce Protocol (ACP) to AP2: ACP has no mandates or signed user intent; AP2 mandates or Verifiable Intent could add that layer, but no adopted extension exists. Source [13, 71]
Same stewardAgentic Commerce Protocol (ACP) to Stripe MPP (Machine Payments Protocol): Stripe co-maintains ACP and runs MPP; MPP accepts cards through the same Shared Payment Token family that implements ACP Delegate Payment. Source [22, 61]
Competes withfrom UCP: Both specify agent checkout with the merchant as merchant of record; no bridge or mapping is specified. Stripe co-develops ACP and sits on UCP councils. Source [108, 109, 110]
Complementsfrom Visa Trusted Agent Protocol: Visa says TAP complements ACP and Intelligent Commerce Connect accepts ACP payments; no wire-level binding is published. Source [111, 112]
Agentic Commerce Protocol (ACP) in the compare matrix (34 dimensions)
Dimension
Value
Confidence
Primary job
Agent checkout against a merchant-hosted API, with a scoped delegated card token The agent creates, updates and completes a checkout session; Delegate Payment swaps a card for a vault token bound by an allowance.Source [12, 39]
Verified
Layers covered
Checkout and orders, payment credential handoff, discovery and feeds, post-purchase order events No agent identity, reputation or user mandate layer.Source [10, 12]
Verified
Stewards
OpenAI and Stripe (founding maintainers); TSC: OpenAI, Stripe, Meta Meta joined 2026-04-24.Source [3, 4]
Verified
Governance model
Company-led TSC of up to 7 seats appointed by the founders; SEPs by simple majority; founders' block-only veto No foundation; one is a stated long-term goal.Source [4]
Verified
License (spec and code)
Apache-2.0 Contributions under a corporate or individual CLA.Source [6, 7]
Verified
First announced
2025-09-29 With ChatGPT Instant Checkout and Stripe SPTs.Source [8, 9]
Verified
Latest version and date
2026-04-17 (dated folder) No GitHub release or tag; folder edited after release (2026-05-01, 2026-06-15); last commit 2026-07-18.Source [5, 10]
Verified
Maturity
Beta spec, Draft RFCs; deployed for feeds in ChatGPT 2025 in-chat checkout scaled back in March 2026; payment sheet in private beta.Source [1, 14, 37]
Verified
Transports
REST over HTTPS, MCP binding (5 tools), webhooks, feed API and files MCP binding released in 2026-04-17.Source [12, 15, 18]
Verified
Settlement rails
Cards (FPAN or network token) through the merchant's PSP; seller-backed gift cards, points, store credit SPTs can carry Link, wallets, Klarna and Affirm on Stripe.Source [19, 21, 26]
Verified
Agent identity model
Bilateral bearer key per agent and merchant pair Detached Signature recommended; no registry or key directory.Source [12, 20]
Verified
User authorization model
Buyer confirms in the agent UI; token limited by an allowance No signed mandate or consent object.Source [8, 13, 19]
Verified
Human-present and human-not-present support
Human present Every flow assumes the buyer confirms in session; no delegated standing authority.Source [8, 19]
Verified
Merchant of record
The merchant OpenAI and PSPs are not merchant of record.Source [22]
Verified
Credential type
Single-use vault token (vt_) or Stripe SPT Network tokens can sit under SPTs.Source [19, 26]
Verified
Cryptography
TLS; HMAC-SHA256 webhooks; optional detached request signatures (Ed25519 or ES256 examples); 3DS2 Signature algorithms agreed out of band.Source [12, 17, 39]
Centralized per platform Each agent platform onboards merchants; founders control governance.Source [4, 22]
Verified
Observability score
1 of 5 Only discovery documents and the GitHub repository are public.Source [25, 74]
Verified
Fees and who pays them
No protocol fee; OpenAI charges merchants "a small fee" (rate unpublished); a 4 percent Shopify figure is reported only Merchant PSP fees unchanged; SPT pricing not published (public preview).Source [8, 26, 67]
Reported
Who pays (short)
Merchant pays platform fee Card economics otherwise unchanged.Source [8, 22]
MisconceptionIs ACP the same as IBM's Agent Communication Protocol?
No. This ACP is the Agentic Commerce Protocol from OpenAI and Stripe. IBM's Agent Communication Protocol merged into A2A under the Linux Foundation (announced 2025-08-29), and the PyPI package acp-sdk belongs to it. Many 2025 papers on MCP, ACP, A2A and ANP mean IBM's protocol. Source [28, 29, 30, 101]
MisconceptionIs ACP Virtuals' Agent Commerce Protocol, ERC-8183 or the Agent Client Protocol?
No. Virtuals' Agent Commerce Protocol is the commerce layer of its on-chain agent economy, ERC-8183 is an on-chain job escrow standard that also calls itself the Agentic Commerce Protocol, and the Agent Client Protocol connects code editors to agents. Source [31, 32, 33]
MisconceptionIs OpenAI the merchant of record when I buy through ChatGPT?
No. The merchant is merchant of record, its name appears on the card statement, and it handles refunds and chargebacks. ACP lets agents embed commerce without becoming the merchant of record. Source [1, 22]
MisconceptionIs the Shared Payment Token part of ACP?
No. ACP defines a generic Delegate Payment endpoint that returns a vault token. Stripe's SPT is a Stripe product that OpenAI calls the first compatible implementation; spt appears in the schema only as an example credential type. Source [22, 26, 34]
MisconceptionCan I still check out inside ChatGPT the way it launched in 2025?
Not in the 2025 form. On 2026-03-24 OpenAI said the first Instant Checkout lacked flexibility and let merchants use their own checkout. In ChatGPT apps, external checkout is generally available and the payment sheet is a private beta for select marketplace partners. A March 2026 report that it was moving to apps is secondary only, and no primary source gives a shutdown date. Source [14, 35, 37]
MisconceptionIs signing mandatory for Delegate Payment?
Only in one place. RFC section 2.2 says the client must sign; the same RFC's header list says recommended, and the OpenAPI file marks the Signature header optional. On checkout, signatures are recommended. Source [12, 20, 39]
Which version should I implement?
2026-04-17 is the latest dated folder. There are no GitHub releases or tags, and released folders were edited after release, so pin a commit and validate against its JSON Schema. Source [5, 10, 11]
MisconceptionWhy do the examples send items with a quantity when my validator rejects them?
Because the examples drifted. Since 2026-01-30 the schema requires line_items of Item objects without a quantity field. The RFC and OpenAPI examples still send items with id and quantity; the repository's examples file follows the schema. Source [12, 34, 38, 44, 45]
MisconceptionDoes ACP prove that the buyer approved a purchase?
No. ACP has no mandates or signed consent. The allowance limits what a token can do, and the buyer's confirmation lives in the agent interface. Source [8, 13]
MisconceptionAre ACP and UCP converging?
No source supports that. Both define merchant-hosted checkout sessions, five status names match, and each has a well-known discovery document, but no bridge or mapping exists. Stripe supports both. Source [13, 25, 27, 34, 62, 68]
What does selling through ChatGPT cost a merchant?
OpenAI said in 2025 that merchants pay a small fee on completed purchases and has not published a rate. A 4 percent figure for Shopify merchants is a secondary report only. ACP itself has no protocol fee, and the merchant's normal PSP fees apply. Source [6, 8, 22, 67]
Do the OpenAI docs and the ACP spec agree?
Not everywhere. They differ on feed paths, webhook event names, the completion status code, the idempotency conflict code and the TLS version. Use the spec for ACP and OpenAI's docs for what ChatGPT expects. Source [12, 17, 22, 38]
R. Open questions and research frontier
Will OpenAI and Stripe move ACP to a neutral foundation?
The governance document names a foundation as a long-term goal with four preconditions; today the founders appoint the TSC and hold a veto on SEPs. Source [4]
What do the six newer checkout statuses mean?
incomplete, requires_escalation, pending_approval, complete_in_progress and expired, plus authentication_required, appear in the schema; only authentication_required has behavior in the RFC text. Source [12, 34]
Who besides ChatGPT runs ACP checkout in production?
Microsoft, PayPal and Walmart made announcements, and Microsoft's later merchant page asks for UCP feeds. No primary source confirms live ACP checkout on another surface. Source [64, 66, 70]
Will the spec and OpenAI's implementation converge?
Feed paths, webhook names, status codes and TLS versions differ between the spec and OpenAI's docs, and nobody has said which side will change. Source [18, 22]
Will ACP get a user-intent layer?
The Verifiable Intent project proposes carrying its credentials through ACP extensions; the maintainers have not adopted it. Source [71]
How should PSPs report allowance violations?
ACP defines the allowance but no error codes for a charge outside it, so each PSP picks its own. Source [19, 39]
Is the repository still active?
No commit landed between 2026-07-18 and 2026-10-11, after 18 commits following the 2026-04-17 release. Source [5]
How much commerce runs over ACP?
No official volume, GMV or merchant count exists; the only figures are partner lists and a reported remark that about a dozen Shopify merchants sold through AI tools in March 2026. Source [14, 35]
S. Self-test
Quiz
0 of 10 answered.
Flashcards
0 of 15 marked known. Card 1 of 15.
Prompt
Allowance
T. Notes
Notes stay in this browser. Nothing is sent anywhere.