
x402 payments give ERC-8004's Reputation Registry something it didn't have on its own: a way to tell the difference between feedback from someone who actually paid for an agent's work and feedback from someone who didn't. A $10,000 engagement and a free test run can both end in a 5-star rating, but they shouldn't necessarily count the same. This covers what x402 actually does and exactly how it plugs into the reputation-weighting mechanism already covered on this blog.
TL;DR:
402 Payment Required with a PAYMENT-REQUIRED header, the client retries with a PAYMENT-SIGNATURE header proving payment, and a facilitator verifies and settles itHTTP has had a 402 Payment Required status code since the earliest web standards, reserved but never actually implemented. x402 is what finally uses it: Coinbase describes it as "a new open payment protocol... that enables instant, automatic stablecoin payments directly over HTTP." When a client requests something that costs money, the server responds with 402 instead of the content, the client pays, and retries. As of March 2026, the protocol has processed over 119 million transactions on Base and 35 million on Solana, with Google, Visa, AWS, Circle, Anthropic, and Vercel among the x402 Foundation's core members alongside Coinbase and Cloudflare.
402 Payment Required with a PAYMENT-REQUIRED header containing payment instructionsPAYMENT-SIGNATURE header containing the payment proofSettlement runs in USDC or EURC (via EIP-3009) or any ERC-20 token (via Permit2), across Base, Polygon, Arbitrum, World, and Solana. The whole cycle is designed to complete in seconds, without a login step or a stored payment method.
x402 could, in principle, work for a human clicking through a paywall, but that's not the gap it actually closes. A human already has a dozen ways to pay for something online: a saved card, a wallet app, a subscription already in place. An autonomous AI agent calling another agent's API mid-task has none of that, no browser session to redirect through a checkout page, no human present to approve a card charge. x402's whole design, a payment completed inside the same HTTP request-response cycle that failed with 402 in the first place, is built for exactly that machine-to-machine case: an agent can pay for a resource and retry programmatically, in the same execution, without pausing to hand control back to a person. That's also precisely why a payment happening at all becomes meaningful reputation evidence, covered next, a completed x402 payment is closer to proof that a real transaction occurred than a human-submitted rating ever is, since it required an actual on-chain settlement rather than just clicking a star rating.
The Reputation Registry stores a signed fixed-point feedback value (int128 plus valueDecimals) per interaction, and the specification supports weighting that score by proof of payment through x402 integration. Concretely, this means an agent that gets paid $10,000 for a piece of work and receives a rating can have that rating carry more weight in aggregate reputation than a free or trivial interaction that received the same numeric score. Without a payment layer, a reputation system has no way to distinguish "someone paid real money and was satisfied" from "someone tried it for free and left a rating," which matters a lot if reputation is meant to signal something about an agent worth paying for.
One detail worth understanding about why x402 gets reached for specifically in agent-to-agent contexts: the payment settles as a direct stablecoin transfer through a facilitator, not a card network charging a per-transaction processing fee that typically runs to tens of cents regardless of the purchase amount. That fee structure makes sub-cent pricing, an API charging $0.001 per call, impractical over traditional rails, the processing fee alone would dwarf the actual price. A settlement model built around direct on-chain transfer doesn't have that same fixed floor, which is a real part of why an autonomous agent economy built around frequent, small, machine-initiated payments needs something shaped like x402 rather than routing every micro-transaction through infrastructure built for human-scale purchases.
An x402 payment produces real evidence, the signed payment payload, the settlement transaction. That's exactly the category of reputation evidence that belongs referenced through IPFS rather than a private database: the on-chain reputation score can carry a feedbackHash pointing at the payment evidence, and if that evidence is pinned to IPFS and referenced by CID, anyone can verify the hash matches without trusting whoever's hosting it. Pinning that evidence follows the same workflow already covered for ERC-8004 registration files, the payment record is just another JSON document to pin and reference.
What is x402? An open payment protocol from Coinbase that implements the long-unused HTTP 402 Payment Required status code for instant stablecoin payments over HTTP, without accounts or credit cards.
How does the x402 payment flow work? A server responds 402 with a PAYMENT-REQUIRED header, the client retries with a PAYMENT-SIGNATURE header proving payment, and a facilitator verifies and settles the transaction on-chain before the server returns the resource.
How does x402 connect to ERC-8004? ERC-8004's Reputation Registry can weight feedback by proof of x402 payment, so a paid interaction can count differently in aggregate reputation than free or trivial work.
What tokens and chains does x402 support? USDC and EURC via EIP-3009, or any ERC-20 token via Permit2, across Base, Polygon, Arbitrum, World, and Solana.
Where should x402 payment proof be stored for reputation purposes? Pinned to IPFS and referenced by CID through the Reputation Registry's feedbackHash field, the same verifiable-evidence pattern already used for other reputation data.

IPFS gateway not working? Read the status code first, then check the CID, your request rate, and whether anyone is providing the content. Here is the order.

ERC-1155 metadata on IPFS breaks when filenames ignore the {id} rule. Here is the exact 64-character format, a working folder layout, and the per-token option.

AIOZ Pin rate limits in one place: 180 requests per minute for the API, 15 per CID on the public gateway, and no predefined limit on premium gateways.

IPFS pin stuck on Pinning? Here is what Pinning, Pinned, and Failed mean on AIOZ Pin, why big directories can sit there, and how to read a pin's real state.

Two identical files, three IPFS tools, three different CIDs. Here is why that happened for years, and how IPIP-0499 made content addressing deterministic.

AIOZ Pin MCP server setup has two paths: llms.txt lets a super intelligence assistant read the API, the MCP server lets it call 11 tools. Here is each one.