What Is ACP? The Agentic Commerce Protocol Explained

ACP is an open protocol for AI agents to check out at merchants. It defines how an agent tells a business what's in the cart, how the business confirms pricing and availability, and how a single-use payment token flows through the transaction. Co-authored by OpenAI and Stripe, released in September 2025 under Apache 2.0, and first deployed inside ChatGPT's Instant Checkout in February 2026.

If you're building an agent that needs to buy something from a merchant (not an API call or a physical good from a big-box retailer), ACP is probably in your stack. This guide walks through what ACP is, its four endpoints, how Shared Payment Tokens work, where it fits in the broader agentic commerce protocol landscape, and what it doesn't solve.

ACP in one paragraph

ACP is a specification for four REST endpoints that a merchant exposes so an AI agent can create, update, complete, or cancel a checkout session programmatically. Payment flows through a Shared Payment Token (SPT), a single-use, time-bound, amount-restricted credential that the agent can present on the user's behalf without ever seeing raw card data. The spec lives at agenticcommerce.dev and is PSP-agnostic, though Stripe is the first payment service provider to implement SPTs.

The problem ACP solves

Before ACP, every agent that wanted to check out at a merchant had to do one of three things:

1. Scrape the merchant's website. Puppeteer, Playwright, and a team of engineers keeping the scrapers alive as merchants redesign their checkout every quarter.
2. Use the merchant's public API. Most merchants don't have one. Those that do (Shopify Storefront, BigCommerce) only work within their specific platform.
3. Build bespoke integrations. One-off agreements with each merchant. Doesn't scale past a handful.

None of these give a consistent experience for agents, and none of them give merchants the control they need over what gets sold, to whom, and at what price.

ACP standardizes the handshake. A merchant implements four endpoints once. Any agent platform that speaks ACP can check out through those endpoints. The merchant stays the merchant of record, keeps their customer relationships, and controls per-agent and per-transaction approval. The agent gets a predictable, versioned API to integrate against.

The four ACP endpoints

ACP defines four operations, all REST, all aligned to how a traditional merchant checkout already works:

1. Create Checkout

The agent initiates a checkout with cart contents, customer info, and shipping details.

POST /checkout_sessions
Authorization: Bearer <agent_credential>
Content-Type: application/json

{
  "buyer": {
    "email": "jane@example.com",
    "first_name": "Jane",
    "last_name": "Doe"
  },
  "items": [
    {
      "product_id": "prod_abc123",
      "quantity": 1
    }
  ],
  "shipping_address": {
    "line_1": "123 Main St",
    "city": "San Francisco",
    "state": "CA",
    "postal_code": "94105",
    "country": "US"
  }
}

The merchant responds with a checkout_session_id, pricing breakdown (subtotal, tax, shipping), and any required fields the agent still needs to fill in.

2. Update Checkout

The agent can update the session before completion - change quantities, swap shipping methods, apply promo codes, update the address.

POST /checkout_sessions/{id}
Content-Type: application/json

{
  "items": [
    { "product_id": "prod_abc123", "quantity": 2 }
  ]
}

The merchant recalculates pricing and returns the updated session state.

3. Complete Checkout

The agent submits the Shared Payment Token and the merchant charges the payment method and confirms the order.

POST /checkout_sessions/{id}/complete
Content-Type: application/json

{
  "payment": {
    "shared_payment_token": "spt_test_abc123..."
  }
}

If payment succeeds, the merchant returns an order_id and the purchase is real.

4. Cancel Checkout

Before completion, the agent (or the merchant) can cancel cleanly.

POST /checkout_sessions/{id}/cancel

No charge, no order, session closed.

That's the entire surface area. Four endpoints. Any merchant can implement them. Any agent platform can call them. The protocol doesn't care what's in the cart (physical goods, digital goods, subscriptions, async purchases are all supported).

Shared Payment Tokens (SPTs)

The payment piece is where ACP's design matters most.

A Shared Payment Token is a single-use credential that represents permission to charge a specific amount, to a specific merchant, within a specific time window. The user or their wallet provider generates the SPT. The agent receives it scoped to exactly this transaction. The merchant charges it. The token expires.

What an SPT carries:

• Merchant identifier (can only be charged by this merchant)
• Maximum amount (can't be charged more than authorized)
• Expiration window (can't be charged past this time)
• Single-use marker (can only be charged once)

What an SPT doesn't carry:

• Raw card data (stays with the payment processor)
• User account credentials
• Long-lived payment authority

This is how ACP separates the agent's authority to act from the user's authority to pay. The agent can't drain a wallet. The merchant can't bill again later. The user's card details never reach the agent's runtime.

Stripe was the first PSP to implement SPTs. Any compatible PSP can issue tokens that ACP merchants accept. PayPal announced its own ACP server under development at launch.

ACP in production: where it's live today

ACP's first real deployment was OpenAI's Instant Checkout feature in ChatGPT, rolled out to US Etsy sellers in February 2026. A user would ask ChatGPT for a product, ChatGPT would display options, and for participating Etsy sellers, a "Buy" button inside the chat completed the purchase through ACP.

In early March 2026, OpenAI scaled back in-chat purchasing and pivoted to an app-based model. The protocol continues. The specific ChatGPT UI changed.

The lesson that matters: ACP's long-term value is as an open standard, not as a feature of any single platform. Stripe, Shopify, Salesforce, and PayPal are all building or supporting ACP. OpenAI is the first agent platform. More will follow.

What ACP doesn't solve

ACP gets a lot done with four endpoints. It doesn't do everything.

ACP doesn't help you buy from non-ACP retailers. Amazon, Walmart, Target, Best Buy, and most big-box stores haven't adopted ACP and aren't on public roadmaps. If your agent needs to buy from them, ACP won't help. You need an execution layer like Zinc that handles programmatic ordering at 50+ retailers that don't speak ACP.

ACP doesn't handle machine-to-machine API payments. It's designed for human-present commerce where an agent assists a user. For pure agent-to-API micropayments, use MPP or x402 instead.

ACP doesn't handle long-running authorizations. Each checkout session is a single transaction. For pre-authorized agents that act on a user's behalf over time (delegated shopping), you want Google's AP2 protocol layered on top.

ACP doesn't handle payment settlement. It's a checkout protocol. The actual money movement happens through the underlying PSP (Stripe's SPTs today). If the PSP fails, ACP's checkout fails.

ACP doesn't discover merchants. There's no central directory of ACP-enabled merchants. Each agent platform manages its own merchant participation program. If you want to sell through ChatGPT, you apply to OpenAI. No global registry exists.

ACP vs MPP vs x402 vs AP2

Four protocols come up constantly in agentic commerce conversations. They don't compete; they stack.

• ACP (OpenAI + Stripe): How agents check out at merchants. Four endpoints, single-use payment tokens. Merchant-facing.
• MPP (Stripe + Tempo): How agents pay for services over HTTP 402. Sessions, multi-rail (stablecoin + fiat + cards). Service-facing.
• x402 (Coinbase): How agents pay in stablecoins over HTTP. Zero protocol fees, purely crypto-native. Service-facing. See our MPP vs x402 comparison.
• AP2 (Google + 60 partners): How agents get authorized to pay. Cryptographically signed mandates. Authorization layer across all of the above.

A production agent that shops for a user might use all four: AP2 for the user's delegated authorization, ACP to check out at a Shopify merchant, MPP to pay a data API mid-flow, and x402 for a purely crypto micropayment. For retail orders at Amazon or Walmart, none of the protocols cover it - you need an execution layer like Zinc that handles the retailer-specific integration.

Should you implement ACP?

Implement ACP as a merchant if:

• You sell physical or digital goods directly and you're already on Stripe, Shopify, or another ACP-compatible PSP
• You want to be discoverable by agents on ChatGPT and future agent platforms
• You have the engineering capacity to expose four endpoints plus inventory, pricing, and order confirmation flows
• You want to participate in agent-driven commerce without giving up merchant-of-record status

Implement ACP as an agent platform if:

• Your agents help users discover and buy from merchants (not APIs, not big-box retailers)
• Your users want to transact inside your chat or app without being redirected
• You're willing to build a merchant approval and discovery layer on top of the protocol

Skip ACP (at least for now) if:

• Your agents only place orders at big retailers (use Zinc instead)
• Your agents only pay for APIs and services (use MPP or x402)
• You don't have a clear merchant story

Getting started

The ACP spec is at agenticcommerce.dev. Read it, then:

If you're a business implementing ACP:

1. Check whether your payment processor supports Shared Payment Tokens. Stripe is the first; Stripe's docs are at docs.stripe.com/agentic-commerce.
2. Expose the four endpoints (create, update, complete, cancel) following the ACP spec.
3. Apply to agent platforms you want to sell through. OpenAI's ChatGPT has its own application process at acp@stripe.com.

If you're building an agent that uses ACP:

1. Read the ACP spec.
2. Generate Shared Payment Tokens through your PSP when the user confirms intent to buy.
3. Call the merchant's ACP endpoints to check out.
4. Handle the order confirmation and webhooks.

If you need to buy from retailers that don't speak ACP:

Use an execution layer. Zinc provides programmatic ordering at 50+ retailers including Amazon, Walmart, Target, and Best Buy through a single API. No retailer needs to implement ACP for Zinc to work - Zinc bridges the gap. See the Zinc quickstart to place your first order, or build the full flow end-to-end with our guide to building an AI shopping agent.

Bottom line

ACP is a well-scoped protocol that solves a specific problem: letting agents check out at merchants without scraping, without per-merchant custom integrations, and without giving up the merchant-of-record relationship.

It's not a universal commerce protocol. It's the checkout layer of a larger stack. Agents that operate across the full commerce landscape will combine ACP (for merchants that support it), MPP or x402 (for service payments), AP2 (for authorization), and execution-layer infrastructure like Zinc (for the many retailers that don't speak any of these protocols yet).

If you're building for the agent economy, support ACP where your merchants are and pair it with execution-layer coverage for everywhere else.

For the full context on how agentic commerce stacks together, read Agentic Commerce in 2026: The Complete Developer Guide. For the machine-to-machine payment layer, read What Is MPP? A Developer's Guide to Machine Payments. To place a real retail order right now, try agent.zinc.com.

Frequently Asked Questions

What does ACP stand for?

ACP stands for Agentic Commerce Protocol. It's an open specification for how AI agents check out at merchants, co-developed by OpenAI and Stripe, released September 2025 under Apache 2.0 license.

Who created ACP?

ACP was co-authored by Stripe and OpenAI. Shopify, Salesforce, and PayPal all support or are building ACP implementations. The specification is open source and community-contributed at agenticcommerce.dev.

How does ACP work?

A merchant implements four REST endpoints (Create Checkout, Update Checkout, Complete Checkout, Cancel Checkout). An AI agent calls those endpoints to build a cart and complete a purchase on the user's behalf. Payment flows through a Shared Payment Token issued by the user's payment processor (like Stripe). The merchant remains the merchant of record.

What is a Shared Payment Token?

A Shared Payment Token (SPT) is a single-use, time-bound, amount-restricted payment credential. It gives an agent permission to charge a specific amount at a specific merchant within a time window, without exposing raw card data. Stripe was the first PSP to support SPTs.

How is ACP different from MPP?

ACP is a checkout protocol for agents buying from merchants. MPP is a payment protocol for agents paying for services (APIs, compute, data, physical goods) over HTTP. ACP assumes a human-present shopping flow with a merchant relationship. MPP handles machine-to-machine payments where there's no pre-existing merchant relationship.

Does ACP work with Amazon or Walmart?

No. Amazon, Walmart, Target, Best Buy, and most big-box retailers have not adopted ACP. For programmatic ordering at those retailers, use an execution layer like Zinc, which covers 50+ retailers through a single API without requiring the retailer to implement ACP.

Is ACP production-ready?

Yes. ACP launched in OpenAI's ChatGPT Instant Checkout in February 2026 with Etsy sellers. OpenAI has since pivoted to an app-based model, but the protocol remains an open standard with continued support from Stripe, Shopify, Salesforce, and PayPal. Merchant implementations are live in production today.

Where can I read the ACP specification?

The open specification is at agenticcommerce.dev. Stripe's implementation documentation is at docs.stripe.com/agentic-commerce.