04 — Protocol Deep Dive: The Agentic Commerce Protocol (ACP)

Cross-references: this section complements 03-protocol-deep-dive-ap2.md (Google's Agent Payments Protocol / AP2) and feeds into 06-card-networks.md, 07-wallets-platforms.md and 08-merchant-and-retail.md. Throughout, we quote only what the public spec, Stripe docs, OpenAI docs, or cited press state; inferences are marked explicitly as such.

1. Origin: from ChatGPT Plus billing to Instant Checkout

The Agentic Commerce Protocol (ACP) was publicly unveiled on 29 September 2025, co-announced by OpenAI and Stripe under the consumer-facing brand Instant Checkout in ChatGPT. It is the first production deployment of what the two companies describe as "an open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly"[^1]. The initial launch made it possible for logged-in U.S. ChatGPT users — on the Free, Plus, and Pro tiers — to buy a single item from participating Etsy sellers directly inside a chat, with over one million Shopify-backed merchants (including Glossier, SKIMS, Spanx, and Vuori) queued to follow[^2][^3].

The partnership did not materialise overnight. Stripe has been OpenAI's billing infrastructure provider since March 2023, when OpenAI chose Stripe Billing, Checkout, Tax, Revenue Recognition, and Link to commercialise ChatGPT Plus and DALL·E[^4]. That long-running relationship — and the fact that OpenAI users were already anchored to Stripe's Link wallet — explains why ACP's first payment-credential handler is specifically a Stripe primitive (the Shared Payment Token, discussed below) rather than a neutral token format. The two teams formalised the specification, released a reference implementation, and open-sourced the protocol repository (agentic-commerce-protocol/agentic-commerce-protocol) on the day of the ChatGPT announcement; the repo's oldest versioned spec snapshot is dated 2025-09-29[^5].

Within two weeks of launch, the biggest validator of the approach joined: on 14 October 2025, Walmart announced that customers and Sam's Club members would "soon shop Walmart through ChatGPT using Instant Checkout"[^6]. CEO Doug McMillon framed it as a deliberate move away from the search-bar paradigm ("there is a native AI experience coming that is multi-media, personalized and contextual"), while Sam Altman described the integration as "one way AI will help people every day"[^6]. The same day, Visa launched its Trusted Agent Protocol (see 06-card-networks.md), making 14 October a pivotal moment for the wider agentic-payments stack.

As of the spec version in effect at the time of writing (2026-04-17), ACP has released five dated snapshots — 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30, and 2026-04-17 — reflecting a monthly-to-quarterly cadence that has added fulfillment primitives, capability negotiation, extensions and discounts, payment handlers, product feeds, orders and authentication, and an MCP transport binding[^5].

2. Design goals

The protocol is unusually candid about what it is not trying to do. The Stripe documentation states plainly that in an agentic checkout "the AI agent is responsible for presenting the checkout interface and collecting payment credentials, while the seller is responsible for their existing data model and payment processing"[^7]. From that division flow three overriding design goals.

(a) Preserve Merchant-of-Record status. The agenticcommerce.dev landing page describes the protocol's core promise to businesses as: "businesses maintain their customer relationships as the merchant of record, retaining control over which products can be sold, how they're presented, and how orders are fulfilled"[^8]. This is functionally the opposite of a marketplace model. ACP is deliberately engineered so that ChatGPT is not the seller: orders, taxes, disputes, compliance, and fulfillment remain on the merchant's existing commerce stack. The Agentic Checkout RFC makes the same point normatively: "The merchant remains the system of record for all orders, payments, taxes, and compliance. … Orders are processed entirely on the merchant's existing commerce stack. Payment authorization and settlement continue to occur via the merchant's PSP"[^9].

(b) Avoid pushing merchants into a higher PCI scope. A delegated payment credential — the Stripe SharedPaymentToken (SPT) — is the mechanism by which ChatGPT hands a charge to the merchant without the merchant ever receiving raw PAN/CVC. As Stripe's SPT documentation notes, an SPT "represents a scoped grant of the customer's payment method from the agent" and, when the merchant confirms a PaymentIntent with it, "Stripe sets payment_method to a new PaymentMethod cloned from the customer's original payment method. Subsequent events, such as refunds and reporting, behave as if you provided the PaymentMethod directly"[^10]. The practical effect is that existing Stripe integrations — Connect, Radar, Sigma, Tax, Terminal — continue to work as-is.

(c) Minimise integration effort on both sides. The merchant-facing surface is a small REST API (five checkout endpoints plus an optional delegate-payment endpoint) and JSON, not gRPC, signed VCs, or a new wallet SDK; the agent-facing surface reuses bearer tokens, request signing, and idempotency keys — all idioms that anyone who has integrated Stripe already understands. The ACP principles document underlines this pragmatism: "The specification is meant to be used. … Design changes should focus on real, deployable improvements with clear adoption paths, not theoretical ideas"[^11].

A fourth, implicit goal is neutrality: "ACP is agnostic to specific agents, payment providers, sellers, transport layers, payment methods, etc."[^11]. Today this neutrality is largely aspirational — OpenAI and Stripe are the only two shipping implementations, and the SPT handler is PSP-specific — but the repository structure (handler registries, payment-handler RFCs, capability negotiation, MCP binding) shows the direction of travel.

3. Actor model

ACP formalises five actors. Where AP2 centres on mandates between the user and the agent (see 03-protocol-deep-dive-ap2.md §3), ACP centres on a checkout session between the agent and the merchant.

Actor Role Notes
Buyer The natural person with an account on the agent's platform (e.g. a ChatGPT user). Provides shipping address, payment credential, and final "buy" confirmation.
Agent The AI application hosting the conversation (ChatGPT in the reference deployment; "any AI agent can call an ACP-enabled checkout"[^8]). Presents UI, collects credentials, calls merchant endpoints, provisions the SPT, and renders the authoritative cart returned by the merchant.
Merchant The seller of record. Operates the ACP REST endpoints on their own infrastructure. Retains MoR liability; owns the order record; calls their PSP to authorise.
PSP The merchant's existing payment service provider. In the reference deployment this is Stripe, but ACP is "agnostic" — any PSP with a compatible tokenised-card handler can in principle plug in[^8].
Stripe (as token issuer) In the OpenAI/Stripe reference flow, Stripe vaults the buyer's card on behalf of ChatGPT, issues the SPT, sets usage limits, and later clones a PaymentMethod onto the merchant account at charge time[^10]. Today acts as a de facto delegated vault, bridging ChatGPT (which must not hold PANs) and merchants (who should not receive new PANs).

Two observations follow. First, the buyer's card-on-file typically lives with the agent platform, not the merchant — this is the biggest structural departure from web checkout, and it is what makes the SPT necessary. Second, the merchant is the only actor that has to implement new endpoints; the agent and PSP sides are taken off-the-shelf from OpenAI and Stripe, respectively.

4. Core objects

ACP is built from a small set of normative JSON objects, each of which is defined both in an OpenAPI 3.1 schema and in a JSON-Schema bundle under spec/<version>/[^5]. The four most important for this report are:

4.1 Product Feed

The newest major primitive, introduced in the 2026-04-17 snapshot. Its RFC opens with the problem statement that agents previously had to scrape or rely on proprietary catalogue APIs, "brittle, incomplete, and inconsistent across merchants"[^12]. A feed is a merchant-published JSONL catalogue that agents ingest to:

"1. Build or refresh a searchable index of the merchant's products and variants. 2. Match buyer intent to concrete purchasable variants… 3. Present product choices to the buyer with enough context for review… 4. Select the merchant-recognized item identifier to pass into checkout."[^12]

A companion REST Feed API (POST /feeds, PATCH /feeds/{id}/products, plus offline metadata.json + products.jsonl bulk replacement) lets merchants register catalogues against a target_country[^13]. Crucially, the RFC states that "Product feeds are a discovery and merchandising surface. Checkout remains the authoritative surface for pricing, taxes, fulfillment, payment, policy checks, and order creation"[^12] — i.e. prices in a feed are advisory; the checkout session's totals are binding.

4.2 Delegated Payment Credential (Stripe SharedPaymentToken)

ACP's payment-handler layer abstracts over "how the agent passes payment data to the merchant." In today's reference implementation, the handler is card_tokenized (name dev.acp.tokenized.card, PSP stripe)[^9]; the carried credential is a Stripe SharedPaymentToken (SPT). A granted SPT carries usage_limits with currency, max_amount, and expires_at, plus the target PSP account; when revoked or expired the merchant receives a shared_payment.granted_token.deactivated webhook[^10]. See §7 below for the lifecycle.

4.3 Checkout Session

The central state-machine object. Its lifecycle is laid out in the Agentic Checkout RFC:

"Create — POST /checkout_sessions initializes a session from items and optional buyer/address. Update — POST /checkout_sessions/{id} applies changes (items, address, fulfillment option). Retrieve — GET /checkout_sessions/{id} returns latest authoritative state. Complete — POST /checkout_sessions/{id}/complete finalizes with a payment method and MUST create an order. Cancel — POST /checkout_sessions/{id}/cancel cancels if the session is not yet completed/canceled."[^9]

Its status enum is not_ready_for_payment | ready_for_payment | completed | canceled | in_progress, plus authentication_required when 3DS is triggered[^9]. Every response carries the full, authoritative cart — line items with integer minor-unit money, fulfillment options with delivery windows, totals, messages, policy links, capabilities (payment handlers), and (after completion) an order stub.

4.4 Order

Minimal by design. The Order object returned on completion has only id, checkout_session_id, and permalink_url[^9]. Post-purchase events — shipped, delivered, refunded, cancelled — are delivered via a separate Agentic Checkout Webhooks specification (order_create, order_update)[^9]. This keeps ACP from duplicating commerce-platform OMS data models.

A handful of supporting objects appear throughout: FulfillmentOption (shipping / digital / pickup / local_delivery variants), PaymentHandler (self-describing handler registry entry with config_schema and instrument_schemas), AuthenticationMetadata / AuthenticationResult (for 3DS2), Message (info / warning / error with CommonMark-restricted content), and Disclosure (legally-required seller statements). All money fields are integers in minor units — explicit protection against floating-point ambiguity[^9].

5. API walkthrough

5.1 Wire format, transport, and discovery

ACP is JSON-over-HTTPS (TLS 1.3 required). The OpenAPI file spec/2026-04-17/openapi/openapi.agentic_checkout.yaml opens with:

openapi: 3.1.0
info:
  title: Agentic Checkout API
  version: "2026-04-17"
  description: |
    Merchant-implemented REST API for ChatGPT-driven checkout.
    Implements create, update (POST), retrieve (GET), complete, and cancel of
    checkout sessions.
servers:
  - url: https://merchant.example.com
security:
  - bearerAuth: []

[^14]

Discovery is via a well-known JSON document: "ACP provides a well-known discovery document (/.well-known/acp.json) that advertises the seller's capabilities, supported API versions, and available transports"[^15]. When a seller also speaks MCP (the Model Context Protocol binding added in the 2026-04-17 snapshot), the transports array includes "mcp" and the agent can call the same five operations as JSON-RPC 2.0 tool calls over MCP's Streamable-HTTP transport[^15]. The binding is additive: "the REST API, JSON Schemas, and protocol semantics are unchanged"[^15].

5.2 Headers

Every POST against the checkout API carries the following headers, quoted verbatim from §3.1 of the Agentic Checkout RFC[^9]:

Header Required? Purpose
Authorization: Bearer <token> REQUIRED Agent identity + authorisation.
Content-Type: application/json REQUIRED on POST Wire format.
Accept-Language: <locale> RECOMMENDED Locale for Message.content.
User-Agent: <string> RECOMMENDED Agent platform identifier.
Idempotency-Key: <string> REQUIRED on all POST Opaque ≤255 chars; UUIDv4 recommended.
Request-Id: <string> RECOMMENDED Client-chosen trace ID; echoed in response.
Signature: <base64url> RECOMMENDED Detached signature over canonical JSON.
Timestamp: <RFC3339> RECOMMENDED Replay-protection window.
API-Version: 2026-01-16 REQUIRED Date-based spec version.

The Signature header uses an algorithm published out-of-band (the RFC mentions Ed25519 and ES256 as examples for delegated-payment[^16]); the server "SHOULD" validate it over the canonical JSON body plus Timestamp within a bounded clock-skew window[^9]. Webhooks from merchant to agent use an HMAC Merchant-Signature[^9][^7].

5.3 Idempotency

ACP's §6 is one of the most thoroughly specified parts of the protocol. The RFC elevates it to a "canonical reference" that "supersedes prior idempotency rules where they conflict" (SEP #120)[^9]. Equivalence is semantic JSON equality of the body only, with three non-obvious rules quoted verbatim:

"null value vs absent key — Different — null means 'clear this field'; absent means 'do not modify'. … Array element ordering — No — arrays are order-sensitive."[^9]

Replay behaviour: "Same key + identical body → server MUST return the original response with the same HTTP status code. The replayed response SHOULD include the header Idempotent-Replayed: true. Servers MUST NOT re-execute side effects (e.g., payment capture, inventory reservation) on replay"[^9]. Three error codes are standardised: idempotency_key_required (400), idempotency_conflict (422, permanent), idempotency_in_flight (409, with Retry-After)[^9]. 5xx responses are explicitly non-cached; the key must be retained for at least 24 hours[^9].

5.4 Endpoints, quoted

Create session (POST /checkout_sessions → 201) — a minimal request is just { items: [{id, quantity}] }; a full request adds buyer, fulfillment_details (name, phone, email, nested address), and optionally affiliate_attribution with touchpoint: first|last[^14][^9]. The response is an authoritative cart:

{
  "id": "checkout_session_123",
  "payment": { "handlers": [ { "id": "card_tokenized",
    "psp": "stripe", "requires_delegate_payment": true,
    "requires_pci_compliance": false,
    "config": { "accepted_brands": ["visa","mastercard","amex","discover"],
                "supports_3ds": true, "environment": "production" } } ] },
  "status": "ready_for_payment",
  "currency": "usd",
  "line_items": [ … ],
  "totals": [ {"type":"subtotal","amount":300}, {"type":"tax","amount":30},
              {"type":"fulfillment","amount":100}, {"type":"total","amount":430} ],
  "fulfillment_options": [ … ],
  "messages": [],
  "links": [ {"type":"terms_of_use","url":"…"} ]
}

(condensed from the RFC example[^9]).

Update session (POST /checkout_sessions/{id} → 200) — allows partial updates to items, fulfillment_details, or selected_fulfillment_options; returns the full authoritative state[^9].

Retrieve (GET /checkout_sessions/{id} → 200|404) — pure read, no idempotency key needed[^9].

Complete (POST /checkout_sessions/{id}/complete → 200) — this is where the SPT flows. Body contains payment_data (at minimum handler_id + instrument: { type, credential }, optionally billing_address), optional buyer, and a conditional authentication_result. The RFC is strict on 3DS:

"Server MUST set session.status to authentication_required when authentication (e.g., 3DS) is required. When status is authentication_required, the client MUST attempt authentication using the provided metadata and MUST return the authentication_result in the POST /complete request body, regardless of the authentication outcome. If a client calls POST …/complete while session.status is authentication_required and does not include authentication_result: Server MUST return a 4XX error. Server MUST set type to invalid_request, code to requires_3ds, and param to $.authentication_result."[^9]

Cancel (POST /checkout_sessions/{id}/cancel) — 200 on success, 405 when the session is already completed or canceled[^9].

Delegate payment (POST /agentic_commerce/delegate_payment → 201) — a separate endpoint hosted by whoever vaults the card (Stripe in the reference flow). The request carries a PaymentMethodCard (fpan/network_token, display fields, checks_performed: [avs, cvv, ani, auth0]), an Allowance (reason: "one_time", max_amount, currency, checkout_session_id, merchant_id, expires_at), a billing_address, and risk_signals (type: "card_testing", score, action: blocked|manual_review|authorized)[^16]. The response is a minimal { id, created, metadata } vault token[^16].

5.5 Error shape

Flat, no envelope: { type, code, message, param? } where type ∈ invalid_request | processing_error | service_unavailable | rate_limit_exceeded and param is an RFC 9535 JSONPath[^9]. Standardised error code values for Message objects include missing | invalid | out_of_stock | payment_declined | requires_sign_in | requires_3ds[^9].

6. Trust and authentication

ACP layers trust at three levels.

(a) Agent ↔ merchant transport. The merchant onboards each agent platform out-of-band, receives its bearer token and signing public key, and then verifies Authorization, Signature, and Timestamp on every POST[^9][^7]. Stripe's short security summary captures this: "All requests require HTTPS and include Authorization: Bearer {token}. Sign all webhook events and include an HMAC signature. … The agentic application must provide authorization and signing keys during onboarding"[^7]. The signature scheme is not fixed by the spec ("Server SHOULD publish acceptable signature algorithms out-of-band"[^9]); Ed25519 and ES256 are cited as plausible choices[^16]. Inferred: in the reference OpenAI/Stripe deployment this amounts to a closed allow-list of one agent (ChatGPT), with Stripe managing key rotation on the merchant side.

(b) Agent proves user authorisation. This is the conceptually hardest part of ACP and, notably, the one where ACP is less explicit than AP2. The protocol does not require a verifiable credential signed by the user (contrast AP2's IntentMandate and CartMandate — see 03-protocol-deep-dive-ap2.md). Instead, user authorisation is implicit in two mechanisms:

  1. The agent only issues the /complete request after the buyer has pressed a "buy" button inside ChatGPT's UI and the agent's own UX has surfaced the authoritative cart — the pattern OpenAI describes as users confirming "order, shipping, and payment details directly inside ChatGPT"[^2].
  2. The Allowance attached to the SPT is narrowly scoped: reason: one_time, a specific checkout_session_id, a specific merchant_id, a specific max_amount and currency, and a short expires_at window[^16]. Even if the agent were compromised mid-flight, the delegated credential could not be reused against a different merchant or for a different amount. The RFC's §2.5 is explicit: "The returned token MUST ONLY be usable within the provided Allowance… The token MUST become invalid at or after allowance.expires_at"[^16].

The authentication RFC adds a third, optional mechanism: delegated consumer authentication (3DS2, browser channel, native integration). An agent can call POST /delegate_authentication against a merchant-specified authentication provider, receive a fingerprint action, pass it back with POST /{id}/authenticate, and return the final cryptogram (three_ds_cryptogram, electronic_commerce_indicator, transaction_id, version) to the merchant as authentication_result on /complete[^17]. This lets the issuer ACS authenticate the cardholder through the agent even though the agent is not a browser.

(c) Merchant verifies agent. The bearer+signature pair is today effectively a closed allow-list. The spec foresees broader identity mechanisms (Stripe's own separate work on Web Bot Auth and Cloudflare's IETF draft are the natural complements — see 06-card-networks.md), but ACP itself does not prescribe them.

7. The SharedPaymentToken lifecycle and PCI scoping

Putting the pieces together, the Stripe SPT flow in a ChatGPT Instant Checkout runs as follows[^7][^10][^16][^9]:

sequenceDiagram
    autonumber
    actor Buyer
    participant Agent as ChatGPT (Agent)
    participant Stripe as Stripe (Token Issuer / PSP)
    participant Merchant as Merchant ACP Server

    Buyer->>Agent: "Buy that red mug"
    Agent->>Merchant: POST /checkout_sessions (items, address)\nAuthorization: Bearer, Idempotency-Key, Signature
    Merchant-->>Agent: 201 {id, status: ready_for_payment, totals, payment.handlers[card_tokenized,psp:stripe]}
    Agent->>Buyer: Render authoritative cart; ask to confirm
    Buyer->>Agent: Confirms; selects stored card
    Agent->>Stripe: POST /agentic_commerce/delegate_payment\n{payment_method:card, allowance:{reason:one_time, max_amount, checkout_session_id, merchant_id, expires_at}}
    Stripe-->>Agent: 201 {id: spt_123, created, metadata}
    alt 3DS required
        Agent->>Stripe: POST /delegate_authentication (fingerprint, challenge)
        Stripe-->>Agent: authentication_result {cryptogram, eci, ...}
    end
    Agent->>Merchant: POST /checkout_sessions/{id}/complete\n{payment_data:{handler_id:"card_tokenized", instrument:{type:"spt", credential:"spt_123"}}, authentication_result?}
    Merchant->>Stripe: PaymentIntents.create(payment_method_data[shared_payment_granted_token]=spt_123, confirm=true)
    Stripe-->>Merchant: PaymentIntent(succeeded); cloned PaymentMethod
    Merchant-->>Agent: 200 {status: completed, order:{id, permalink_url}}
    Agent->>Buyer: "Order placed!"
    Merchant-->>Agent: Webhook order_create / order_update (HMAC signed)

From a PCI-DSS scope perspective, three properties are worth highlighting. First, the agent never hands raw PAN/CVC to the merchant — the credential that flows into /complete is the opaque spt_123 reference, not card data. Second, when the merchant confirms the PaymentIntent, "Stripe sets payment_method to a new PaymentMethod cloned from the customer's original payment method. Subsequent events, such as refunds and reporting, behave as if you provided the PaymentMethod directly"[^10] — in practice this means disputes, Radar rules, Sigma reports, and Tax behave exactly as for a normal card. Third, SPT revocation is asymmetric: the agent can revoke unilaterally, and shared_payment.granted_token.deactivated fires a webhook to both sides[^10]. Inferred: this lets ChatGPT kill a token if a user withdraws consent between session creation and /complete without needing a merchant API call.

8. Comparison with AP2

ACP and AP2 are best read as complementary layers, not competitors. The clearest way to see this is to overlay their primary objects:

Concern AP2 (see §03) ACP
Top-level object Mandate (Intent / Cart / Payment), signed VC Checkout Session (REST resource)
Cryptographic trust root W3C Verifiable Credentials + DIDs, signed by user and merchant Bearer token + optional request signatures, issued out-of-band by merchant
User-authorisation proof Explicit signed CartMandate, verifiable ex-post Implicit (UI confirmation + narrow Allowance on SPT)
Payment Payment-method-agnostic — mandates can carry A2A, cards, stablecoins, etc. Card-first today (card_tokenized handler over Stripe SPT); other handlers are a roadmap item (see RFCs rfc.payment_handlers.md, rfc.seller_backed_payment_handler.md)
Focus Mandate-centric — what is the user authorising? Flow-centric — how does the cart get built and paid?
Transport A2A / MCP over JSON-RPC REST; MCP binding added in 2026-04-17
Governance Google-led, multi-partner OpenAI + Stripe as founding TSC, open to 5 more seats
Maturity / adoption Spec released Sep 16 2025; partner list, no shipping consumer product yet (as of report date) Spec and consumer product (ChatGPT) shipped Sep 29 2025; Etsy, Shopify, Walmart live or onboarding

Operationally, one can imagine a future deployment in which the buyer's agent constructs a signed AP2 CartMandate authorising a purchase, then invokes an ACP checkout session against the merchant using the mandate's payload as the items array and its Allowance as the SPT's allowance block. That stack would give the best of both: AP2 supplies the auditable user-consent primitive ACP currently lacks, and ACP supplies the live merchant-integration contract AP2 currently lacks. The rfc.delegate_authentication.md in the ACP repo and AP2's PaymentMandate are structurally reconcilable (both describe 3DS-style cryptograms carried from ACS through the agent to the merchant)[^17], so such a composition is not obviously blocked by either spec.

9. Merchant integration effort and early adopters

Because ACP reuses Stripe's existing primitives, the marginal integration effort for a merchant already on Stripe is small: implement five JSON endpoints on top of existing cart/OMS logic, add the SPT handler on the PaymentIntents side, and wire webhook delivery. Stripe lists the four integration steps almost tersely: create, update, complete, cancel; "every endpoint response includes the current state of the checkout"[^7]. Shops that already have a headless commerce backend can expose ACP as a thin adapter over their existing cart APIs.

Early adopters validate the low-friction claim:

  • Etsy (Sep 29 2025) — first live merchant; U.S.-based Etsy sellers available to U.S. ChatGPT users at launch[^2].
  • Shopify (Sep 29 2025, rolling) — "over 1 million Shopify merchants" named as the next wave, including Glossier, SKIMS, Spanx, and Vuori[^2][^3]. Shopify's participation is particularly meaningful because it implies a single platform-level adapter fans out to a long tail of small sellers.
  • Walmart (Oct 14 2025) — full corporate announcement: "Walmart announced a new partnership with OpenAI that will start with allowing customers and members to soon shop Walmart through ChatGPT using Instant Checkout"[^6]. Walmart's participation also brings Sam's Club members into the flow.

The agenticcommerce.dev FAQ spells out the operational contract for new merchants: "Any business or AI platform can implement the ACP spec to participate in agentic commerce. … If your business wants to participate in ChatGPT, you'll need to apply. … Businesses can use ACP with any compatible PSP — Stripe is the first compatible PSP with its Shared Payment Token"[^8]. That last sentence is the clearest public statement that the PSP layer is, in principle, swappable, even if only Stripe ships a handler today.

10. Limitations (only what is citable)

The following constraints are documented in public sources as of April 2026; others should be treated as inferred and flagged as such.

  • Single-item purchases only at launch. At the September 2025 rollout, Instant Checkout supports "single-item purchases"; multi-item carts were listed by OpenAI as a planned follow-up[^2]. (Note: the spec's line_items array is structurally multi-item; the constraint is on the ChatGPT product, not on ACP itself.)
  • United States only at launch. Launch geography limited both buyers and sellers to the U.S.[^2]. The Feed API uses a target_country field (default example US) — no explicit spec-level geofence, but the product is US-first[^13].
  • Card rails only in the current handler. The only requires_delegate_payment: true handler registered today is card_tokenized with psp: stripe, carrying accepted_brands: [visa, mastercard, amex, discover][^9]. A/A, stablecoin, or wallet handlers are RFC-stage (rfc.payment_handlers.md, rfc.seller_backed_payment_handler.md).
  • One agent platform in production. "OpenAI is the first AI platform to implement ACP with ChatGPT"[^8]; no other agent has shipped a public ACP integration yet. Inferred: this also means the merchant-side bearer+signature allow-list is trivially small.
  • Product feed is new. The Feed RFC is dated unreleased; the first OpenAPI-and-schema snapshot is 2026-04-17[^12][^13]. Early merchants integrated without it, using bespoke item-ID handoffs.
  • 3DS is browser-channel only (for now). The Delegate Authentication RFC limits itself to "3D Secure 2 (3DS2) authentication only, browser channel only (not app/SDK), native integration (client handles fingerprint/challenge flows, not redirect-based)"[^17]. App-SDK and redirect-based 3DS are out of scope.
  • SPT allowance is one_time only. The Delegate Payment RFC states that allowance.reason MUST be one_time[^16]. Recurring or subscription semantics are not yet covered by this handler.

Other constraints that are plausible but not explicitly cited in public sources (e.g. "no shared carts across merchants", "no partial captures") should be assumed undocumented and left for the roadmap.

11. Roadmap and governance

The ACP repository is licensed Apache 2.0, with a CLA (individual CLAs via CLA-Assistant, corporate CLAs via a signed process)[^5]. The two named maintainers are OpenAI and Stripe[^18]. Governance is formalised in docs/governance.md: a Technical Steering Committee of "up to 7 seats. Each seat is held by one organization, including OpenAI and Stripe. Seats are filled incrementally as qualified contributors emerge."[^19] The governance document lays out "Shared Principles" — mission protection, neutrality, security, protocol integrity, and considered decision-making — and states that "the Founding Maintainers' veto authority may be exercised as a last resort"[^19] to defend those principles.

Day-to-day cadence is public: a weekly TSC meeting on Thursdays with a rotating triage lead, Discord-first communication, and a SEP (Specification Enhancement Proposal) workflow with a 7-business-day community review window followed by a simple-majority TSC vote[^20]. SEPs cover "major protocol changes, breaking changes, or process changes"; minor PRs use a lighter template[^5]. Membership is reviewed quarterly, and the governance document says explicitly: "Future Path: Neutral foundation stewardship as ecosystem matures"[^5][^19] — mirroring the trajectory x402 took with the Cloudflare/Coinbase-led x402 Foundation (see 05-protocol-deep-dive-x402-and-crypto.md).

The feature roadmap can be read straight off the rfcs/ directory, which contains active proposals covering: capability negotiation, extensions, discounts, payment handlers beyond cards, seller-backed payment handlers, product feeds, orders, delegate authentication, affiliate attribution, intent traces, marketing consent, and an MCP transport binding[^5]. The 2026-04-17 snapshot operationalised product feeds, orders, authentication, cart primitives, and the MCP binding; the unreleased/ tree lists the next-up candidates. In short: ACP began as a narrowly scoped card-checkout contract and is being deliberately grown into a fuller commerce standard — with the caveat, frequently repeated in the repo's own principles, that "the protocol should evolve from actual participant needs, not speculation"[^11].

Sources

[^1]: Agentic Commerce Protocol repository, README.md: "The Agentic Commerce Protocol (ACP) is an interaction model and open standard for connecting buyers, their AI agents, and businesses to complete purchases seamlessly." Maintained by OpenAI and Stripe; status "Beta"; Apache 2.0. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/README.md

[^2]: Web search synthesis of OpenAI's launch announcement ("Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol", OpenAI, Sep 29 2025), corroborated by tertiary reporting (Yahoo/TechCrunch, PPC.land) — launch date Sep 29 2025, U.S.-only, single-item purchases only, Etsy first, 1M+ Shopify sellers next, Glossier/SKIMS/Spanx/Vuori named. https://openai.com/index/buy-it-in-chatgpt/ ; https://tech.yahoo.com/ai/chatgpt/articles/openai-partners-etsy-shopify-chatgpt-171605265.html ; https://ppc.land/openai-launches-instant-checkout-for-chatgpt-with-stripe-partnership/

[^3]: Same as [^2], Shopify merchant rollout details.

[^4]: Stripe Newsroom, "OpenAI chooses Stripe to power payments" (March 2023): "OpenAI has chosen Stripe to power payments as it moves to commercialize its groundbreaking ChatGPT and DALL·E generative AI technologies." https://stripe.com/newsroom/news/stripe-and-openai

[^5]: agentic-commerce-protocol/agentic-commerce-protocol repository structure, including spec/{2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30, 2026-04-17, unreleased}/, rfcs/, docs/, legal/cla/, and Apache-2.0 LICENSE. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol

[^6]: Walmart corporate newsroom, "Walmart partners with OpenAI to create AI-first shopping experiences" (14 October 2025); quoted statements from Doug McMillon and Sam Altman. https://corporate.walmart.com/news/2025/10/14/walmart-partners-with-openai-to-create-ai-first-shopping-experiences

[^7]: Stripe Docs, "Agentic Commerce Protocol": checkout lifecycle, four endpoints, event model, security guidelines. https://docs.stripe.com/agentic-commerce/protocol

[^8]: agenticcommerce.dev landing page and FAQ: MoR retention, agent neutrality, Stripe as first compatible PSP, OpenAI as first agent. https://agenticcommerce.dev/

[^9]: rfcs/rfc.agentic_checkout.md — endpoint lifecycle, headers, idempotency rules, data model, validation, 3DS semantics, example Create request/response. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.agentic_checkout.md

[^10]: Stripe Docs, "Shared Payment Tokens" — SPT object, usage_limits, granted-token lifecycle, PaymentIntent confirmation, cloned PaymentMethod semantics, shared_payment.granted_token.deactivated webhook. https://docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens

[^11]: docs/principles-mission.md — ACP mission and core principles (Trust/Security/Compliance; Built for Real-World Use; Open and Neutral; Agile). https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/principles-mission.md

[^12]: rfcs/rfc.product_feeds.md — motivation, user journeys, role of feeds vs checkout authority. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.product_feeds.md

[^13]: spec/2026-04-17/openapi/openapi.feed.yaml — Feed API endpoints and FeedMetadata schema. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.feed.yaml

[^14]: spec/2026-04-17/openapi/openapi.agentic_checkout.yaml — OpenAPI 3.1 spec, version 2026-04-17, bearer auth. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/spec/2026-04-17/openapi/openapi.agentic_checkout.yaml

[^15]: docs/mcp-binding.md — MCP transport binding: /.well-known/acp.json discovery, transports: ["mcp"], Streamable-HTTP, five operation-to-tool mapping. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/mcp-binding.md

[^16]: rfcs/rfc.delegate_payment.md — POST /agentic_commerce/delegate_payment, PaymentMethodCard schema, Allowance constraints (reason, max_amount, currency, checkout_session_id, merchant_id, expires_at), RiskSignal, idempotency rules, security considerations. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_payment.md

[^17]: rfcs/rfc.delegate_authentication.md — 3DS2 delegated authentication, browser channel, native integration; endpoints /delegate_authentication, /{id}/authenticate, /{id} retrieve; cryptogram/ECI/transaction_id fields. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/rfcs/rfc.delegate_authentication.md

[^18]: MAINTAINERS.md — "Lead maintainers: OpenAI; Stripe." https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/MAINTAINERS.md

[^19]: docs/governance.md — TSC composition, shared principles, veto authority, membership criteria, current TSC seat list (OpenAI: aravindrao-openai; Stripe: prasad-stripe). https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/governance.md

[^20]: docs/operating-model.md — TSC operating model: Thursday weekly meeting, triage rotation, Discord channels, SEP lifecycle, quarterly membership review. https://github.com/agentic-commerce-protocol/agentic-commerce-protocol/blob/main/docs/operating-model.md