Three competing standards. Zero consensus. Here's what I found after trying to wire up real payments for our AI agents.
We've been building agent-wallet-sdk for a few months now — a payment primitive specifically for autonomous AI agents. The kind of agents that need to pay for APIs, hire other agents, or hold crypto without a human co-signing every transaction.
When we started, the answer to "how do agents pay for things?" was basically: use a custodial wallet and hope for the best. That answer got a lot more complicated very quickly.
Right now there are three serious contenders trying to own agent payments:
- x402 — HTTP-native micropayments via the long-dormant 402 status code
- ACP — Agent Commerce Protocol, the OpenAI/Stripe joint effort
- UCP — Unified Commerce Protocol, Google/Shopify's angle on agent commerce
They are NOT the same thing solving the same problem. That's the part most explainers get wrong.
x402: The One That Actually Works Today
The 402 HTTP status code has been in the spec since 1996. "Payment Required." Never implemented. Coinbase revived it, and the result is something genuinely clever — when an agent hits a paywalled API endpoint, the server responds with a 402 plus a payment header specifying amount, currency, and network. The agent pays, gets a receipt header, and the request succeeds.
No intermediary. No escrow. No 3-day settlement.
Here's what a server-side 402 response looks like:
HTTP/1.1 402 Payment Required
X-Payment-Required: {"amount":"0.001","currency":"USDC","network":"base","address":"0x..."}
And on the agent side, using our SDK:
import { AgentWallet } from '@agenteconomy/pay';
const wallet = new AgentWallet({
privateKey: process.env.AGENT_PRIVATE_KEY,
network: 'base'
});
const response = await wallet.fetch('https://api.example.com/data', {
maxPayment: '0.01 USDC' // agent won't pay more than this
});
That's it. The wallet handles the 402, signs the USDC transfer on Base, and retries the request with a payment receipt. The whole round-trip takes under 2 seconds.
What x402 gets right: it's HTTP-native, meaning any existing API can add 402 support without changing its architecture. What it gets wrong — and this is a real limitation — is that it's purely payment transport. It doesn't handle agent identity, permissions, or multi-agent coordination at all. If your agent needs to negotiate a rate or split a payment across three agents, x402 has nothing to say about that.
For solo builders without a corporate partnership, x402 is the obvious choice right now. It's live on mainnet. Real APIs are already implementing it. The tooling exists.
ACP: The Enterprise Play
ACP — Agent Commerce Protocol — came out of the OpenAI/Stripe partnership late last year. It's a significantly more ambitious spec than x402, which is both its strength and its problem.
ACP handles the full commerce lifecycle: agent identity verification, payment authorization, dispute resolution, refunds, escrow for multi-step transactions. Think of it as what would happen if Stripe designed a payment standard for agents from scratch, knowing agents are autonomous and can't pick up the phone if something goes wrong.
The identity layer is genuinely useful. ACP agents have cryptographic identities that can accumulate reputation — merchants can see that an agent has completed 500 successful transactions before they fulfill a $10,000 order. That doesn't exist anywhere in x402.
The catch: ACP is still in draft. The spec is available, reference implementations are shipping, but there's no production-grade open-source SDK for it today. If you're not already a Stripe partner with enterprise support, you're building on quicksand.
We tested it in January. The spec is well-designed. The tooling isn't there yet.
UCP: The Commerce-First Angle
UCP came from the Google/Shopify ecosystem and has a very specific thesis: agents are going to be major consumers, and the existing commerce infrastructure (carts, checkout, returns, merchant APIs) should be upgraded to speak agent natively rather than built around crypto rails.
UCP is less about crypto and more about extending REST commerce APIs with agent-specific headers for authentication, intent signaling, and budget constraints. A UCP-compliant Shopify store can serve both human shoppers and agent buyers using the same backend.
Interesting idea. Genuinely useful for e-commerce agents. Mostly useless if your agent is paying for APIs, data feeds, or other agent services — which is the more interesting category to us.
What We Actually Use
We built agent-wallet-sdk on x402. Specifically on USDC on Base — sub-cent fees, 2-second finality, and a real ecosystem of APIs already implementing 402 support.
Here's our read on the decision tree:
Use x402 if:
- You're building a solo project or small team setup
- Your agent pays for APIs, data, or compute
- You want something production-ready today
- You're comfortable with crypto rails (USDC on Base specifically)
Watch ACP if:
- You're building for enterprise deployment
- Multi-agent trust and identity matter as much as payment
- You're already in the Stripe/OpenAI orbit
- You can wait 6-12 months for the spec to stabilize
Use UCP if:
- Your agent is a buyer in traditional e-commerce
- You're integrating with Shopify or Google Shopping
- Crypto is a deal-breaker for your use case
The honest answer is that these three protocols will probably coexist — they're solving different layers of the same problem. x402 is transport. ACP is identity + commerce. UCP is e-commerce integration. Long term, I'd expect ACP to absorb x402 semantics and add the identity layer on top. But "long term" in AI infrastructure means 18-24 months, and a lot of production agents need to pay for things today.
ERC-8004: The Missing Layer Nobody's Talking About
One thing that x402 doesn't handle and ACP handles inconsistently: multi-agent trust.
When Agent A hires Agent B, who authorizes the payment? What prevents Agent B from charging whatever it wants? ERC-8004 — the trust standard for multi-agent transactions — is addressing this at the smart contract layer. It's not a payment protocol itself, but it's the authorization layer that makes large-scale agent-to-agent commerce possible.
Our wallet SDK wraps ERC-8004 spend limits by default. An agent spawning subagents can set hard budget caps on what each subagent can spend — enforced at the contract level, not by trusting the subagent's self-reported costs.
This is the piece that keeps getting left out of "agent payments" discussions. The payment is the easy part. The authorization hierarchy — who can spend what, on behalf of whom, with what limits — that's the hard part.
Try It Yourself
If you want to add x402 payments to your agent:
npm install @agenteconomy/pay
The README has a working example with a live testnet endpoint you can hit immediately — no setup required.
If you're evaluating ACP or have tried UCP in production, I'd genuinely like to know what you found. Drop it in the comments. The space moves fast enough that what I wrote above might already be outdated by the time you're reading this.
Top comments (1)
Interesting comparison, but I think the discussion is still framing the problem at the wrong abstraction layer.
x402, ACP, and UCP are not really competing protocols in the strict sense. They operate at different layers of what will eventually become the agent commerce stack.
x402 is essentially a transport primitive. It answers a very narrow question: how does an HTTP request become conditionally payable. From a systems perspective it is almost analogous to TCP adding congestion semantics to IP. Extremely useful, but intentionally minimal.
ACP is attempting something completely different. It is defining the economic identity layer for agents: authentication, reputation accumulation, escrow semantics, and dispute resolution. In other words, it tries to solve the coordination problem that appears once agents start interacting economically at scale.
UCP, on the other hand, is not really an agent protocol at all. It is an extension of existing commerce APIs so that automated buyers can interact with traditional merchant infrastructure. That makes sense for retail workflows but does not address the emerging machine-to-machine economy.
The real unsolved problem is exactly what you hinted at near the end: authorization hierarchies.
Payment itself is trivial. Signing a transfer is a solved problem.
What is not solved is the spending authority model when agents recursively spawn subagents, negotiate contracts, or compose services dynamically. At that point the system stops being a payment protocol and becomes a distributed capability system.
If agent economies actually materialize, the stack will likely converge toward something like:
transport layer (x402-style conditional requests)
identity and trust layer (ACP-like agent identities)
capability and spending delegation (ERC-8004 or something equivalent)
domain integration layers (UCP-style commerce APIs)
Right now the ecosystem is debating “which protocol wins”, but the more interesting question is how these layers compose without turning agent commerce into a centralized gatekeeper system.
Curious to see how agent-wallet-sdk evolves here. The spend limit model around ERC-8004 is a step in the right direction because it starts treating agents as economic actors with bounded authority rather than just wallets with code attached.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.