ACPAgentic Commerce Protocol
ACP is two specifications wearing one name. The checkout half is a commerce integration; the delegated payment half is the part that concerns authority, and it is deliberately minimal.
What it is
ACP is an interaction model and open standard connecting buyers, their agents, and businesses, published under Apache 2.0 and maintained by OpenAI and Stripe with a stated path towards neutral stewardship. It shipped alongside Instant Checkout in ChatGPT in September 2025 and has been revised on a date-versioned cadence since.
It comprises two OpenAPI specifications. The agentic checkout API defines how an agent creates and updates a checkout session against a merchant and completes it. The delegate payment API defines how a buyer's payment provider issues a scoped credential the agent can present, so the merchant is paid without the agent ever holding the buyer's card.
| Licence | Apache 2.0 |
|---|---|
| Versioning | Date-based snapshots: 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30, 2026-04-17 |
| Specifications | Agentic Checkout API; Delegate Payment API |
| Maintainers | OpenAI and Stripe, founding maintainers |
| Status | Beta |
What the delegated payment half actually does
The delegated payment specification replaces a stored card with a token minted for a transaction: bound to a merchant, an amount, and a short expiry. If the token leaks, what leaks is the ability to charge one merchant one amount for a short time — a real and worthwhile reduction in blast radius compared with a card on file.
It is worth being precise about what such a token can and cannot say. It can say how much. It cannot say why, or for what purpose, or under what circumstances the buyer would have wanted to be asked first. It carries no notion of budget consumed to date, no counterparty history, no operating hours, and no escalation path. Those are not oversights; they are outside the specification's scope. But it means a shared payment token is a containment mechanism, not an authority model — and a firm that treats it as the latter has bounded a single transaction while leaving the sequence of transactions unbounded.
How it has changed
The revision history is a good proxy for where agentic commerce is actually hard. Fulfilment came first, in December 2025, because a purchase that cannot report its own delivery state is not a purchase a merchant can support. Capability negotiation followed in January 2026 — agents and merchants needed to agree what each could do before attempting a checkout, rather than failing halfway. Later that month came extensions, discounts and pluggable payment handlers, loosening the original coupling to one provider. April 2026 added carts, product feeds, orders, authentication and MCP compatibility.
Read as a sequence, ACP has grown from 'complete a purchase' towards 'run the merchant relationship'. That raises the value of integrating it and raises the stakes on the authorisation underneath, which has not grown at the same rate.
What it does not do
- Scoped to the buyer-merchant-agent triangle. Business-to-business payment, invoice settlement and treasury movement are out of scope.
- The delegated payment token expresses an amount and a scope, not a policy: no purpose, no cumulative budget, no counterparty rules, no escalation.
- Beta, with date-versioned snapshots and no compatibility guarantee across them.
- Governance is two commercial firms with a stated intention to move to a foundation. That intention is not yet a foundation.
Where mnd8t sits relative to it
Adjacent, and largely orthogonal. ACP governs the conversation between an agent and a merchant. mnd8t governs whether the agent should be having it: a proposal is evaluated against the mandate before a checkout is created, and the decision plus its reasons are retained as verifiable evidence. Where an ACP token bounds one transaction, a mandate bounds the pattern of transactions.
Last reviewed 8 September 2026. Corrections: hello@mnd8t.com.