Agent commerce has the same problem the early web had: it works, but only because two or three big players agreed on the basics. As of 2026, the basics in agent commerce are encoded in two open specifications: the Agentic Commerce Protocol (ACP), jointly published by OpenAI and Stripe, and the Agent Payments Protocol (AP2), led by Google with a wide list of co-authors.
Both are real, both are being adopted, and they overlap enough that engineers building agent integrations need to understand the relationship. This article breaks down what each protocol actually specifies, where they agree, where they diverge, and how to plan an integration that won't need to be rewritten in twelve months.
What These Protocols Are Trying to Solve
When an AI agent buys something for a user, four parties are involved: the user, the agent platform (ChatGPT, Claude, Gemini, etc.), the merchant, and the payments provider (Stripe, Adyen, PayPal, a card network).
The hard problems that need standardizing:
- Authorization. How does the merchant know the agent has the user's permission to make this specific purchase, within these specific limits?
- Identity. How does the merchant know which agent platform is reaching out, and that it's a legitimate one?
- Payment binding. How does payment information get safely from the user's wallet of record to the merchant, without exposing it to the agent?
- Receipts and disputes. How do all parties record what happened so disputes, refunds, and reorders work?
Without a standard, every merchant has to build a bespoke integration with every agent platform — exactly the problem early payment APIs solved twenty years ago. Both ACP and AP2 are attempting to solve it, with somewhat different scopes and design philosophies.
The Agentic Commerce Protocol (ACP)
Published by OpenAI and Stripe in 2025, ACP is the first protocol to ship with both real merchant adoption and real consumer-agent volume behind it.
What ACP Specifies
ACP is, structurally, a set of APIs and webhooks that define how an agent and a merchant exchange the information needed to complete a transaction. The core concepts:
- The agent presents a
delegated_paymentartifact — a cryptographically signed object that proves the user has authorized this agent to spend up to a stated limit at this merchant or merchant category. - The merchant exposes an ACP-compliant checkout endpoint that accepts a cart, the delegated payment artifact, and standard line-item data.
- The PSP (typically Stripe in launch implementations) issues a Shared Payment Token that the merchant charges through their existing integration. The token is single-use and bound to the cart.
- Receipts and disputes flow back to the agent and user through standard webhook events that ACP defines.
The protocol explicitly assumes a card-network or PSP-mediated payment in the background. It's not trying to replace the card rails — it's defining the connective tissue between the agent and the existing payment infrastructure.
Who's on ACP Today
OpenAI's "Buy in ChatGPT" experience runs on ACP. Stripe's Agent Toolkit speaks ACP natively. Shopify integrated ACP into Universal Cart. Perplexity, Vercel, and several large retailers (Walmart, Etsy partners, and others have publicly mentioned it) implemented it in 2025. The list of adopting merchants and PSPs continued to grow through early 2026.
ACP's strength is that it shipped first, with a working consumer agent (ChatGPT) sending real money through it on day one. That's a different bar than a published spec without a flagship implementation.
The Agent Payments Protocol (AP2)
Announced by Google in 2025 with a broad coalition that included American Express, Mastercard, PayPal, Coinbase, Salesforce, ServiceNow, Adyen, Worldpay, and dozens of others — though notably not Stripe and OpenAI — AP2 is the more ambitious, more abstract, and more multi-party of the two protocols.
What AP2 Specifies
AP2's central abstraction is the Mandate — a structured, cryptographically signed authorization from a user to an agent that defines what the agent is allowed to do. AP2 distinguishes:
- Intent Mandates — high-level user goals ("book me a flight to Tokyo under $1,500 for next month")
- Cart Mandates — specific carts the agent has assembled, signed both by the agent and (where applicable) by the user
- Payment Mandates — the authorization to actually move money for a given cart
The protocol is designed to be payment-method-agnostic. AP2 specifies the same mandate structure whether the underlying rail is a card network, ACH, a stablecoin like USDC over Coinbase's x402, or a future payment method that doesn't exist yet. That's a meaningful design choice — ACP assumes a card-network/PSP payment path, while AP2 treats payment as a pluggable layer.
AP2 also leans more heavily on decentralized identity primitives, including verifiable credentials and decentralized identifiers (DIDs), to make agent and user identity portable across platforms.
Who's on AP2 Today
Google's Gemini and Agent Builder products speak AP2. The card networks Mastercard and American Express have implemented it. PayPal, Adyen, Worldpay, and several other PSPs ship AP2 support. Salesforce Agentforce and ServiceNow's enterprise agents use AP2 for B2B agent transactions. Coinbase ties AP2 to x402 for stablecoin-denominated agent payments.
AP2's strength is breadth. The list of adopting parties is wider than ACP's, especially in enterprise and non-card-network rails.
Where They Agree
Despite the marketing positioning, ACP and AP2 agree on more than they disagree on:
- Tokenization, not raw card data, exposed to agents
- Cryptographically signed user authorization as the core trust artifact
- Scoped permissions (spend limit, merchant, category, expiry)
- Verifiable agent identity so merchants can distinguish trusted agents from scrapers
- Standard receipt and dispute flows back to the agent and user
A merchant who supports either protocol is, in effect, supporting most of the same trust and authorization model as a merchant who supports the other.
Where They Differ
The substantive differences:
| ACP (OpenAI/Stripe) | AP2 (Google + coalition) | |
|---|---|---|
| Payment rail assumption | Card-network / PSP first | Rail-agnostic (cards, ACH, stablecoin, future) |
| Identity model | Federated, agent-platform-vetted | Decentralized identifiers, verifiable credentials |
| Mandate granularity | Single delegated-payment artifact per cart | Three-tier (intent → cart → payment) mandates |
| Reference implementations | OpenAI ChatGPT, Stripe, Shopify, Perplexity | Google Gemini, Mastercard, Amex, PayPal, Adyen, Salesforce, Coinbase |
| Crypto/stablecoin native | No (separate path) | Yes (via Coinbase x402 integration) |
| B2B mandate granularity | Less developed | More developed |
The simplest way to think about it: ACP optimizes for shipping a great consumer card-payment experience between major agents and major merchants right now. AP2 optimizes for being the long-term substrate for any agent paying any merchant on any rail, including ones not yet invented.
Neither is wrong. They reflect different bets about how agent commerce will evolve.
Will They Converge?
Almost certainly. Public statements from both camps in late 2025 and early 2026 have acknowledged the overlap and signaled willingness to align. The most likely paths:
- A compatibility shim that lets a merchant implement one protocol and accept transactions from agents using the other. This is the easiest near-term outcome and mostly a matter of mapping fields between ACP's
delegated_paymentand AP2's mandate structure. - A merged spec under a neutral standards body — likely the W3C Web Payments group, EMVCo, or a new joint foundation. This is the more durable path but slower; expect 12–24 months at minimum.
- Two specs continue to coexist, with ACP dominating consumer LLM commerce on card rails and AP2 dominating enterprise agents and non-card rails. Less elegant, but workable, and not unprecedented (compare REST and GraphQL).
The realistic 2026 outcome is some version of (1) and (3) running in parallel.
What Merchants and Developers Should Do Now
Concrete recommendations:
If you're a consumer e-commerce merchant on Stripe or a Stripe-compatible PSP: Implement ACP first. The path is the shortest, the agent traffic is the largest today (ChatGPT, Perplexity), and the integration work is mostly accepting Stripe Shared Payment Tokens at checkout.
If you're an enterprise SaaS or B2B platform: Implement AP2. Your buyers' agents are more likely to be Salesforce Agentforce, ServiceNow, Microsoft Copilot, or vertical procurement agents — and the AP2 mandate structure handles purchase orders, approval chains, and budget controls more naturally than ACP.
If you're a marketplace or have to support both worlds: Pick the protocol that matches your dominant traffic source today, and plan to add the other within 12 months. Architect your checkout layer so the protocol-specific code is isolated; the underlying business logic (cart, inventory, fulfillment) shouldn't have to care.
If you're a payment infrastructure provider: You almost certainly need both, and you should be loud about saying so. Acquirers, gateways, and PSPs that support only one protocol will struggle as merchants demand a single integration that handles whichever agent shows up.
If you're an agent developer: Use the SDKs that speak the protocol your target merchants accept. Stripe's Agent Toolkit and Vercel's AI SDK make ACP near-trivial. Google's Agent Builder and the AP2 reference SDKs do the same for AP2. Don't roll your own protocol implementation in 2026 — too much will change.
The Stakes
Standards moments are durable. Whichever set of protocols becomes the default for agent commerce will shape merchant integration patterns, fraud models, and platform power dynamics for the next decade — the way the W3C Web Payments specs, OAuth, and EMV 3DS shaped their respective categories.
The encouraging news is that both ACP and AP2 are open, both are real, and both have meaningful production traffic. The unencouraging news is that "supporting both" is genuinely the right answer in 2026, and that adds engineering cost. Plan for it; the alternative is being invisible to a meaningful slice of the agent traffic that's already showing up on your storefront.
StartShop's commerce platform supports both ACP and AP2 out of the box, so merchants can accept agent traffic from any major platform without bespoke integration.