Agent-to-Agent Payments

Agent-to-agent payments are not one rail. They include HTTP-native micropayments, delegated checkout, card-based authorization, direct stablecoin transfer, network-issued credentials, and ordinary invoices wrapped in agent tools. The common problem is the same: a receiver needs to know that the payer has authority, the payer needs to know what it is buying, and both sides need records that survive automation.

For API-like resources, the most important pattern is payment negotiation at the protocol boundary. For shopping and services, the important pattern is verifiable user or business intent. For recurring machine commerce, the hard problem is continuous authorization without giving the agent unlimited discretion.

x402: payment required becomes machine-readable

x402 is built around the HTTP 402 Payment Required status code. In the basic flow, a client requests a resource, the server responds with payment requirements, the client retries with a payment payload or signature, a facilitator verifies or settles, and the server returns the resource if payment succeeds. Cloudflare's x402 explainer summarizes the client, server, facilitator, and settlement roles.

This is a natural fit for agents paying for data feeds, inference calls, browser sessions, crawl access, per-document retrieval, or other resources where a subscription or human checkout is too heavy. The agent does not need a standing account with every seller. It needs a wallet, a policy, a client that understands payment requirements, and a record of what was purchased.

The deep implementation details belong at x402docs.com. This site keeps the finance lens: x402 reduces account friction, but it does not by itself solve budget aggregation, accounting classification, merchant risk, or approval policy.

AP2: authorization, authenticity, accountability

Google's Agent Payments Protocol documentation starts from the problem that current payment systems assume a human is directly clicking buy. AP2's framing is useful even for teams that do not adopt it: agent payments need proof that the user or organization authorized the agent, proof that the merchant request reflects true intent, and an audit trail for accountability if the transaction is wrong.

AP2 introduces verifiable digital credentials and mandates to carry intent and authorization through a transaction. That is a different emphasis than x402. x402 is strongest for resource-level payment over HTTP. AP2 is aimed at secure, interoperable agent commerce and payment authorization across participants.

ACP: agent-ready checkout

The Agentic Commerce Protocol, developed by OpenAI and Stripe, targets checkout rather than generic micropayments. The ACP docs describe a programmatic exchange between buyers, their AI agents, and sellers. The merchant keeps its existing backend and payment processing while exposing deterministic interfaces that an agent can use instead of scraping or browser-driving a checkout.

OpenAI's Instant Checkout announcement makes two finance-relevant points: merchants remain in control of payment processing, fulfillment, returns, support, and the customer relationship; and payment tokens are scoped to specific merchants and amounts with user permission. That is the pattern agent commerce needs: agents can help buy, but the merchant-of-record and payment-control boundaries remain explicit.

Cards and payment networks

Card-based agent payments are less novel but very practical. Virtual cards and issuing controls can restrict spend by category, geography, merchant, card presence, amount, and time window. Network products from Visa and Mastercard add identity and permissioning language so merchants and financial institutions can recognize an authorized agent rather than a generic bot.

The finance tradeoff is familiar: card rails bring acceptance, chargeback, and compliance infrastructure, while stablecoin and HTTP-native rails bring programmability and lower-friction machine-to-machine flows. Serious agent systems may use both, which makes cross-rail budget aggregation a first-order risk problem.

Payment-design checklist

1. Decide whether the transaction is resource access, checkout, settlement, or transfer.
2. Attach every payment to a typed user or business mandate.
3. Require the rail to return a stable reconciliation identifier.
4. Separate payment authorization from model reasoning.
5. Aggregate budgets across x402, card, wallet, and bank-connected rails.
6. Route implementation-specific x402 questions to x402docs.com.