A year ago there was no serious payment protocol purpose-built for AI agents. The choices were: adapt human payment infrastructure (credit cards, ACH, payment processors) to work with machine-speed agents, or build proprietary payment flows as one-off integrations. Neither was satisfying. The first had fundamental architectural mismatches. The second produced fragmented, non-interoperable solutions.
Today there are two serious open protocols. x402, backed by Coinbase, Google, Anthropic, Visa, AWS, and Cloudflare, defines an HTTP-native payment flow triggered by the 402 status code — a clean, minimal protocol that makes HTTP resources payable. AP2 (Agent Payment Protocol 2) from Google takes a broader approach: payment, identity, authorization, and commerce receipts in a single protocol designed for structured agent-to-agent commerce. Both are real, production-deployed protocols with meaningful adoption. Choosing between them (or using both) requires understanding what each is actually optimized for.
x402 — the HTTP-native approach
x402 is designed to answer a specific, narrow question: how does an AI agent pay for access to an HTTP resource? The answer is deliberately minimal. The server returns an HTTP 402 status code with payment terms. The agent evaluates the terms, pays if the terms are acceptable, and retries with a payment proof in the request header. The server verifies the proof and serves the resource.
That's the entire protocol. No identity negotiation, no service agreements, no multi-step trust establishment. Just: resource has a price, agent pays the price, server delivers the resource. The simplicity is the feature.
x402 — Simple, HTTP-native
- Does one thing: makes HTTP resources payable
- No new protocols, no registration, no bilateral setup
- Server returns 402 → agent pays → server confirms
- Works with any HTTP stack, any language
- 35M+ transactions already in production
- Backed by Coinbase, Google, Anthropic, Visa, AWS, Cloudflare
- Proco supports x402 natively — zero additional configuration
AP2 — Comprehensive agent commerce
- Multi-component protocol: payment + identity + authorization + commerce receipts
- Designed for structured, multi-step agent-to-agent interactions
- Identity verification built into the protocol — both sides are verified
- Delegated authorization — an agent can grant sub-agents specific payment authority
- SLA and commitment support for service-level commercial relationships
- More complex to implement — both sides need to support it
- Proco supports AP2 identity linking and payment components
When x402 is the right choice
x402 is the right protocol for agent-to-API interactions: your agent needs to access a paid data source, computation resource, or tool API. The commercial relationship is simple — a price per request or per query, paid in real time, with no ongoing service agreement. The key advantages:
Zero setup friction on the server side. Adding x402 to an existing API endpoint is a single middleware addition. The server doesn't need to know anything about the calling agent — it just needs to specify payment terms and verify payment proofs. No registration, no API key management, no bilateral agreement.
Network effects are already working. With 35 million transactions in production and backing from the major cloud providers, AI companies, and payment networks, x402 is reaching the critical mass where compatibility becomes a baseline expectation rather than a differentiator. Every new x402-compatible service is immediately accessible to every x402-compatible agent. That's a network that's already growing.
Works with Proco's policy engine out of the box. Proco's x402-compatible HTTP client evaluates payment terms against your policy engine before executing any payment. The agent doesn't implement any payment logic — it makes normal HTTP calls and the infrastructure handles x402 negotiation, policy evaluation, and payment execution transparently.
When AP2 is the right choice
AP2 is the right protocol when the commercial relationship between agents is more structured than a simple micropayment. The specific scenarios where AP2's additional complexity pays off:
Orchestrator-to-sub-agent commissioning. When an orchestrating agent is delegating tasks to sub-agents with specific deliverables, SLAs, and contingent payment (pay only if the deliverable meets quality criteria), AP2 provides a structured commercial framework. The task commission, the quality validation, and the payment settlement are all part of the protocol.
Enterprise agent-to-agent commerce with audit requirements. When both sides of an agent transaction need to be verifiably identified — for compliance, for dispute resolution, or for enterprise audit requirements — AP2's identity verification components provide a level of assurance that x402 (which is payment-only) doesn't address.
Delegated authorization hierarchies. When an agent needs to grant specific payment authority to sub-agents (without giving them unrestricted access to the parent agent's wallet), AP2's delegation model provides a structured approach. The parent agent authorizes specific sub-agents to make specific types of payments up to specific limits — all within the protocol.
In practice — using both protocols
The most sophisticated production deployments don't choose between x402 and AP2 — they use both for different interaction types within the same agent system. A research orchestration agent might use x402 for its data API calls (simple micropayments, no bilateral setup required) while using AP2 for commissioning research sub-agents (structured commercial relationships with quality-contingent payment).
The infrastructure choice doesn't force a protocol choice. Proco supports both x402 (natively, with automatic policy integration in the HTTP client) and AP2 identity and payment components. You can mix protocols within the same agent deployment based on the nature of each interaction type, without changing your underlying wallet infrastructure.
The practical decision tree: if the agent is paying for API access, start with x402. If the agent is commissioning other agents for structured tasks with quality deliverables, evaluate AP2. If you're unsure, start with x402 — the simplicity means you'll have it working in an afternoon, and you can add AP2 for specific interaction types as your architecture matures.
The protocol landscape is still forming
Both x402 and AP2 are evolving. x402 is adding trust extensions that handle some of the identity scenarios AP2 covers natively. AP2 is adding lightweight interaction patterns that reduce the setup overhead for simple payment scenarios. The protocols are converging on complementary rather than competing positions — x402 as the lightweight, HTTP-native standard for simple payments; AP2 as the comprehensive framework for complex commercial agent interactions.
For builders, the pragmatic advice is: implement x402 today for agent-to-API payments. Monitor AP2's adoption trajectory and add support as the ecosystem matures. Proco supports both, so the infrastructure decision is not a commitment to either protocol exclusively. Build on open standards, start simple, and add complexity as your use cases demand it.
Further reading: x402 Explained · Building on x402