x402 vs AP2 vs ACP: Three Agent-Payment Standards, One Attribution Problem

x402 vs AP2 vs ACP: Three Agent-Payment Standards, One Attribution Problem

AI agents are starting to spend money. Not in simulations — in production. They call paid APIs, buy compute, and pay for data. Three competing protocols emerged in 2025–2026 to standardize that payment flow:

• x402 — Coinbase + Cloudflare. Revives the HTTP 402 status code. Settles USDC on Base or Solana in ~2 seconds. Crypto-native.
• ACP — Agentic Commerce Protocol. Stripe + OpenAI. Credit-card rails with enhanced authorization for agents. Traditional payments reimagined.
• AP2 — Agent Payments Protocol. Google. Enterprise-grade authorization framework for agent-initiated transactions. Protocol-agnostic on the rail layer.

Each solves the "let an agent pay" problem in a slightly different way. But they all produce the same downstream headache: how do you measure whether that spend was worth it?

This post compares the three from an attribution and analytics perspective — because picking a payment standard is also picking a measurement problem.

The three standards at a glance

The differences look like engineering trivia. They're not. The fee model sets which business models are viable. The data visibility sets what you can measure.

The attribution gap, three ways

All three standards let an agent pay. None of them, out of the box, tell you which agent spend produced which business outcome. That's the attribution problem — and each rail exposes it differently.

x402: transparent ledger, missing outcome layer

x402 payments are USDC transfers on public chains. Every agent spend is a transaction with a sender address, a recipient address, an amount, and a timestamp. You can pull that data from any block explorer or indexer.

What's missing: the link from agent wallet → business outcome. The chain tells you that Agent A spent $12.40 on Exa search API calls this week. It doesn't tell you whether those searches produced a research report that closed a deal.

Building attribution on x402 looks like building attribution for a regular wallet — register the wallet, tag it with a workflow ID, define success events, link spend to outcomes. The primitives already exist in on-chain attribution tools; agent wallets are just wallets.

ACP: locked data, mature tooling

ACP payments live inside Stripe. Stripe's dashboard already breaks down transactions by customer, product, and time. You get merchant-grade reporting out of the box — refunds, chargebacks, failed authorizations.

What's missing: openness. If your agent is paying a dozen services, each service has its own Stripe (or competitor) merchant account. You see your agent's outgoing charges in one place if you're the buyer, but your service providers' reporting is proprietary. You can't aggregate across providers without integrating each one. Cross-provider attribution requires manual plumbing.

AP2: strong authorization, weakest analytics story

AP2's emphasis is authorization and identity. Who authorized the agent to spend? On what terms? For what purpose? It's an enterprise answer to an enterprise question.

What's missing: measurement. AP2 defines the control plane ("Agent X may spend up to $100/month on research APIs"), not the measurement plane. You get a strong audit trail of authorized spend, but whether that spend produced ROI is out of scope.

Choosing based on what you need to measure

The x402 advantage for measurement isn't a feature of the protocol — it's a consequence of the rail. Public ledgers are composable. Anyone can index them. Any service can build attribution on top without permission.

What "agent attribution" actually looks like

Regardless of protocol, the attribution framework is the same:

1. Register the agent's identity. Wallet address for x402. Customer ID for ACP. Agent credential for AP2.
2. Track outbound spend. USDC outflows for x402 (on-chain, free). Stripe charges for ACP (merchant dashboard). Authorization-artifact ledger for AP2.
3. Define the success event. A completed report, a profitable trade, a resolved support ticket, a generated lead. Assign it a revenue value.
4. Link spend to outcome. Per-agent, per-workflow, per-time-period. Compute cost-per-action, ROI, spend-to-outcome ratio.

The hard part isn't step 4. It's step 2 and step 3. x402 makes step 2 trivial (public ledger). ACP makes step 3 trivial (merchant-dashboard conversion tracking). AP2 makes neither trivial but adds strong step 1.

The next 12 months

Our read:

• x402 wins in agent-to-API payments where micropayment economics matter. Sub-cent payments are impossible on card rails.
• ACP wins for agents buying from existing businesses that already accept Stripe. Zero-engineering adoption beats cryptographic purity for 80% of use cases.
• AP2 wins in enterprise environments where authorization policy matters more than rail fees. Procurement departments will care.

All three will coexist. A single agent might pay x402 for data APIs, ACP for a SaaS subscription, and AP2 for a regulated financial transaction — in the same workflow.

The measurement layer is what holds this together. It has to be rail-agnostic, or you end up with three disconnected views of what your agents are doing.

Further reading

• How to Track AI Agent ROI — the measurement framework
• x402 Analytics: tools compared — x402station, Nevermined, b402scan, on-chain attribution
• x402 documentation
• Google AP2 announcement
• Stripe ACP overview