# ACP explained The Agentic Commerce Protocol: the checkout session a store implements, the delegated payment token with its limits, and how the merchant stays merchant of record. By Valerii Checha, 17 Oct 2026 When an AI agent buys something for a shopper, two things have to reach the store: an order and a way to pay for it. The Agentic Commerce Protocol (ACP) is a specification for both. It defines a set of endpoints, web addresses that a store's software answers, so that an agent can open a checkout, change it and complete it, and a separate endpoint that turns a card into a token limited by amount, expiry and merchant. This article goes through what the released specification says: who maintains it, how a checkout session moves, what delegated payment does and what the documents leave open about it, and where Stripe's Shared Payment Tokens fit. Where this article explains a general term in plain words, such as tokenizing or 3-D Secure, the explanation is ours, not the specification's. Definitions quoted from the ACP documents are collected at the end. If you are new to the series, [the hub article](https://storewalk.ai/blog/why-agents-cant-buy) explains why agents fail on most stores today. ACP is about two of those failures: getting through checkout, and paying on someone's behalf. ## What ACP is and who maintains it ACP is published as a [public GitHub repository](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) under the Apache 2.0 licence, with a companion site at [agenticcommerce.dev](https://www.agenticcommerce.dev/). The repository's README calls it "an interaction model and open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly". The sources do not agree on who maintains it. The repository's [MAINTAINERS.md](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md) lists three lead maintainers: OpenAI, Stripe and Meta. The README in the same repository says the specification is maintained by OpenAI and Stripe, and its badge reads "Maintained by OpenAI & Stripe". agenticcommerce.dev says "Stripe and OpenAI developed the Agentic Commerce Protocol". Stripe's own [ACP page](https://docs.stripe.com/agentic-commerce/acp) calls it "an open standard created by Stripe, OpenAI, and Meta". Meta is in the maintainers file and on Stripe's page, but not in the README or on the protocol's site. We go by the maintainers file and say ACP is maintained by OpenAI, Stripe and Meta, without saying who created it. On governance, the README says ACP "is jointly governed by OpenAI and Stripe as Founding Maintainers" and gives its future path as "Neutral foundation stewardship as ecosystem matures". It also says ACP was "first implemented by both OpenAI and Stripe", and points to [OpenAI's commerce documentation](https://developers.openai.com/commerce/) and [Stripe's agentic commerce documentation](https://docs.stripe.com/agentic-commerce) as the two reference implementations. ## The problem ACP is meant to solve The README states what each party gets, in the three lines quoted below. In plain terms, the merchant of record named in the second line is the party that sells to the buyer and is responsible for the sale. A payment provider is a company that processes a store's payments, and the ACP documents call it the PSP, for payment service provider. - For businesses: "Sell to high-intent buyers by making your products and services available for purchase through AI agents—all while using your existing commerce infrastructure." - For AI agents: "Let your users discover and transact directly with businesses in your application, without being the merchant of record." - For payment providers: "Process agentic transactions by passing secure payment tokens between buyers and businesses through AI agents." In our words, not the specification's: an agent wants to place an order with a store without becoming the merchant of record. The store wants to keep the systems it already runs. And the buyer's payment details have to reach the store's PSP by way of the agent. ACP's checkout endpoints address the first two needs, and its delegated payment endpoint the third. ## The checkout session, step by step The [Agentic Checkout API](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml), at version `2026-04-17`, describes itself as a "Merchant-implemented REST API for ChatGPT-driven checkout". This is an OpenAPI file, the machine-readable definition of the endpoints. The documents call the store the merchant, and some call it the seller. A REST API is a set of endpoints in which each address stands for a thing, such as one checkout session, and the request method says what to do with it: `GET` reads it, `POST` creates or changes it. The merchant implements the endpoints and the agent calls them. [OpenAI's checkout page](https://developers.openai.com/commerce/specs/checkout) marks create, update and complete as "Call direction: OpenAI -> Merchant". A checkout session is one attempt to buy one basket. The file defines five operations on it: - Create, `POST /checkout_sessions`: "Initializes a new checkout session from items and (optionally) buyer and fulfillment info." The merchant "MUST return 201 with a rich, authoritative cart state". - Update, `POST /checkout_sessions/{id}`, where `{id}` is the session's identifier: "Applies changes (items, fulfillment address, fulfillment option) and returns an updated authoritative cart state." - Retrieve, `GET` on the same address: "Returns the latest authoritative state for the checkout session." - Complete, `POST …/complete`: "Finalizes the checkout by applying a payment method. MUST create an order and return completed state on success." - Cancel, `POST …/cancel`: "Cancels a session if not already completed or canceled." The word "authoritative" recurs in these descriptions. The [Agentic Checkout RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md), one of the repository's design documents, gives the goal as "Ensure ChatGPT renders an authoritative cart state on every response." In our reading, the basket, prices and totals the agent shows are the ones your store returned. In steps 4 and 5 of the figure below, the agent obtains a vault token, which in plain terms is a stand-in value used in place of the card details. The draft RFC also calls it an SPT, Stripe's term for a shared payment token. An ACP checkout, message by message. 1. Agent → Merchant: POST /checkout_sessions. The agent opens a checkout session. The checkout API is a merchant-implemented REST API. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). 2. Merchant → Agent: Session and its status. In the 2026-04-17 spec a session status is one of incomplete, not_ready_for_payment, requires_escalation, authentication_required, ready_for_payment, pending_approval, complete_in_progress, completed, canceled, in_progress or expired. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). 3. Agent → Merchant: POST /checkout_sessions/{id}. Each session has its own URL, which takes POST and GET. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). 4. Agent → Merchant's PSP: POST /agentic_commerce/delegate_payment. Per the draft Payment Handlers RFC, the agent calls delegate_payment with the seller’s PSP, before checkout completion. The RFC does not place the call relative to Update. Source: [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md). 5. Merchant's PSP → Agent: Vault token (SPT). Per the same draft RFC, the PSP creates a vault token (SPT) scoped to the seller’s merchant account, and the agent submits it to the seller. Source: [ACP RFC: Payment Handlers (Draft, 2026-01-22)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md). 6. Agent → Merchant: POST /checkout_sessions/{id}/complete. The agent completes the session. A session can also be ended with POST …/cancel. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). 7. Merchant → Merchant's PSP: Process the payment. The merchant processes the payment with its existing PSP. Source: [OpenAI commerce docs: checkout](https://developers.openai.com/commerce/specs/checkout). Steps 4 and 5, the delegated payment call, come from a draft RFC rather than the released file. The delegated payment section below explains the difference. Every request carries a few required headers. `Authorization` holds a bearer token, an API key the agent presents to your store. `API-Version` names the protocol version the agent is using. An `Idempotency-Key` "MUST be present on all POST requests". In our words, it is a label that lets the store recognise a retried request as a repeat. ### What a session carries A session response must include its `id`, `status`, `currency`, `line_items`, `totals`, `fulfillment_options`, `messages`, `links` and `capabilities`. Among the optional fields are `expires_at`, the time the session expires, and `continue_url`, whose description reads "URL to continue or resume the checkout session". `messages` carries info, warnings and errors for the buyer. An error message lets your store report a problem without failing the whole request. The file describes it as a "Business-logic error within a valid CheckoutSession response", gives an invalid email address and an out-of-stock item as examples, and adds: "The agent can respond by asking the buyer for corrections or trying alternatives." Its codes include `missing`, `invalid` and `out_of_stock`. The checkout RFC adds an optional `resolution` that says who has to fix it: - `recoverable`: "Agent can fix via API". - `requires_buyer_input`: "Buyer must provide information the API cannot collect programmatically". - `requires_buyer_review`: "Buyer must authorize before order placement". ### Statuses The `2026-04-17` file lists eleven statuses, shown in step 2 of the figure, and gives them one shared description: "Current status of the checkout session". It does not describe each value on its own. The checkout RFC, labelled Draft at version `2026-01-16`, lists five: `not_ready_for_payment`, `ready_for_payment`, `completed`, `canceled` and `in_progress`. OpenAI's checkout page lists four and shows an example `API-Version` of `2025-09-12`. OpenAI's page has not caught up with the released file, so this article cites the file. ACP checkout session statuses, and which documents describe them. | Status | Released file, 2026-04-17 | Checkout RFC, Draft 2026-01-16 | OpenAI’s checkout page | | ----------------------- | ------------------------- | ------------------------------ | ---------------------- | | incomplete | Listed | Not listed | Not listed | | not_ready_for_payment | Listed | Listed | Listed | | requires_escalation | Listed | Not listed | Not listed | | authentication_required | Listed | Not listed | Not listed | | ready_for_payment | Listed | Listed | Listed | | pending_approval | Listed | Not listed | Not listed | | complete_in_progress | Listed | Not listed | Not listed | | completed | Listed | Listed | Listed | | canceled | Listed | Listed | Listed | | in_progress | Listed | Listed | Not listed | | expired | Listed | Not listed | Not listed | The lists come from: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml), [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md) and [OpenAI commerce docs: checkout](https://developers.openai.com/commerce/specs/checkout). Rules the documents attach to a status: - authentication_required (a Draft document): The store “MUST set session.status to authentication_required when authentication (e.g., 3DS) is required”. The agent then returns the result with Complete, “regardless of the authentication outcome”. Sources: [ACP RFC: Agentic Checkout (Draft, 2026-01-16)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md) and [ACP RFC: Delegate Authentication (Draft, 2026-01-28)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md). - completed (the released file): Complete “MUST create an order and return completed state on success”. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). - canceled (the released file): Cancel “Cancels a session if not already completed or canceled.” Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). The other statuses have no description of their own in any document cited here. The released file gives all eleven one description: “Current status of the checkout session”. Source: [ACP Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml). One status has a rule attached in the RFC. The store "MUST set `session.status` to `authentication_required` when authentication (e.g., 3DS) is required". 3DS, or 3-D Secure, is the check in which the card's bank asks the cardholder to confirm a payment. The agent must then attempt authentication and return the result in its Complete request, "regardless of the authentication outcome". When Complete succeeds, the response must carry `status: completed` and an `order` with an `id`, the `checkout_session_id` and a `permalink_url`. The RFC also requires order updates (`order_create`, `order_update`) to be sent to "the application's webhook receiver", an address that accepts event notifications. Those are defined in a separate webhooks specification. ## Delegated payment The Complete request must contain `payment_data`. In the released file, that names a payment handler and an instrument whose credential has a `type` and a `token`, and the schema also allows a purchase order number in their place. For card handlers that require it, delegated payment is how the agent gets that token. The [Delegate Payment API](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml), at the same version, defines one endpoint, `POST /agentic_commerce/delegate_payment`. It "Tokenizes a credential for controlled usage by the merchant's PSP per the **Allowance** constraints". Tokenizing means replacing the card details with a stand-in value. "Exactly one credential type is currently supported: **card**." The card can be sent as a raw card number (`fpan`) or as a network token, a substitute card number issued through the card network. The allowance is the set of limits. All six of its fields are required: ```json { "reason": "one_time", "max_amount": 2000, "currency": "usd", "checkout_session_id": "csn_01HV3P3...", "merchant_id": "acme", "expires_at": "2025-10-09T07:20:50.52Z" } ``` This is the example from the file, with amounts in minor units, so `2000` is $20.00. `reason` is "currently only one_time". `merchant_id` is the "merchant authorized to use this token". The [Delegate Payment RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md) says the token "MUST ONLY be usable within the provided Allowance" and "MUST become invalid at or after `allowance.expires_at`". The request also carries at least one risk signal, which the file describes as a "Fraud detection signal indicating detected risk patterns and recommended actions". Each has the type `card_testing` (card testing is fraud in which someone tries stolen card numbers to find the ones that work), a score ("Risk score indicating severity level") and a recommended action: `blocked`, `manual_review` or `authorized`. The response is the vault token, with an id beginning `vt_`. Try a charge against an example allowance to see how the limits work together. The limits on an ACP delegated payment token. Example allowance. max_amount and currency are the file’s own example; the other values are made up for this figure. ```json { "reason": "one_time", "max_amount": 2000, "currency": "usd", "checkout_session_id": "cs_example_1", "merchant_id": "example-store", "expires_at": "2026-11-01T12:00:00Z" } ``` - reason: Why the token exists. There is one value today. Its usage is “currently only one_time”. Source: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml). - max_amount: The most the token can pay, in minor units: 2000 is 20.00. Required; amounts are in minor units. The file’s example is 2000. Source: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml). - currency: The currency that amount is in. Required. The file’s example is usd. Source: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml). - checkout_session_id: The one checkout session the token is for. Required. Source: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml). - merchant_id: The one merchant that may use the token. Required: the “Unique identifier for the merchant authorized to use this token”. Source: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml). - expires_at: When the token stops working. The token “MUST become invalid at or after allowance.expires_at” (Draft RFC). Sources: [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml) and [ACP RFC: Delegate Payment (Draft, 2025-09-29)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md). The Delegate Payment RFC, a Draft, says the token “MUST ONLY be usable within the provided Allowance” and “MUST become invalid at or after allowance.expires_at”. Which limit a charge breaks is our reading of that rule. Source: [ACP RFC: Delegate Payment (Draft, 2025-09-29)](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md). On the page you can try a charge of 15.00 usd by example-store for cs_example_1 before expires_at, and change one thing at a time: | Charge | Result | | --------------------------- | ------------------------------------------------------------------------------------------ | | As set | Within the allowance: none of its limits stops this charge. | | 25.00 usd | Outside the allowance (max_amount): the token must not be usable for this charge. | | charged by another merchant | Outside the allowance (merchant_id): the token must not be usable for this charge. | | for another session | Outside the allowance (checkout_session_id): the token must not be usable for this charge. | | at or after expires_at | Outside the allowance (expires_at): the token must not be usable for this charge. | ### Who calls it, and who answers In their rules, the OpenAPI file and the Delegate Payment RFC (labelled Draft, version `2025-09-29`) call the two sides client and server. The RFC's goals mention "ChatGPT-initiated checkouts" and the file's example `User-Agent` is `ChatGPT/2.0`, but neither document says who sends the request or who hosts the endpoint. The file's one server address is the placeholder `merchant.example.com`, the same placeholder the checkout file uses. The [Payment Handlers RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md), labelled Draft at version `2026-01-22`, is more specific. Its credential vaulting flow reads: 1. "Agent sees handler has `psp: "stripe"` and `merchant_id: "acct_1234567890"`" 2. "Agent calls `delegate_payment` with the Seller's PSP (Stripe) using the merchant_id" 3. "PSP (Stripe) creates vault token (SPT) scoped to the Seller's merchant account" 4. "Agent submits SPT to Seller" 5. "Seller unwraps and uses the SPT with their PSP (Stripe)" As that draft is written, the agent makes the call and the store's PSP answers it, and steps 4 and 5 of the figure follow it. The released OpenAPI file does not say so itself. ACP's [MCP binding document](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/mcp-binding.md) also puts the endpoint with the payment provider. It describes the Delegate Payment API as one "that agents use to obtain payment tokens from payment providers", and as "a separate API surface served by a different party (payment provider, not merchant)". The `2026-04-17` [changelog](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/changelog/2026-04-17.md) lists that document. The release added a binding for the Model Context Protocol (MCP), which an AI application uses to call tools that other software offers, and the changelog records it as "Model Context Protocol (MCP) transport binding for ACP checkout operations": five MCP tools, each mapped to one checkout endpoint. The binding covers checkout only, and its document says delegated payment "should be addressed in a follow-up". ### Payment handlers A session's `capabilities.payment.handlers` lists the payment handlers the store accepts. Each handler declares, among other fields, `psp` (the provider), `requires_pci_compliance` ("Whether this handler routes PCI DSS sensitive data"; PCI DSS is the security standard for handling card data) and `requires_delegate_payment` ("Whether this handler requires using delegate_payment API"). The Payment Handlers RFC says the `psp` field "tells Agents which PSP the Seller uses". The Payment Handlers RFC sets the order for the delegated case. When `requires_delegate_payment` is true, the "Agent **MUST** call `/agentic_commerce/delegate_payment` before checkout completion", puts the vault token in the payment instrument's credential, and the "Seller uses vault token with their PSP to charge payment". The RFC recommends that "Handlers SHOULD set `requires_delegate_payment: true`". Its handler discovery flow lists the steps in order: the agent creates a checkout session, the seller's response lists the payment handlers, the agent obtains a credential and calls `delegate_payment`, it submits the token as payment, and the seller processes the payment. Update is not part of that flow, which is why step 4 of the figure says the RFC does not place the call relative to Update. ## How the merchant stays merchant of record agenticcommerce.dev puts ACP's position in one line: "businesses maintain their customer relationships as the merchant of record". The README says the same from the agent's side: agents transact "without being the merchant of record". The checkout RFC uses a related term. It says "The merchant remains the **system of record** for all orders, payments, taxes, and compliance", that "Orders are processed entirely on the merchant's existing commerce stack", and that "Payment authorization and settlement continue to occur via the merchant's PSP." OpenAI's checkout page says: "You process payment with your existing PSP; if using Delegated Payments, accept the token and apply your normal authorization/capture flow." So the agent sends the basket and a token, and your store creates the order and charges the payment through your own provider. [UCP](https://storewalk.ai/blog/ucp-explained) also keeps the store as merchant of record but arranges things differently. A UCP business publishes a profile at `/.well-known/ucp` for agents to find. ACP's discovery file is still a proposal, covered below. UCP's Update is a "full replacement of the checkout resource", while ACP's Update "Applies changes (items, fulfillment address, fulfillment option)". The status names differ too: UCP has `ready_for_complete` where ACP has `ready_for_payment`. ## Stripe Shared Payment Tokens The Payment Handlers RFC calls the vault token an SPT in its examples, and the checkout file's Complete example sends `token: spt_123` with `provider: stripe`. SPT is Stripe's term. On [Stripe's own documentation](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens), "SPTs grant sellers scoped access to customers' payment methods for agent-initiated purchases". They are available in the US, Canada and listed European countries. Stripe's seller page draws the flow this way. The customer gives a payment method to the agent. The agent issues an SPT through Stripe and sends it to the seller. The seller creates a payment with the SPT through Stripe, and Stripe processes the transaction. On the agent's side, the endpoint is `POST /v1/shared_payment/issued_tokens`, with `usage_limits` for currency, maximum amount and expiry. Stripe says "The agent sets the maximum amount to match the total amount of the transaction." The agent can revoke a token. As a seller, you can do one of two things with the token. You can charge it with Stripe by creating a PaymentIntent (Stripe's object for one payment) that carries the token in its `shared_payment_granted_token` field. Or you can call Stripe's resolve endpoint once to "retrieve network credentials and submit them to your payment processor", when that processor is not Stripe. Network credentials here are card details or a token standing in for them. "You can only resolve an SPT one time." A token's states are `active`, `requires_action` and `deactivated`, and `deactivated` is final. SPTs are in preview: the terms are the "Stripe Agentic Commerce Seller Services preview", and every example sends `Stripe-Version: 2026-09-30.preview`. Stripe's SPT pages, in both the seller and the agent version, do not mention ACP or `delegate_payment`; the connection is in the ACP documents' examples. [How an agent pays without seeing your card](https://storewalk.ai/blog/how-agents-pay) is planned to cover tokens across providers. ## What this means for your store today Unlike UCP, ACP gives you no file to open to see whether your store supports it. The discovery file, `/.well-known/acp.json`, is not part of the released specification. It appears only in a [discovery RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.discovery.md) marked "Status: Proposal" and "Version: unreleased". So you have to ask. On a hosted platform, ask the platform. On a custom build, ask whoever maintains your checkout, and ask your payment provider. Each of these questions points at a named field or endpoint in the specification: - Do you implement the ACP checkout endpoints for my store, and which `API-Version` do they accept? - Which payment handlers does a session list, and which `psp` does each name? - Does the handler set `requires_delegate_payment`, and does my PSP accept delegated tokens? - When 3-D Secure is needed, does my checkout set `authentication_required` and return the authentication metadata? - Where do order webhooks go, and does the order's `permalink_url` point to my store? We do not list which platforms or stores support ACP. None of the sources this article uses publishes such a list. ## What is not settled yet ACP is versioned by date. The README marks `2026-04-17` as the "Latest Stable" version, and labels the specification as a whole `beta`. There are five dated versions, from `2025-09-29` to `2026-04-17`, and a further `unreleased` folder for current work. The three RFCs this article cites for the endpoints are each labelled Draft, and the discovery RFC is a Proposal. Several questions stay open in the published text: - Who maintains ACP: the maintainers file lists Meta, and the README and agenticcommerce.dev do not. - Who hosts `delegate_payment`: the released OpenAPI file does not name the caller or the host. The draft Payment Handlers RFC names both, and the MCP binding document says the endpoint is "served by a different party (payment provider, not merchant)". - What each of the eleven statuses means: the released file gives them one shared description. - Delegated payment covers one credential type, card, and one allowance reason, `one_time`. - OpenAI's checkout page lags the released file, so two official sources show different status lists. - Stripe's SPTs, the token the ACP examples use, are a preview product. The sources below were last checked on the date shown, and this article will be updated in place when the specification moves. For how ACP sits next to UCP, MCP and AP2, read [UCP vs ACP vs MCP vs AP2](https://storewalk.ai/blog/ucp-vs-acp-vs-mcp-vs-ap2). ## Terms as the documents define them Three terms appear throughout, and the documents named in each entry define them. Each quotation comes from the document named in its entry. - Merchant, seller, business: the [Payment Handlers RFC](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md) treats the three words as one party, the "Party accepting payment". - PSP: in the same RFC, "Payment Service Provider", a "Service processing payment transactions (e.g., Stripe, Adyen)". - RFC and OpenAPI file: the [README](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) describes an RFC as a "Human-readable design doc with rationale, flows, and rollout plan" and the OpenAPI files as a "Machine-readable HTTP API spec for integrating checkout endpoints". ## Sources - [ACP repository and README](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol) - [ACP MAINTAINERS.md](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md) - [agenticcommerce.dev](https://www.agenticcommerce.dev/) - [Agentic Checkout API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml) - [ACP Delegate Payment API, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.delegate_payment.yaml) - [ACP RFC: Agentic Checkout](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md) - [ACP RFC: Delegate Payment API](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md) - [ACP RFC: Payment Handlers](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.payment_handlers.md) - [ACP RFC: Discovery](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.discovery.md) - [OpenAI commerce docs: checkout](https://developers.openai.com/commerce/specs/checkout) - [OpenAI commerce docs](https://developers.openai.com/commerce/) - [ACP: MCP transport binding for Agentic Checkout](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/mcp-binding.md) - [ACP changelog, 2026-04-17](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/changelog/2026-04-17.md) - [Stripe docs: Agentic Commerce Protocol](https://docs.stripe.com/agentic-commerce/acp) - [Stripe docs: agentic commerce](https://docs.stripe.com/agentic-commerce) - [Stripe docs: Shared payment tokens](https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens) - [ACP RFC: Delegate Authentication](https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md) - [UCP specification overview](https://ucp.dev/latest/specification/overview/) - [UCP checkout capability](https://ucp.dev/latest/specification/shopping/checkout/) Last checked 22 Oct 2026