Agentic Commerce Protocol: An OpenAPI Spec for Agent-Initiated Checkout
The Agentic Commerce Protocol (ACP) is an interaction model and open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly. The specification is currently maintained by OpenAI and Stripe.
At a glance
- What is it?
- ACP is a date-versioned specification, not a library, that defines how an AI agent negotiates capabilities, delegates payment, and hands a buyer to a merchant. It is maintained by OpenAI and Stripe and is still in beta, which shapes what you can safely build on today.
- Who is it for?
- Adopt ACP if you are a merchant, agent builder, or payment provider who needs a shared contract for agent-initiated checkout and can work against a beta specification with two reference implementations. Do not adopt it if you need a stable, frozen API surface today, because the repository marks the project as beta and keeps active development in spec/unreleased/.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 60 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 16, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Coordination Problem ACP Is Trying to Standardize
An AI agent that wants to buy something on a user's behalf has no default contract to follow. The agent does not know which payment methods a merchant accepts, whether the merchant can hold a cart across turns, or who is allowed to charge the card. Every integration becomes a bilateral negotiation. ACP exists to replace that with a published interaction model: the buyer's agent, the business, and the payment provider each implement the same OpenAPI surface and JSON Schema payloads, so the handshake is defined in advance. The README frames the audience in three parts. Businesses get a channel to high-intent buyers while, in its wording, using existing commerce infrastructure. Agents get to embed commerce without becoming the merchant of record. Payment providers get to move tokens between buyers and businesses through the agent. That last point is the load-bearing one: the agent is a conduit, not the seller, which is why the repository ships a separate delegate payment specification rather than folding payment into the checkout document.
RFCs, Snapshots, and the Date-Versioned Spec Directory
The repository is organized as a standards project rather than an SDK. Three artifact types coexist. The rfcs/ directory holds human-readable design documents with rationale and rollout plans, including rfc.agentic_checkout.md, rfc.capability_negotiation.md, rfc.payment_handlers.md, rfc.seller_backed_payment_handler.md, rfc.extensions.md, and rfc.discount_extension.md. The spec/ directory holds machine-readable snapshots, each in a YYYY-MM-DD folder, with OpenAPI YAML and JSON Schema subdirectories. The examples/ directory mirrors those dates with sample requests and responses. Versioning is by complete snapshot, not by semantic increment: the README states that each version represents the specification at a point in time, and that older versions remain available but are marked deprecated in the changelog. Development happens in spec/unreleased/ and is snapshotted to a dated folder when ready. The dated folders listed in the README run from 2025-09-29 (initial release) through 2025-12-12 (fulfillment enhancements), 2026-01-16 (capability negotiation), 2026-01-30 (extensions, discounts, payment handlers), and 2026-04-17 (cart, feed, orders, authentication, and MCP). That cadence is the clearest signal of the project's maturity stage: five snapshots in roughly seven months, with the newest one adding MCP alongside cart and order endpoints.
What the Checkout and Delegate Payment Specs Actually Cover
The documentation table points to two OpenAPI documents in spec/2026-04-17/openapi/: openapi.agentic_checkout.yaml and openapi.delegate_payment.yaml. The split matters. Checkout covers the cart-to-order path, and the 2026-04-17 snapshot name adds cart, feed, orders, and authentication to that surface. Delegate payment is the piece that lets an agent pass a payment token without holding the funds. Capability negotiation, introduced as its own snapshot on 2026-01-16, is the mechanism by which an agent and a merchant agree on what each side supports before the transaction proceeds; the extension and discount work landed on 2026-01-30. The repository does not publish a single monolithic schema. It publishes reusable JSON Schema definitions for payloads, events, and objects, which you are expected to validate against rather than transcribe by hand. If you are evaluating fit, read the RFC first for intent and the OpenAPI second for wire format. The RFCs are where the rationale lives; the YAML is where the constraints are.
Getting Started Without a Package to Install
There is no npm install step described in the README, and no client library is named. The stated path is: review the OpenAPI specs and JSON Schemas in spec/2026-04-17/, choose a reference implementation, follow the linked guides, and test against examples/2026-04-17/. The two reference implementations named are OpenAI's, documented at developers.openai.com/commerce/, and Stripe's, documented at docs.stripe.com/agentic-commerce. The README describes the choice plainly: use OpenAI's implementation to integrate with ChatGPT and other AI agent surfaces, or use Stripe's to use its payment and merchant tooling. That means your first real commands are git-based. Clone the repository, then read spec/2026-04-17/openapi/openapi.agentic_checkout.yaml alongside the matching files in examples/2026-04-17/ to see concrete request and response shapes. The configuration keys, endpoint paths, and required fields you will need are in those YAML and JSON files, not in the README, which is a navigation document rather than an integration guide.
The Beta Label and the unreleased Directory Are the Real Constraints
Two facts in the repository should govern your planning. First, the status badge reads Beta, and the README repeats that the specification is currently in beta. Second, active development lives in spec/unreleased/, and the README describes the lifecycle as unreleased, then snapshotted to a dated version, then deprecated in the changelog over time. A dated snapshot is therefore a freeze point, not a guarantee of stability across snapshots. If you build against 2026-04-17 and the next snapshot changes a payload shape, your integration follows the deprecation path rather than an automatic upgrade. This is the wrong tool if you need a frozen, versioned API contract with a long support window, or if your commerce stack has no path to either the OpenAI or Stripe implementation. It is also a poor fit if you want to be the merchant of record yourself, since the model explicitly positions the agent as a delegate rather than the seller. The repository gives no migration tooling for moving between snapshots; the changelog directory is documentation, not automation.
How ACP Differs From Writing to a Single Merchant's API
The obvious alternative is to integrate directly with one payment provider's or one merchant's own API. That approach gives you a single counterparty, a single set of credentials, and a support contract. The difference in approach is that ACP is counterparty-neutral by design: the same checkout and delegate payment schemas are meant to be implemented by many businesses, with capability negotiation handling the variance between them instead of you writing per-merchant branches. The cost is that you inherit the specification's release cadence and its beta status. A direct integration has no capability negotiation layer because there is nothing to negotiate with one provider. ACP's extension and discount RFCs exist precisely because a shared surface needs a formal way to add optional behavior without forking the core. If your roadmap is one merchant and one payment rail, the direct integration is simpler. If your roadmap is an agent that must transact across many businesses without bespoke code per business, the negotiation and extension machinery is the part you cannot easily rebuild yourself.
Governance, the CLA, and What Contribution Costs
Maintenance is shared between OpenAI and Stripe, per MAINTAINERS.md and the README. Contributions run through two pull request templates: one for SEP proposals covering major protocol changes, breaking changes, or process changes, and one for minor improvements covering documentation, bug fixes, and tooling. The docs/ directory holds governance.md, principles-mission.md, and sep-guidelines.md, and the README directs you to governance.md to determine what requires a SEP. Every contributor must sign a Contributor License Agreement before a contribution is accepted. Individual contributors sign through CLA Assistant automatically on their first pull request; corporate contributors follow the process in legal/cla/CORPORATE.md, with signatories tracked in legal/cla/SIGNATORIES.md. For a company that wants to influence the specification rather than only consume it, the corporate CLA is the gate to clear early, because it is a precondition rather than a formality you can file after the fact. The project is licensed under Apache-2.0, which is a permissive licence, but this article is not legal advice and your counsel should review the CLA terms alongside it.
Who Should Track This Repository Now
The honest read is that ACP is infrastructure for a market that is still forming, and the repository reflects that. Five dated snapshots, a beta badge, and an unreleased directory mean the specification is moving faster than most production integration cycles. That is not a reason to ignore it. If you are a payment provider deciding whether agent-initiated transactions will need a token delegation flow, the delegate payment OpenAPI document is the concrete artifact to study. If you are a merchant with an existing commerce backend, the question to answer first is whether the 2026-04-17 checkout surface maps onto your cart and order models, which you can check by reading the OpenAPI and JSON Schema files directly rather than by reading the README. If you are an agent developer, the capability negotiation RFC from the 2026-01-16 snapshot tells you what the handshake assumes about your side. The repository will not tell you whether to adopt it. It gives you the schemas, the changelog trail, and two reference implementations to test against, and the decision rests on how much specification churn your integration can absorb.
Editorial conclusion
Adopt ACP if you are a merchant, agent builder, or payment provider who needs a shared contract for agent-initiated checkout and can work against a beta specification with two reference implementations. Do not adopt it if you need a stable, frozen API surface today, because the repository marks the project as beta and keeps active development in spec/unreleased/. Before writing code, read spec/2026-04-17/openapi/openapi.agentic_checkout.yaml and openapi.delegate_payment.yaml, then diff them against spec/unreleased/ to see what is already moving.
Community notes