If a customer asks ChatGPT to "buy me the thing," and the thing is in your store, the sale either happens without a browser or it goes to a competitor whose catalog the agent can actually read and check out against. That is the whole stakes of the Agentic Commerce Protocol. It is not a chatbot integration and it is not a new Stripe product — it is an open standard, co-developed by Stripe and OpenAI, that defines how a buyer's agent completes a purchase directly against your systems. This walkthrough is the merchant's side: what you build, where the money and the risk actually sit, and the two defaults that quietly cost you orders.

The one-paragraph version#

ACP was published under Apache 2.0 in September 2025 and its first live use is Instant Checkout in ChatGPT, already selling for Etsy and Shopify merchants. It is one of several agent-payment standards now in play — if you want the map of how it sits next to Google's AP2 and the crypto-native x402, we covered that in AP2 vs x402 vs ACP. This piece is narrower: the merchant's build. As a merchant you implement three things: a product feed the agent reads to discover and rank your items, a Checkout API of five REST endpoints, and a delegated-payment step that converts the buyer's card into a single-use, scoped token you charge on your own processor. The agent never sees a card; you never hold an open-ended credential. Everything that matters — cart validation, tax, shipping, fraud checks — stays on your server.

The shape of a purchase#

There are three parties: the buyer, their agent (ChatGPT), and you, the merchant. The flow is:

  1. The agent discovers your product in your feed and shows it to the buyer.
  2. The agent calls your Checkout API to build and price a cart against your authoritative catalog.
  3. When the buyer confirms, the agent obtains a delegated payment token and calls your complete endpoint.
  4. You validate, run risk checks, charge the token on your processor, and emit an order event to a webhook.

The agent orchestrates; your server is the source of truth for price, tax, availability, and the final charge.

1. The product feed — where discovery is won or lost#

Before anything is buyable, it has to be discoverable. ACP expects a structured product feed — a machine-readable catalog the agent ingests (for ChatGPT, refreshed daily against an OpenAI-provided endpoint) and ranks. This is the piece founders under-invest in and then wonder why the agent never surfaces their product.

Treat the feed like SEO for agents: complete titles, real descriptions, accurate price and availability, variants, and identifiers. A thin or stale feed is not a soft penalty — it is invisibility. The agent cannot sell what it cannot read.

A stale feed isn't a ranking penalty. It's a locked door. The agent sells your competitor because it could read their catalog and not yours.

2. The Checkout API — five endpoints, one rule#

The agent drives checkout by calling five REST endpoints you host. The single rule that governs all of them: every response returns the full, authoritative cart state — line items, pricing, taxes and fees, shipping, discounts, totals, and status. Never return a partial. A partial response desyncs the agent's view of the cart, and a desynced cart is an abandoned one.

POST   /checkout_sessions                      # create a session from the agent's cart → full cart state
POST   /checkout_sessions/{id}                 # update items / shipping / discounts → full cart state
GET    /checkout_sessions/{id}                  # read authoritative state (404 if unknown)
POST   /checkout_sessions/{id}/complete         # place the order → status: completed + order
POST   /checkout_sessions/{id}/cancel           # abandon (405 if already completed or canceled)

The complete response is the one with teeth: it MUST return status: completed and an order object carrying an id, the checkout_session_id, and a permalink_url the agent can hand back to the buyer as a receipt.

// POST /checkout_sessions/{id}/complete → 200 OK
{
  "id": "cs_9f3k2",
  "status": "completed",
  "line_items": [
    { "id": "li_1", "title": "Trail Runner — M9", "quantity": 1, "amount": 12800 }
  ],
  "totals": { "subtotal": 12800, "tax": 1024, "shipping": 0, "total": 13824, "currency": "usd" },
  "order": {
    "id": "ord_5521",
    "checkout_session_id": "cs_9f3k2",
    "permalink_url": "https://yourstore.com/orders/ord_5521"
  }
}

Amounts are in the currency's minor units (cents). Keep your session store keyed by checkout_session_id; the agent will GET it to reconcile if anything looks off.

3. Delegated payment — the part that keeps you safe#

Here is the mechanism that makes handing checkout to an autonomous agent sane. The agent does not get your customer's card, and it does not get a reusable credential. Instead it requests a delegated payment token:

POST /agentic_commerce/delegate_payment
Idempotency-Key: 5f1c...            # required — de-dupes retries
Signature: keyid="...",sig="..."    # signed request

The payment provider returns a vault token scoped by an allowance object and metadata:

{
  "vault_token": "vt_live_8k2...",
  "allowance": { "max_amount": 13824, "currency": "usd" },
  "expires_at": "2026-07-22T18:40:00Z",   // RFC 3339
  "merchant_id": "acct_yourstore",
  "checkout_session_id": "cs_9f3k2",
  "risk_signals": ["device_verified", "buyer_authenticated"]
}

Read that token for what it is: a one-time, capped, expiring voucher bound to this cart and only this cart. max_amount is the ceiling. expires_at is short. checkout_session_id pins it to one order. A compromised agent, a retry storm, or a bug cannot overspend it or replay it. You then charge that token on your existing processor — Stripe or otherwise — inside your complete handler, after your own validation passes.

This is why "an agent has my credit card" is the wrong mental model. There is no card-on-file. Each purchase mints a fresh, purpose-scoped token, and the buyer confirms in the agent UI before it is issued. If you want the buyer's side of the same token — issuing and spending one from an agent — we walked through it in Take Your First AI-Agent Payment.

4. Webhooks — stay in sync after the sale#

Checkout ends, fulfillment begins. Emit order_create and order_update events to the webhook receiver so the agent — and therefore the buyer — sees shipping and status changes without polling you. This is the same discipline as any commerce webhook: sign it, make the handler idempotent, and treat your store as the fulfillment-grade source of truth.

Build it yourself, or take the managed path?#

ACP is an open spec, so you can implement all of it against any capable processor. But the delegate-payment and token-vaulting machinery is exactly the part a small team least wants to own. Stripe's managed route — Shared Payment Tokens plus an agent-facing checkout — implements that leg for you, so you build the feed and the five endpoints and let Stripe vault and issue the token. If you have a payments team or a non-Stripe processor, roll your own; if you are three people who want to be buyable in ChatGPT this week, take the managed path. Either way the checkout and feed stay portable, because the protocol is the standard, not the vendor.

The two things that actually cost you orders#

Agentic checkout is not a future you prepare for — it is a channel that is live and selling today. The merchants who show up in it are the ones whose feed is rich and whose five endpoints never lie about the cart. Ship those, cap the token, and let the agent do the buying.