OpenAI Agentic Commerce Protocol: What changes (2026)

What is the OpenAI Agentic Commerce Protocol?

ACP defines shared interfaces for commerce involving merchants and AI agents. For a merchant evaluating ChatGPT, I would separate catalog discovery from checkout: the information needed to recommend an item is not the authorization needed to purchase it.

The official onboarding guide starts with structured product data. The checkout specifications describe additional interfaces for completing an order. Your available integration depends on approval and the supported route, not simply on whether you can produce a catalog file.

Your commerce system remains responsible for authoritative inventory, pricing, and order state. The support team needs access to the appropriate evidence when a customer asks what happened. That operational responsibility matters more than describing the protocol as an automatic new sales channel.

How the OpenAI Agentic Commerce Protocol works

Review catalog data, checkout, and payment processing as separate integration concerns. The sequence below explains their responsibilities, not a guarantee that every merchant can enable all three immediately.

Step 1: Getting your products seen with a product feed

The official onboarding guide, captured in September 2026, distinguishes file uploads from API updates.

An approved partner supplies structured product data using the documented file-upload or API method. Confirm required fields and identifiers in that method's schema; do not assume every file format from an older integration guide is still accepted.

The current onboarding guide recommends a daily full feed with API updates during the day. Small feeds can use the API for both; promotions are API-only. Validate the selected method's schema and keep inventory and prices current. Uploading a feed does not guarantee that every product will appear in every shopping answer.

Step 2: Confirm the checkout integration available to you

OpenAI publishes both an Agentic Checkout Spec and a separate checkout plugin specification. Do not treat their interfaces as interchangeable or assume that feed approval enables either route automatically.

The REST checkout specification describes session creation, updates, completion, cancellation, and retrieval. Your commerce system returns the cart state and order identifiers. It also sends order events so the buyer's view can reflect subsequent changes. This is why saying the protocol stops at order confirmation is misleading: the documented lifecycle includes fulfillment and refund information.

The plugin specification describes an approved-partner beta. A merchant plugin exposes a checkout_session tool and a checkout widget. Item identifiers and quantities are required; other offer metadata can be optional. The merchant uses those identifiers to retrieve authoritative price and inventory information. A displayed price supplied with a request is not a substitute for that lookup.

Step 3: Keep payment authorization separate from conversation

The checkout specification keeps payment processing on the merchant's existing payment service provider. Delegated Payments is an optional integration where applicable, not a prerequisite to every commerce flow. Confirm the payment route supported by your approved integration rather than copying a launch example into production.

A conversational answer is not payment authorization. Your implementation still needs request authentication, input validation, and idempotency: preventing duplicate operations when a request is retried. A customer asking whether a return is possible is also not permission to cancel the order or move money.

What merchants gain, and what they still need to operate

The practical opportunity is to make your catalog usable in a shopping conversation and, where approved, connect a checkout experience. Evaluate that opportunity against your own traffic and conversion measurements. Protocol support alone does not establish a revenue lift or a reduction in abandoned carts.

The merchant remains responsible for the commerce systems behind the experience. Catalog freshness, stock changes, fulfillment promises, payment failures, and customer questions need an owner. Treat integration approval as the start of an operating process, not the end of the work.

Product information and policy knowledge serve different needs

A structured catalog can include rich product details, so it is too broad to say ACP cannot help answer pre-sale questions. The useful question is whether the available information answers this customer's question. A compatibility claim needs a reliable source; a return exception may require a policy decision that is not present in a product record.

For example, a customer could ask whether an opened camera accessory remains returnable. The product specification tells you what the accessory fits. The returns policy determines the normal rule. The order record and the customer's circumstances may determine what needs human review. Keep those sources distinct rather than treating any one of them as the whole answer.

Order events are not a complete support workflow

The checkout specification includes order updates and refund information. Those records can help explain what happened, but they do not by themselves decide how to respond to a disputed promise or a request for an exception. That is the support task evaluated in the eesel CLI walkthrough below.

An eesel teammate can use approved knowledge and supported connections, with permissions you configure. Inspect what a particular integration supplies before relying on it for order lookup or helpdesk actions. Connecting an account alone does not prove its knowledge is ready or that every action is available.

Plan for stale data and failed operations

Use a small set of failure cases before increasing traffic. These are suggested checks, not reported results from a merchant deployment:

The implementation details depend on your selected integration and payment provider. Keep test records and real customer operations separate, and compare the destination record with the user-facing result.

Configure the support workflow with eesel CLI

The CLI documentation describes terminal access to the same teammate as the dashboard. This is documentation, not a screenshot of a completed commerce integration.

A product feed, a checkout integration, and a support teammate do different jobs. The eesel CLI gives you terminal access to the same teammate and workspace you use in the eesel dashboard. It is a way to configure and inspect support operations, not an ACP checkout implementation or a payment processor.

That distinction is useful when a coding agent is helping with a commerce rollout. Claude Code, Cursor, or Codex can run the CLI, read its JSON output, and help configure knowledge and instructions. You are asking it to operate an existing support teammate, not build another support application. Connecting eesel does not automatically import an ACP catalog, establish a payment integration, or authorize refunds.

Start by confirming the destination. With Node.js 18.17 or newer, an existing eesel user can run:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents

Choose the intended teammate from that workspace. Replace SUPPORT_AGENT_ID below with its identifier, then inspect its configuration:

npx @eesel/cli status --agent SUPPORT_AGENT_ID
npx @eesel/cli integrations --agent SUPPORT_AGENT_ID
npx @eesel/cli instructions --agent SUPPORT_AGENT_ID
npx @eesel/cli automations --agent SUPPORT_AGENT_ID

Agent selection is not a sandbox. An existing teammate may already have live triggers and write permissions. Review those before changing its setup or sending a test request. Confirm that approved delivery and return policies are available as knowledge; a connected source is not necessarily downloaded and ready. Separately confirm whether the chosen integration supports the order lookup or helpdesk action you need.

A useful instruction for the coding agent is:

Inspect the selected eesel support teammate and propose changes for post-purchase questions. Identify missing policy knowledge and explain which connections or permissions are needed. Do not connect private accounts, change automations, contact customers, cancel orders, or issue refunds without my approval.

For a private rehearsal, disable write actions first and use fictional details. Suppose a customer says checkout promised next-day delivery, but the approved shipping policy only promises dispatch within two working days. Ask the teammate to draft a response that separates the customer's claim from verified policy. It should identify what order information is missing and when a person must investigate, not invent a delivery date or claim compensation was paid.

Start a fresh conversation for this case with new --name, scoped to the selected agent. Keep follow-up questions in that conversation if you want to test whether it remembers the disagreement. CLI chats are billed work; configuration inspection is free. The CLI's --dry-run previews a write request, not whether a support answer is correct.

After the policy rehearsal, separately test any approved order lookup using an authorized test record. Check the returned order identifier and state against the source system. If you later allow a helpdesk update, verify the actual destination record: a terminal answer saying an action happened is not enough. A good policy response, a successful lookup, and a delivered customer reply are three different results.

This is where eesel CLI fits the commerce project: a coding agent can help prepare and inspect support behavior while your team retains control of data access and customer-facing actions. Checkout and payment authorization remain separate responsibilities.

Get your business ready for the OpenAI Agentic Commerce Protocol

Prepare three parts of the customer journey separately: accurate product information, an approved checkout integration, and support that can explain policy and investigate order problems. Do not assume that completing one proves the others work.

For support, begin with one defined question type and approved knowledge. Use eesel CLI to inspect the intended teammate, review permissions, and rehearse a policy disagreement before enabling live actions. Confirm any required helpdesk or order connection rather than assuming ACP supplies it.

Try eesel when you want a coding agent to help configure an existing support teammate through the CLI. Check the current trial and usage terms, and expand the rollout only after verifying answers and action delivery separately.