Agentic Commerce Protocol (ACP)

The Agentic Commerce Protocol is OpenAI and Stripe's approach to AI agent commerce. Where the other protocols invest in credential chains, composable capabilities, or verifiable credentials, ACP takes a more direct path: an API-driven checkout session that delegates payment to Stripe.

Architecture

ACP's design reflects its creators' strengths. OpenAI brings the agent ecosystem. Stripe brings payment infrastructure. The result is a protocol optimized for getting from "the agent wants to buy something" to "the payment is processed" with minimal ceremony.

Discovery

Merchants publish an /.well-known/acp.json manifest describing their available checkout endpoints and supported capabilities. Like UCP's discovery mechanism, this allows agents to find and interact with merchants without prior integration.

Authentication

ACP uses bearer token authentication. An agent authenticates to a merchant's ACP endpoint by including a bearer token in the request header. This is the simplest authentication model among the four protocols — no credential chains, no HTTP message signatures, no OAuth2 flows.

Simplicity is a feature for adoption. Bearer tokens are understood by every developer and supported by every HTTP client. They are also the weakest authentication model in the group — a bearer token proves possession of the token, not the identity of the bearer.

Capabilities Negotiation

Before initiating a checkout, the agent and merchant negotiate supported capabilities. The capabilities object describes what the merchant supports — payment methods, shipping options, return policies — and what the agent can handle. This negotiation ensures both parties agree on the interaction's parameters before committing.

The Checkout Session

ACP's core abstraction is the checkout session. A checkout session encapsulates the full transaction:

1. Creation: Agent requests a new checkout session from the merchant
2. Configuration: Items, quantities, shipping details, and payment method are specified
3. State lifecycle: The session moves through defined states — pending, completed, canceled, or expired
4. Payment delegation: Payment is handled via delegate_payment, routing to Stripe

The session model is straightforward. There is one object (the session), one lifecycle (creation to completion), and one payment path (Stripe). The agent does not need to manage multiple API resources or coordinate between separate cart, checkout, and payment services.

Secure Payment Tokens

ACP uses Secure Payment Tokens (SPTs) for tokenized payment. Rather than passing raw payment credentials, the agent provides an SPT that represents a tokenized payment method within Stripe's infrastructure. This keeps sensitive payment data within Stripe's PCI-compliant environment and out of the agent-merchant communication channel.

Identity Model

ACP's identity model is minimal by design.

What it covers:

• Agent authentication: Bearer tokens identify the agent to the merchant for the duration of the session
• Payment identity: Stripe's customer and payment method records provide payment-layer identity

What it does not cover:

• Human identity: ACP does not define how the human behind the agent is identified or how their authorization is verified. The assumption is that the agent platform (OpenAI) has handled user authentication, but ACP itself does not carry that proof.
• Merchant identity: Beyond the /.well-known/acp.json manifest served from a domain, ACP does not define merchant identity verification. There is no equivalent to VI's issuer-verified credentials or AP2's VDCs.
• Entity authority: No mechanism for verifying organizational authorization
• Persistent identity: Bearer tokens are session-scoped. There is no identity that persists across sessions or accumulates history.

What ACP Handles Well

ACP's strength is simplicity. The checkout session model is easy to understand, easy to implement, and easy to debug. For the most common case — an AI agent making a straightforward purchase — ACP provides the shortest path from intent to completed payment.

The Stripe integration is a genuine advantage. Stripe's payment infrastructure handles PCI compliance, fraud detection, multi-currency support, and payment method management. By delegating payment to Stripe rather than building a new payment layer, ACP inherits decades of payment engineering.

SPTs solve a real problem. Agent-to-merchant communication should not carry raw payment credentials. Tokenization keeps sensitive data within the payment processor's security boundary.

For developers already building on OpenAI's platform and accepting payments through Stripe, ACP requires minimal new infrastructure. This is a significant adoption advantage.

What ACP Defers

ACP is completely silent on dispute resolution. The specification does not mention disputes, chargebacks, refunds processes, or any post-purchase conflict mechanism. This is not a deferral with acknowledgment (like VI's Section 2.4) or a deferral with a stated philosophy (like AP2's "follow existing regulations"). It is an absence.

In practice, disputes in ACP transactions would fall to Stripe's existing dispute handling — the standard chargeback process familiar to any merchant using Stripe. This works for simple consumer purchases. It does not scale to:

• Agent-to-agent disputes: When both parties are AI agents, who initiates the chargeback? Who responds to evidence requests?
• Complex transactions: Multi-item orders with partial fulfillment, services with subjective quality criteria, or digital goods with licensing terms
• Cross-border enforcement: Stripe operates globally, but chargeback rules vary by card network, issuing bank, and jurisdiction

ACP also defers:

Identity beyond tokens: Bearer tokens establish session-level authentication. They do not create persistent identity, verifiable delegation chains, or trust credentials. An agent using ACP cannot prove to a merchant that it is authorized by a specific human, that it operates within specific constraints, or that it has a history of successful transactions.

Agreement lifecycle: The checkout session is a single transaction. It begins, it completes (or expires or is canceled), and it ends. There is no mechanism for ongoing obligations, subscription management, or multi-phase commitments.

Jurisdictional framework: ACP is jurisdiction-agnostic. Stripe's terms of service provide some jurisdictional structure for the payment, but the commerce interaction itself — what was promised, what was delivered, what remedies apply — has no jurisdictional anchor within the protocol.

The Simplicity Tradeoff

ACP makes a clear architectural choice: minimize complexity at the protocol layer and rely on existing infrastructure (Stripe, OpenAI's platform, standard web security) for everything else. This is a valid strategy for bootstrapping adoption. It is also a strategy that defers the hardest problems to infrastructure that was not designed for agent commerce.

Stripe's dispute handling was designed for human merchants and human customers. OpenAI's platform authentication was designed for API access, not for verifiable delegation of purchasing authority. Standard web security was designed for browser-based interactions, not for autonomous agents making binding commitments.

ACP will likely need to address these gaps as agent commerce matures. The question is whether the protocol evolves to handle them directly or whether complementary layers — like Integra's identity and dispute infrastructure — fill the gaps from below.