A merchant can implement all five Agentic Commerce Protocol (ACP) endpoints correctly and still never see an agent use them.
Implementing the checkout contract is the visible work. The catalog an agent reads first is what decides whether it ever calls those endpoints.
This guide covers how ACP works, the endpoints it defines, and where to invest first.
Key takeaways:
ACP is an open HTTP standard maintained by OpenAI and Stripe. It defines five endpoints a merchant hosts so an AI agent can build a cart, apply shipping, and pay.
Agents browse far more than they buy. Product pages drew 87% of agent requests tracked across 2025, against 2.2% for checkout and payment pages.
The average US retail product page scores 66% machine-readable, meaning roughly a third of its content is invisible to an AI agent.
Fluid compute meters Active CPU, so a checkout handler stops accruing CPU charges while it waits on a payment provider. Provisioned memory still bills.
BotID reports whether a bot is verified and which one it is, so a checkout route can admit OpenAI's
chatgpt-operatoragent and return a 403 to everything else.
Copy link to headingWhat is the Agentic Commerce Protocol?
The Agentic Commerce Protocol is an open interaction standard for transactions between a buyer's AI agent and a merchant's commerce stack, with a payment service provider (PSP) completing the connection. A purchase can finish without the buyer stepping through a browser checkout.
OpenAI and Stripe co-developed the standard and govern it as founding maintainers, and OpenAI announced it on September 29, 2025, with Etsy as the first live partner. The spec ships under the Apache 2.0 license and carries a beta label, with 2026-04-17 as the current stable release.
Copy link to headingCompare ACP to UCP and MCP
Three standards currently overlap, and the protocol layer is the least settled part of the agentic commerce stack. The Universal Commerce Protocol (UCP) takes a discovery-first approach with a coalition behind it. The Model Context Protocol (MCP) handles tool invocation and carries no payment semantics.
The payment credential row is the one to read first, since the three standards diverge most sharply there:
No merchant has to bet on one of these yet. All three send agents to the same product data on the same storefront, so an accurate feed and a fast response serve an agent arriving on any of them.
Copy link to headingSplit responsibility across the three parties
Responsibility splits three ways, and that split is what lets a merchant adopt ACP without rebuilding a commerce stack. Each party holds one job:
The agent: Calls the merchant's checkout endpoints on the buyer's behalf and requests a scoped payment credential from the PSP. It never holds the order or settles the money.
The seller: Runs the checkout session on existing infrastructure and stays merchant of record. Pricing, inventory, tax, fulfillment, and refunds stay where they already live.
The payment service provider: Tokenizes the buyer's card and binds that token to one session, one merchant, a maximum amount, and an expiry. The merchant charges against the token, never raw card details.
Adopting ACP therefore looks more like exposing a new API surface than replacing a payment stack. The protocol now spans four building blocks: agentic checkout, cart and feed, delegate payment, and delegate authentication. Each reaches the merchant as a set of endpoints to implement.
Copy link to headingCore components of the Agentic Commerce Protocol
ACP is an API specification, not an SDK. A merchant implements it by exposing HTTPS endpoints that accept JSON and return the complete checkout session state on every response. Four pieces make up a working implementation.
Copy link to headingImplement the five checkout session endpoints
A merchant implements five endpoints, though only creation and completion are on every path:
Every update call recomputes tax and shipping before returning the session. Three headers are required on every request: Authorization, Content-Type, and API-Version. The create request also requires a capabilities object, which the seller answers with the intersection it supports.
Copy link to headingSend an idempotency key with every mutating request
Idempotency-Key is an optional header in the spec, not a required one. A same-key replay with identical parameters should return the original result. On the delegate payment endpoint, reusing a key with different parameters returns 409 with an idempotency_conflict code.
ACP version
2026-04-17requiresIdempotency-Keyon all checkout and delegated-payment POST requests.
Optional in the spec does not mean optional in a handler. Agents retry more aggressively than browsers do, which makes honoring the key the floor for any mutating checkout route.
Copy link to headingDelegate payment through a shared token
OpenAI builds a delegated payment request capped at a max_amount and sends it to the merchant's PSP. Supported integrations can use shared payment tokens for secure billing, and the token rides along in the /complete call.
The allowance is scoped tightly. It carries a one_time reason, a currency, an expiry, and the checkout session and merchant it may be used against, so a token can't be replayed elsewhere.
Copy link to headingExtend checkout with product feeds and the MCP binding
The 2026-04-17 release added Product Feeds as a third pillar, with a recommended cadence of one full upload per day plus intraday API calls for price and availability changes. Each row in the UTF-8 tab-delimited or CSV file carries the fields the specification marks required, including id, title, link, image_link, availability, and price.
The same release added a Model Context Protocol binding, so ACP checkout endpoints can be exposed as MCP tools without rewriting the HTTP layer underneath them. Which of these pieces to build first is the sequencing question.
Copy link to headingBest practices for adopting the Agentic Commerce Protocol
Sequencing decides whether an ACP build earns agent revenue or produces a compliant endpoint no agent reaches. The four decisions below cover what to build first, what to validate against, and what to enforce regardless of what the spec permits.
Copy link to headingConfirm checkout is the right first move
Wiring up the full checkout flow first is the common opening, and the traffic data argues against it. Product pages take 87% of agent requests against 2.2% for checkout and payment, so most agent activity today is research.
ACP checkout earns its build cost when all four of these hold:
A narrow catalog: Single-item purchases with no bundle or promo-app logic.
Real-time inventory: Stock and availability that are authoritative at the API layer rather than batch-synced.
A qualified PSP: Payments running through a provider certified to PCI DSS Level 1.
Confirmed feed accuracy: Product data checked end to end against the transactional backend, not sampled.
Shipping checkout before the catalog data is trustworthy inverts the order of return.
Copy link to headingInvest in feed accuracy before checkout depth
The average US retail product page scores 66% machine-readable, so roughly a third of what it says never reaches an agent. An attribute the agent can't read is, for the purposes of any recommendation it makes, an attribute the product doesn't have. Repairing availability values that drift from the backend and adding geo_price attributes for regional pricing close part of that gap.
Latency belongs in the same workstream. Agents abandon a slow catalog request far sooner than a person browsing the same page would. An endpoint answering in well under a second protects the crawl that feeds every later step.
Copy link to headingValidate against both published schema artifacts
A handler validated against one artifact can pass its own tests and still fail a real agent's request. An open issue on the ACP spec repo documents six fields in the 2026-04-17 checkout schema that the JSON Schema declares and the OpenAPI document rejects. The OpenAPI schemas set additionalProperties: false, so those fields fail validation outright. Which artifact wins is still an open question with the maintainers, so check payloads against both and avoid the drifting fields until they rule.
Copy link to headingEnforce idempotency on every mutating route
Because the spec leaves Idempotency-Key optional, a handler that only honors it when present inherits whatever the calling agent decides to send. A retry without a key reads as a new purchase. Requiring the key on mutating routes, and storing results against it, moves that guarantee out of the agent's hands and into the merchant's. The infrastructure those decisions run on carries the remaining cost.
Copy link to headingHow Vercel powers agentic commerce for ecommerce teams
Agent traffic hits the same storefront human traffic does, with different latency tolerances, different retry behavior, and a payment path that runs server to server. Four platform pieces map onto those differences. None of them fixes inventory that is wrong at the source, and none takes over order state, refunds, or tax reconciliation. Those stay with the commerce backend.
Copy link to headingCut checkout billing to active CPU time
An ACP /complete handler spends most of its wall-clock time waiting on a PSP charge, a tax calculation, and a shipping lookup. Traditional serverless billing treats that waiting as computation.
Fluid compute meters Active CPU instead, so charges accrue while code executes and pause during I/O wait. Provisioned memory continues to accrue separately. An I/O-bound /complete handler is the workload shape that model was built around.
Copy link to headingVerify the agent at the door
Gating a checkout route on isBot alone rejects chatgpt-operator, the agent issuing legitimate ACP requests, along with everything else. BotID returns isBot, isVerifiedBot, and verifiedBotName, which supports a narrower rule:
import { checkBotId } from 'botid/server';
export async function POST(request: Request) { const { isBot, isVerifiedBot, verifiedBotName } = await checkBotId(); const isOperator = isVerifiedBot && verifiedBotName === 'chatgpt-operator';
if (isBot && !isOperator) { return Response.json({ error: 'Access denied' }, { status: 403 }); }
return handleCheckout(request);}IP ranges and user-agent strings are trivial to spoof, and BotID depends on neither. Over Black Friday and Cyber Monday 2025, the firewall executed 7.5 billion actions and blocked over 415 million bots. Spoofed traffic at a checkout route arrives at volume.
Copy link to headingKeep the product feed fresh with ISR and Cron Jobs
A feed that drifts from the backend fails agents quietly, because the agent trusts what it read. For webhook-driven expiration, call revalidateTag('product-feed', { expire: 0 }) so the next request fetches fresh data. Time-based revalidation can provide a fallback, but it does not guarantee that every response is less than 15 minutes old.
ACP's recommended cadence maps onto those controls directly:
A daily snapshot: A Cron Job regenerates the full feed, paired with an inventory webhook that calls
revalidateTagon price or stock changes.A 15-minute staleness floor: Setting
export const revalidate = 900on the feed route caps drift when a webhook is missed.
Both routes sit at public URLs, so each one verifies its caller before invalidating anything. Vercel sends the value of a CRON_SECRET environment variable as an Authorization header on every cron invocation, and the handler compares the two before regenerating. Keep that variable server-side and never prefix it with NEXT_PUBLIC_, which would inline it into the browser bundle. Per-region snapshots have room to run, since every plan now supports up to 100 cron jobs per project.
Copy link to headingShip the checkout contract without hand-rolling it
Reimplementing the session contract by hand is where handler bugs appear, usually around idempotency and error shapes. Vercel's acp-handler package covers it in TypeScript, with idempotency, signature verification, and OpenTelemetry tracing built in. It is still published as an alpha and expects a Redis-compatible store for sessions, so treat it as a starting point rather than a finished dependency.
It targets Web Standard request and response objects, so it ships adapters for more than one framework. On the discovery side, the Shopify template ships llms.txt, structured data, and a sitemap on the first deploy.
Copy link to headingBuild for agents that read before they buy
Agent traffic rewards a storefront that is already fast and already accurate long before it rewards a fully wired checkout flow. The infrastructure absorbing a peak-season spike is the same infrastructure an agent hits when it crawls a catalog.
How much of the ACP surface to build depends on catalog complexity and how authoritative an inventory API already is. Vercel covers the layers underneath that decision:
Active CPU metering: Billing pauses while a checkout handler waits on a PSP, a tax service, or a shipping lookup. Provisioned memory keeps accruing.
Verified-bot signals: BotID reports whether a caller is a verified bot and which one, so a route can admit
chatgpt-operatorand refuse the rest.Tag-based feed invalidation: An authenticated webhook and a scheduled snapshot keep product data current without rebuilding routes that didn't change.
First-party ACP handler: The
acp-handlerpackage covers idempotency, signature verification, and tracing. It is published as an alpha.Peak-season capacity: The same network carried 115.8 billion requests over Black Friday and Cyber Monday 2025, and agent crawls run on it too.
Start a new Vercel project and ship on your first git push, or browse vercel.com/templates to begin from a commerce foundation you can grow into.
Copy link to headingFrequently asked questions about the Agentic Commerce Protocol
Copy link to headingWhat is the difference between ACP and MCP?
They answer different questions. MCP describes how an agent calls a tool, and ACP describes what a purchase means once that tool is called. An MCP server on its own has no way to carry a scoped payment credential or bind a charge to an order, which is the part ACP specifies.
Copy link to headingDo I need to implement the full Delegate Payment spec to use ACP?
No. A PSP that supports the shared payment token path handles the delegated credential with minimal integration work. Iframe-based payment integrations send cardholder data directly to the payment processor, so the merchant platform never processes, stores, or accesses it.
Copy link to headingHow do I stop bot traffic from abusing ACP endpoints in peak season?
Verification at the route is the first layer, and rate limiting is the second. A verified agent name identifies who is calling but says nothing about how often, so it belongs alongside Firewall rules that cap request rates on /checkout_sessions paths. Unverified traffic to those paths has no legitimate reason to arrive.
Copy link to headingWhat is the fastest way to keep an ACP product feed accurate on Next.js?
Webhook-driven invalidation is the fast path, and the scheduled snapshot exists to catch what the webhooks miss. Price and stock are the two fields worth monitoring for changes with a webhook, and that route should authenticate its caller before invalidating anything. A time-based floor on the feed route then bounds how stale the data can get if a webhook never fires.