Agentic commerce

The Agentic Commerce Protocol (ACP): an enrollment guide for merchants

ACP is how ChatGPT buys from you: your feed, your checkout API, your Stripe account, OpenAI’s buyer. Here’s what you actually build, how enrollment works, and where implementations go wrong, written by a team that shipped one.

Updated July 13, 2026 · 10 min read

In September 2025, OpenAI launched Instant Checkout in ChatGPT, built on the Agentic Commerce Protocol (ACP), an open specification it developed with Stripe. The promise to merchants is direct: a ChatGPT user asks for something, your product appears, and they buy it inside the conversation while the order lands in your systems like any other sale.

The demand side is not hypothetical. Salesforce reported AI influenced $262B of 2025 holiday sales, and OpenAI revamped Instant Checkout in March 2026 toward discovery-first product surfacing. The buyers are arriving faster than most merchant roadmaps assumed.

The official docs tell you what the API looks like. What they don’t give you is the merchant-side view: what you actually have to build, what enrollment involves, and where implementations break. We built and shipped a complete ACP implementation at Nexez, including feeds, checkout sessions, order webhooks, and settlement. This guide comes from doing the work, not paraphrasing the spec.

What ACP actually is (and what it isn’t)

ACP is a REST contract between an AI application and a merchant. The AI surface, whether ChatGPT today or anything else that speaks the protocol, discovers your products through a feed you publish, runs a checkout against an API you host, and hands you a payment credential at the end. You fulfill the order, you answer the support emails, you process the refunds.

The most important design decision sits in that last sentence: you remain the merchant of record. OpenAI is not a marketplace. It never takes custody of the money or the customer. Per OpenAI’s launch announcement, the buyer pays the same price they would on your site and merchants pay a small fee on completed purchases, while discovery costs nothing. Your fraud, tax, and chargeback obligations don’t move. Neither does your customer relationship.

Payment works through a Shared Payment Token (SPT): a Stripe-issued delegated credential scoped to a specific merchant, an amount ceiling, and an expiry window. At the end of checkout, OpenAI hands you a token and you charge it the way you’d charge any payment method. You never see the buyer’s card.

Two things ACP is not. It’s not a switch you flip in a dashboard; it’s an API integration with a partner-approval gate in front of it. And it’s not the only protocol in this space: Google’s UCP and the Model Context Protocol solve adjacent problems, and it’s worth understanding how UCP, ACP, and MCP differ before committing engineering time to any of them.

The four surfaces you have to build

A working ACP integration is four distinct pieces. None is individually hard, but they have to agree with each other exactly. Most integration pain comes from surfaces disagreeing: a feed price that doesn’t match the checkout total, an order status that never gets reported back.

The product feed

The feed is a JSON catalog of everything sellable: identifiers, titles, descriptions, prices, availability, images, and a link back to the canonical product page. Each item carries eligibility flags telling ChatGPT whether it may appear in search results and whether it’s eligible for checkout. Those flags are independent, which matters: you can publish a discovery-only feed today and flip checkout eligibility after enrollment clears.

Treat the feed as a cache of your catalog living in someone else’s system. It goes stale the moment you change a price, which is exactly why the protocol makes your checkout API, not the feed, the source of truth for money.

The checkout_sessions API

This is the core of the build: REST endpoints under your domain that OpenAI calls with a Bearer key it issues you. A session is created with line items, updated as the buyer supplies address and fulfillment choices, then either completed with a payment token or canceled. Every response returns the full recalculated state: items, totals, taxes, fulfillment options, and any buyer-facing messages.

The state machine sounds trivial and isn’t. A session that hasn’t collected enough information isn’t ready for payment. A completed session must be terminal. A canceled one must never charge. Your implementation has to enforce those transitions server-side, because you cannot assume the caller always will.

Order webhooks

After money moves, the relationship inverts: now you call OpenAI. At enrollment they give you a webhook URL and an HMAC signing secret, and your job is to push signed order events whenever state changes: confirmed, shipped, refunded, or disputed. Skip this and the buyer’s order view in ChatGPT silently goes stale, which turns into support tickets on your side, not theirs.

Settlement

At the complete step you receive the delegated token and create a PaymentIntent with it as the payment method on your own Stripe account. The money settles exactly where your web orders settle, and refunds ride your existing rails. This is the leg teams assume is easy and then get wrong. See the idempotency gotcha below.

The enrollment path, step by step

Instant Checkout is an approved-partner program, not self-serve. OpenAI’s merchant documentation at developers.openai.com/commerce describes the integration, but production credentials come through an application. Here’s the sequence as it actually plays out:

1. Apply to the program. You describe your business, catalog, and technical setup. There’s no published approval timeline, so start this before you build, not after.
2. Publish your product feed and give OpenAI the URL. Discovery-eligible items can start appearing in ChatGPT independent of checkout approval.
3. Stand up the checkout_sessions endpoints for create, retrieve, update, complete, and cancel behind Bearer auth that fails closed with a 401 until credentials exist.
4. Receive credentials: the Bearer key OpenAI presents on every request, a request-signing secret, and their order-webhook URL plus HMAC secret for your outbound events.
5. Wire settlement. Confirm with Stripe that Shared Payment Tokens work with your account structure, then charge the token at the complete step.
6. Certify with a test payment credential: session created, completed, a real test-mode charge, a durable order record, and a buyer receipt. Complete the full loop before using any real delegated token.
7. Flip checkout eligibility in your feed only after the smoke test passes end to end.

How much work is it, honestly?

It depends entirely on which of three paths you take.

The DIY estimate deserves honesty, because the endpoints themselves are only a few days of work. The long tail is everything around them: idempotent settlement, webhook signing, feed regeneration on every price change, state-machine edge cases, and keeping all of it alive when your catalog system changes. If you have in-house engineers and a high-volume catalog, owning it makes sense. If you’re a twelve-listing service business, it almost certainly doesn’t.

Gotchas that bite real implementations

These are the failure modes we explicitly designed against, in roughly the order they’ll hurt you.

One more that’s really a design stance: build the whole thing fail-closed. No credentials configured should mean a 401 on every checkout endpoint, not a best-effort guess. A dormant checkout surface is annoying; an unauthenticated one is a liability.

What to do while your application is in review

Enrollment timing isn’t in your control. Discovery is. The same structured catalog data that feeds ACP makes your site legible to every other agent, including Claude, Gemini, Perplexity, and browser agents, through JSON-LD, llms.txt, and clean machine-readable pages. Even before ChatGPT can check out with you, agents can find you, compare you, and send buyers to the checkout you already have.

That groundwork is measurable: run your site through a free agent-legibility scan to see what agents can currently extract from it, and read what llms.txt actually does before adding one. If you sell services rather than products, the deeper question is bookings. How AI agents book service businesses covers that side, and selling on ChatGPT without Shopify covers the storefront question.

ACP is early, and early is the point. The merchants who publish feeds and structure their catalogs now are the ones agents will already know when checkout enrollment opens wider. The protocol work compounds; waiting doesn’t.