The landscape in early 2026
A year ago, agent payments were a thought experiment. Today, serious protocols are in production or late-stage development, each backed by a company with real distribution. If you're building agent infrastructure, you need to understand what each one does — and what none of them do.
x402: HTTP-native payments
Coinbase's x402 protocol is the most elegant approach architecturally. It extends HTTP itself — when a server returns a 402 Payment Required status, the client agent knows exactly how to pay and retry. Payment becomes part of the protocol layer, like authentication.
What it does well: x402 is beautifully simple for pay-per-request API access. An agent calls an endpoint, gets a 402, pays in USDC, retries, gets the response. No accounts, no subscriptions, no API keys. The payment is the authentication. For simple, stateless, request-response interactions, this is close to ideal.
Where it falls short: x402 is designed for atomic exchanges — pay, receive. It doesn't handle multi-step workflows where the output needs to be checked before payment clears. There's no escrow primitive and no verification concept. If the API returns garbage, you already paid.
Google AP2: agent-to-agent commerce
Google's Agent-to-Agent Payment Protocol takes a broader view. AP2 is designed for commerce between agents — not just API calls, but services with negotiation, terms, and fulfillment. It includes concepts like offers, acceptances, and delivery confirmation.
What it does well: AP2 models the full commercial transaction lifecycle. Agents can negotiate terms, agree on deliverables, and confirm receipt. It's the most complete protocol for agent commerce as a concept. Google's distribution (Android, Google Pay, Workspace) gives it enormous potential reach.
Where it falls short: "Delivery confirmation" in AP2 is a binary signal — the buyer agent says "received." But received doesn't mean verified. There's no programmable check on whether the deliverable meets specifications. The buyer still has to trust the seller, or build their own verification logic entirely outside the payment flow.
Side by side
| x402 | AP2 | |
|---|---|---|
| Settlement | USDC (on-chain) | Google Pay / fiat |
| Best for | Pay-per-API-call | Agent commerce |
| Escrow | No | No |
| Verification | None | Binary confirm |
| Programmable rules | No | No |
| Multi-step workflows | No | Partial |
| Latency | Seconds | Variable |
The missing row
Look at the table above. Every protocol handles the money-moving layer. None of them handle the work-checking layer. This isn't a criticism — it's a scope observation. Payment rails optimize for reliability, speed, and cost of moving funds. Verification is a different problem entirely.
The missing piece is a layer that sits between the work and the settlement — one that's agnostic to which rail you use underneath. Define your verification rules when you create the payment. Escrow the funds. Let the agent do the work. Run the checks. Then settle on whatever rail makes sense for your use case.
x402 for crypto-native API monetization. AP2 for Google-ecosystem commerce. And a verification layer that works with all of them.
Arbitr is that verification layer. We're rail-agnostic by design — escrow, verify, and release on any settlement protocol. Currently in early access with USDC on Solana, with x402 and AP2 integrations on the roadmap. Get early access →
The composable stack
The agent payment stack is going to be composable, not monolithic. Just like web infrastructure separated into CDN, compute, database, and auth layers — each best-in-class at its job — agent commerce will separate into discovery, negotiation, verification, and settlement layers.
The protocols building settlement rails are doing important work. The missing piece is the verification layer that makes those rails trustworthy for substantive agent-to-agent work. That's where the value compounds.