Skip to content
Sign in

Guide16 min readPublished

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.

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 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 under the Apache 2.0 licence, with a companion site at 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 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 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 and Stripe's agentic commerce documentation 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, 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 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, 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 to MerchantPOST /checkout_sessionsThe agent opens a checkout session. The checkout API is a merchant-implemented REST API.Source: ACP Agentic Checkout API, 2026-04-17
  2. Merchant to AgentSession and its statusIn 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
  3. Agent to MerchantPOST /checkout_sessions/{id}Each session has its own URL, which takes POST and GET.Source: ACP Agentic Checkout API, 2026-04-17
  4. Agent to Merchant's PSPPOST /agentic_commerce/delegate_paymentPer 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)
  5. Merchant's PSP to AgentVault 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)
  6. Agent to MerchantPOST /checkout_sessions/{id}/completeThe agent completes the session. A session can also be ended with POST …/cancel.Source: ACP Agentic Checkout API, 2026-04-17
  7. Merchant to Merchant's PSPProcess the paymentThe merchant processes the payment with its existing PSP.Source: OpenAI commerce docs: 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

Choose a status to see which documents list it and what they say about it.

Which documents list each status
StatusReleased fileDraft RFCOpenAI’s page
ListedNot listedNot listed
ListedListedListed
ListedNot listedNot listed
ListedNot listedNot listed
ListedListedListed
ListedNot listedNot listed
ListedNot listedNot listed
ListedListedListed
ListedListedListed
ListedListedNot listed
ListedNot listedNot listed

authentication_required

Listed in: Released file, 2026-04-17.

What a Draft document says

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) and ACP RFC: Delegate Authentication (Draft, 2026-01-28)

Sources: ACP Agentic Checkout API, 2026-04-17, ACP RFC: Agentic Checkout (Draft, 2026-01-16) and OpenAI commerce docs: checkout

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, 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:

{
  "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 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

Choose a field to see what it limits.

Example allowance. max_amount and currency are the file’s own example; the other values are made up for this figure.

max_amount

The most the token can pay, in minor units: 2000 is 20.00.

What the documents say

Required; amounts are in minor units. The file’s example is 2000.

Source: ACP Delegate Payment API, 2026-04-17

Try a charge against this allowance

Amount
Charged by
For checkout
When

Within the allowance: none of its limits stops this charge.

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)

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, 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 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 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 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, "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 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 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.

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 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 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".