Home » Free ACP Payments Module » What Is ACP

What Is the Agentic Commerce Protocol (ACP)?

The Agentic Commerce Protocol (ACP) is an open specification, published by OpenAI with payment support from Stripe, that defines how AI agents complete purchases with merchants. It standardizes three things: a checkout session API that the agent platform calls on the merchant (create, update, complete, cancel), a delegated payment flow built on scoped Shared Payment Tokens, and a product feed format that tells agents what a merchant sells. A merchant that implements ACP can sell inside AI assistants like ChatGPT directly, instead of hoping the assistant links to their website.

The Problem ACP Solves

AI assistants have become a real surface where buying decisions happen. People ask an assistant to find a tool, compare plans, or pick a product, and until recently the best possible outcome for a merchant was a link. The human still had to leave the conversation, land on a website, navigate a checkout built for browsers, and re-enter intent the assistant already knew. Every step in that handoff loses buyers, which is the same funnel problem documented across checkout optimization work for years, made worse because the context switch is total.

The deeper issue is that there was no standard contract between agent platforms and merchants. An assistant cannot safely improvise a purchase against an arbitrary website: it does not know the real price, the tax treatment, what is in stock, or how to pay without handling raw card numbers. Each platform could build one-off integrations with big retailers, but one-off integrations do not scale down to the long tail of software companies and small merchants. ACP exists to make purchase a protocol-level capability, the way RSS once made syndication one and the way MCP made tool use one, so any merchant can implement one API and become buyable by any compliant agent.

What the Protocol Actually Specifies

ACP has three legs. The first is the checkout session API, a small REST surface the merchant hosts. The agent platform creates a session with the items the shopper wants, the merchant responds with authoritative line items, totals, tax, fulfillment options, and status. The platform can update the session (change items, add buyer details, pick fulfillment), and the merchant re-prices on every change. When the session reaches ready_for_payment, the platform calls complete with payment data, and the merchant returns the final session with an order attached. There is also a cancel call for abandoned flows. Sessions move through five states: not_ready_for_payment, ready_for_payment, in_progress, completed, and canceled.

The second leg is delegated payment. Instead of the agent ever seeing card details, the platform's payment provider issues a Shared Payment Token (SPT), a single-use credential scoped to a specific merchant and amount ceiling. The merchant charges that token through its own payment processor, in practice Stripe, which treats it like a confirmable payment source. The shopper authorizes once on the platform side, the merchant charges once on its side, and no raw payment credentials cross the boundary. The third leg is the product feed: a flat file (JSONL or CSV) of items with prices, availability, images, and seller policy links, which platforms ingest so their assistants know what exists and what it costs before any session is created.

Requests carry a pinned API-Version header (the module pins the 2026-04-17 spec snapshot), bearer token authentication, optional HMAC signatures, and a mandatory Idempotency-Key on every POST so retries can never duplicate a charge. Errors come back in a flat, typed shape with machine-readable codes like missing, out_of_stock, and payment_declined. These details matter because they are exactly the parts that are tedious to get right by hand, and they are all covered in the ACP endpoints reference.

Who created ACP and who supports it?
OpenAI publishes the specification, and Stripe provides the matching payment infrastructure, including Shared Payment Tokens. The protocol is open, so any agent platform can adopt it as a buyer and any merchant can implement it as a seller. It debuted alongside Instant Checkout in ChatGPT, and the spec remains in beta with published snapshots merchants pin to.
Is ACP the same thing as MCP?
No. MCP (Model Context Protocol) is a general standard for connecting AI assistants to tools and data. ACP (Agentic Commerce Protocol) is specifically about completing purchases between an agent platform and a merchant. They are complementary: an MCP server can offer shopping tools conversationally, while ACP defines the platform-to-merchant checkout and payment wire format. The ACP Payment Module implements both surfaces over one commerce core.
Do I need ACP if I just want payments in my MCP tool?
Not on day one. The module's MCP checkout tool uses a hosted Stripe payment link, which works today in any MCP client with no platform enrollment. Implementing the ACP endpoints as well means agent platforms can also drive your checkout programmatically, which is where instant, in-assistant purchases come from. Since the module ships both on the same core, you get the ACP surface without extra work and can enable it whenever it becomes relevant.

How a Purchase Flows Through ACP

Walking one purchase end to end makes the protocol concrete. A shopper tells their assistant they want the Pro plan of some tool. The platform already has the merchant's product feed, so it knows the item id and price. It POSTs to the merchant's /checkout_sessions with that item, and the merchant, here the ACP Payment Module, resolves the item against the live catalog, prices it in integer cents, computes totals, and returns a session in ready_for_payment state. If the shopper changes quantity or provides an address, the platform POSTs an update and the merchant re-prices, now including tax if it is enabled and the address is known.

The platform then shows the shopper a final confirmation inside the assistant. On approval, the platform mints a Shared Payment Token scoped to this merchant and amount, and POSTs it to /checkout_sessions/{id}/complete. The merchant charges the token through Stripe, marks the session completed, attaches an order record with a permalink, and fires its order webhook to the seller's own systems for fulfillment. If the charge is declined or needs 3DS, the merchant returns the matching error code and the platform handles the recovery conversation. The whole loop is a handful of HTTPS calls, and the shopper never left the chat. The payment mechanics are covered further in payment modes and the handoff in the order webhook guide.

What ACP Means for Merchants

The strategic read is that assistants are becoming a storefront, and ACP is the cash register standard for it. Early adoption favors digital sellers, software licenses, credits, subscriptions, and digital goods, because fulfillment is instant and the buyer is already at a keyboard talking to an agent. That is precisely the segment the ACP Payment Module targets: it gives a software company the full merchant side of ACP, the MCP shopping tools, the Stripe integration, and the product feed in one free, open source package, so speaking the protocol is an afternoon of configuration instead of a quarter of engineering. Sellers weighing this channel against established ones can compare the economics in our payment processing guide, since the processing costs are identical, only the funnel changes.

It is still early. The spec is in beta, delegated payments are a Stripe preview for US merchants, and platform coverage is growing rather than complete. But protocols compound: the merchants who implemented them early tend to be the defaults when the surface matures. Implementing ACP through an open source module keeps the bet cheap, you own the deployment, there is no middleman fee, and the code is inspectable on GitHub.

Related Articles