ACP vs MCP vs A2A: how AI agents actually buy things
MCP (Anthropic) is agent↔tool. ACP (Stripe/OpenAI) is agent↔payment. A2A (Google) is agent↔agent. For most agent-commerce implementations in 2026, MCP alone is enough — the tool returns a Stripe URL, the human clicks. Add ACP when you want the agent to spend inside a pre-authorized envelope without per-transaction clicks. A2A is nascent; skip it until two independent agents need to negotiate. They don't compete; they stack.
Every week a founder emails me: "Should I build on MCP, ACP, or A2A?" The framing is wrong. These aren't competitors. They're layers.
Here's the field guide I wish existed when I started.
The one-line summary
| Protocol | Owner | Job | You need it when… |
|---|---|---|---|
| MCP | Anthropic (2024) | Agent calls a tool | You want an agent to search, read, or take action on your API. |
| ACP | Stripe + OpenAI (2025) | Agent completes a payment | You want the agent to charge without a per-transaction human click. |
| A2A | Google (2025) | Agent talks to another agent | You have two independent agents (buyer's + seller's) that need to negotiate. |
Notice the columns don't overlap. MCP doesn't handle payment. ACP isn't a tool-calling protocol. A2A doesn't dictate how either agent talks to its own tools.
MCP: the tool layer
Model Context Protocol was Anthropic's answer to "how does an agent connect to my system?" An MCP server exposes tools (functions the agent can call) and resources (data the agent can read). The transport is JSON-RPC over stdio or HTTP.
For commerce, the tools look like:
search_esim_plans(country, min_data_gb, min_days) -> [Plan]
get_checkout_link(sku, buyer_email) -> { url }
get_order_status(order_id) -> { status, fulfillment }The agent picks a plan, calls get_checkout_link, and hands the URL back to the user. The user clicks and pays on Stripe. The agent never sees a card. That's the consent-first pattern the whole industry landed on in 2026.
MCP is by far the most widely deployed of the three. Claude Desktop, Claude Code, Cursor, Zed, and a growing list of ChatGPT integrations all speak it. If you ship exactly one protocol, ship MCP.
ACP: the payment layer
Agentic Commerce Protocol is Stripe and OpenAI's joint answer to "how does the agent charge without a click every time?"
The user signs one broader consent up front, called a Shared Payment Token or equivalent:
I authorize this agent to spend up to $50/month on mobile top-ups for phone number +8618xxxxxxxx.
Inside that envelope the agent presents the token instead of a URL, and the charge completes. Outside the envelope (different category, over the cap, past the time window) the token is rejected and the agent has to fall back to a fresh consent flow.
ACP layers on top of MCP — an MCP checkout tool can return either a URL (consent-first) or accept a payment token (ACP). Cartapi will do both; they aren't in tension.
ACP is the right answer for high-frequency, low-value flows (a $1 top-up daily, an API-credit refill hourly). It's overkill for a one-off eSIM purchase where the click is invisible anyway.
A2A: the agent layer
Agent-to-Agent is Google's answer to "what if two agents need to talk?"
Imagine a buyer's personal agent messages a seller's storefront agent: "I need 10GB in Thailand for a week, budget $8." The storefront agent replies with options. They negotiate on price, warranty, delivery. Eventually one of them calls a payment protocol (probably ACP) to close the deal.
A2A defines the envelope for that conversation — message shape, capability discovery, task lifecycle. It doesn't say what the agents can do; it says how they announce and coordinate.
In August 2026 the production surface is thin. Google's own agents use it internally, a handful of enterprise pilots exist, but the buyer-side agent ecosystem hasn't caught up. Most commerce today is user↔agent↔tool, not agent↔agent. A2A becomes interesting when the buyer's side is autonomous enough to negotiate — which is a 2027 story, not a 2026 one.
How they stack
The clearest way to think about it:
- A2A — how agents find each other and coordinate a task.
- MCP — how each agent talks to its own tools and data.
- ACP — how the payment inside that task actually clears.
A full future purchase looks like: buyer's agent (via A2A) finds seller's agent → seller's agent (via MCP) searches its catalog and returns options → buyer's agent picks one → ACP payment token clears the charge → seller's agent (via MCP again) fulfills the order.
Today, most of the middle layer collapses: the user runs the buyer's agent directly, so A2A is unused; MCP does the tool call; consent-first URL replaces ACP because it's simpler. That's fine. Ship what you need.
What to ship first
- Ship MCP. One HTTP endpoint, a tool list, JSON-RPC over Streamable HTTP. This unlocks Claude Desktop, Claude Code, Cursor, and any custom SDK loop. Skip nothing on this step.
- Return consent-first URLs. Not card fields. Not tokens. URLs. Signed, short-lived, single-use.
- Add ACP when the click hurts. If your product is high-frequency low-value, wire ACP as a second checkout path. Keep the URL path as the fallback.
- Ignore A2A until a real buyer-side agent shows up asking to negotiate. It will happen; it hasn't yet at any scale that matters.
Where cartapi sits
Cartapi's live surface is MCP + consent-first URLs. ACP is wired in the code, waiting on Stripe Shared Payment Tokens for general availability. A2A isn't on the roadmap because cartapi is a seller-side API, not an agent — A2A support (if it matters) would be added by the buyer's-side agent connecting to us.
Connect and see for yourself:
claude mcp add --transport http cartapi https://mcp.cartapi.io/mcpusing cartapi, top up +8618xxxxxxxx with about ¥50 of airtime.
Frequently asked questions
What is the difference between MCP, ACP, and A2A?
MCP (Anthropic) is how an agent connects to a tool or data source. ACP (Stripe/OpenAI) is how an agent completes a purchase inside a pre-authorized envelope. A2A (Google) is how two agents talk to each other. Different layers: agent↔tool, agent↔payment, agent↔agent.
Do I need all three protocols to ship agent commerce?
No. MCP alone is enough for consent-first checkout. Add ACP when you want the agent to complete purchases inside a pre-signed spending envelope without a per-transaction click. Add A2A only if two independent agents need to negotiate — a nascent use case in 2026.
Which protocol does cartapi implement?
Live: MCP with consent-first URL checkout at mcp.cartapi.io/mcp. In progress: ACP, pending Stripe Shared Payment Tokens rollout. Not on the roadmap: A2A (cartapi is seller-side infrastructure, not an agent).
Will these protocols merge?
Unlikely near-term. Different vendors, different economic motives. Longer-term, expect A2A and MCP to interoperate (A2A messages carrying MCP tool invocations) and ACP to become the payment layer any commerce interaction calls into. Google's Universal Commerce Protocol may be the eventual unifier.
Is MCP or ACP more secure?
Different threat models. MCP with consent-first URLs bounds a prompt-injection at zero (bad URL, user declines). ACP bounds a prompt-injection at the envelope cap (bad purchase inside your $50/month, category-restricted budget). Both are safe if you configure them correctly; both fail identically if you hand the agent an unbounded credential.