Interoperable Agent Payments: How x402 Fits Into the Agentic Internet Stack

Why agent payments need a native web primitive now

AI agents are quickly moving from just “reading the web” to actually “buying the web.” They’re starting to pay for things like per-request data, on-demand computing, model inference, and premium content. What’s really been lacking is an easy, compatible way for machines to handle payments between each other using the same channels they already rely on for communication: HTTP.

x402 makes things easier. By turning on HTTP 402 “Payment Required” with a machine-readable contract and some standard headers, any agent or browser can check prices, put together a signed payment, and grab the resource all in one smooth process--no need for accounts, API keys, or fancy billing SDKs. Coinbase is in charge of the core spec and reference code, while Cloudflare is teaming up to create a neutral x402 Foundation. They’ve also rolled out SDK support and an MCP playground to speed up standardization across the board. (docs.cdp.coinbase.com)

The agentic internet stack at a glance--and where x402 snaps in

Intent and collaboration layer: Google’s Agent‑to‑Agent (A2A) protocol is pretty cool--it allows different agents to find each other, share what they can do, and work together using JSON‑RPC/HTTP. They even have a special x402 extension that brings paid interactions into the mix (like payment-required → payment-submitted → payment-completed) right within the A2A message flow. Check it out here.
Tooling/connectivity layer: Anthropic introduced the Model Context Protocol (MCP), which kind of sets the rules for how agents use tools, grab resources, and show prompts. Cloudflare has integrated x402 into their Agents SDK and MCP servers, allowing tools to list their prices and handle payments automatically. You can read more about it here.
Payment handshake: The x402 protocol lays out the whole negotiation process (that’s the HTTP 402 payload), provides proof with the X‑PAYMENT header, and even gives a receipt with the X‑PAYMENT‑RESPONSE header. Plus, there’s a facilitator API for verifying and settling transactions on-chain. More details can be found here.
Identity and custody: With wallets--whether they’re embedded, server-based, externally owned accounts (EOA), smart accounts, or Solana accounts--you can sign payment payloads and collect funds. Coinbase has made things easier with their SDK by offering a useX402 hook that lets you integrate with just one line of code. Check it out here.
Settlement networks: The current reference implementations are focused on Base/EVM using ERC‑3009 signatures (like USDC) and Solana SPL. They’re designed for speedy finality and low fees, perfect for all those little agent micro-commerce transactions. You can dive into that here.
Discovery: Coinbase has launched the x402 Bazaar, a kind of “Google for agents,” where you can find x402-enabled APIs and models. This way, agents can easily discover priced endpoints while they’re running. Learn more about it here.

x402 in 5 building blocks (the minimum you need to ship)

HTTP 402 Response with Payment Requirements
When your server sends back a 402 response, it should include a JSON body outlining one or more payment options that you accept. Here are the key fields to include:

scheme: logical payment scheme (like, for example, "exact")
network: the ID of the target chain/network
maxAmountRequired: the absolute maximum in asset base units
payTo: the address of the recipient
asset: token contract if you're using EVM, or mint if it's Solana
extra: any details that are specific to the scheme (like the EIP-712 name/version for the token on EVM)
mimeType/outputSchema: a description of the payload so clients can make informed decisions before they pay
maxTimeoutSeconds: the server's SLA for wrapping up the paid request

These fields and their meanings are pretty standard, so clients can easily parse and pick what they need without any custom documentation. (github.com)

X‑PAYMENT Header from the Client
The client tries again using the X‑PAYMENT header, which is set to base64(JSON). This includes x402Version, scheme, network, and a payload that depends on the scheme--like an EIP‑3009 authorization on EVM or an SPL instruction on Solana. Check it out here: github.com.
Facilitator verification and settlement
While servers can handle local verification, production environments typically rely on a facilitator:

POST /v2/x402/verify → returns isValid and invalidReason
POST /v2/x402/settle → gives you success, txHash, and networkId

Coinbase's hosted facilitator is now providing fee-free USDC settlement on Base and is also supporting Solana. If you're into self-hosted or community facilitators, you can also expand to other networks. Check out more details here: (docs.cdp.coinbase.com)

4) X-PAYMENT-RESPONSE receipt

When everything goes smoothly, send back a 200 status along with the X-PAYMENT-RESPONSE that has the settlement details. This helps buyers keep track of their transactions. Check it out on GitHub.

5) Latency Strategy

You have a couple of options here: you can either go for a quick fulfillment right after "verify" and then settle asynchronously to keep things speedy, or you can choose to block on the settlement for a bit more solid payment finality. The spec makes it clear that there's a trade-off between how quickly you respond and how certain you feel about the outcome. Latency Strategy

Code you can paste today

Server: Hono (Workers) Paywall with Per-Route Price and Base Sepolia in Minutes

When it comes to setting up your Hono server with a paywall, you might want to consider the per-route pricing model. It’s super flexible and allows you to tailor costs to exactly what you need.

Understanding the Model

Here's a quick breakdown of the key points:

Per-Route Pricing: You only pay for the routes you use. This means you can optimize your expenses based on your actual consumption.
Base Sepolia in Minutes: This refers to the basic rate calculated per minute on the Sepolia network.

Key Features

Cost-Effective: Since you’re charged based on routes, you won’t be paying for unused services.
Granular Control: Manage your routes and costs more effectively, allowing for better budgeting.

Getting Started

To get the ball rolling, make sure to check the Hono documentation to set everything up correctly. You can find more details here.

Conclusion

Using a per-route pricing structure with your Hono server lets you customize your setup in a way that’s both economical and efficient. Enjoy the freedom to scale as you need without the worry of a one-size-fits-all price tag!

import { Hono } from "hono";
import { paymentMiddleware } from "x402-hono";

const app = new Hono();

// Charge $0.01 for /quotes; settle to your EVM address
app.use(paymentMiddleware(
  "0xYourPayToAddress",
  {
    "/quotes": {
      price: "$0.01",
      network: "base-sepolia",
      config: { description: "Per-call market quote" }
    }
  }
));

app.get("/quotes", c => c.json({ bid: 123.45, ask: 123.55 }));
export default app;

The middleware sends out a compliant 402 response body, manages verification and settlement through a facilitator, and includes the X‑PAYMENT‑RESPONSE when everything goes smoothly. Check it out here: (npmjs.com)

Client: Let's wrap the fetch call with x402 to handle automatic pay-on-402.

import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { baseSepolia } from "viem/chains";
import { wrapFetchWithPayment } from "x402-fetch";

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
const wallet = createWalletClient({ account, chain: baseSepolia, transport: http() });

const fetchWithPay = wrapFetchWithPayment(fetch, wallet, /* optional: maxValue */);

const res = await fetchWithPay("https://api.example.com/quotes");
console.log(await res.json());

Forget about manually sifting through 402 bodies or crafting signatures. The wrapper takes care of everything for you--just select a requirement, build the X-PAYMENT, and it’ll handle the retries, sending back the final 200 response. Check it out here: (npmjs.com)

React apps that come with built-in wallets can totally skip the hassle of connecting wallets and just use one simple hook:

import { useX402 } from "@coinbase/cdp-hooks";

const { fetchWithPayment } = useX402();
const res = await fetchWithPayment("https://api.example.com/quotes");

The hook signs using the user's embedded wallet, whether it's an EOA, a smart account, or a Solana account, and takes care of any replay issues. Check out the details here.

How x402 composes with A2A and MCP (interoperability in practice)

A2A + x402: So, here’s how it goes down when a merchant agent needs payment: it sends back a payment-required message. Then, the client agent jumps in with a payment-submitted (that’s a signed payload, by the way). Once everything's verified, the merchant wraps things up with a payment-completed. This whole slot-in extension is pretty cool because it standardizes paid agent skills across various vendors and languages. That means you can manage inference, data pulls, or actions without needing custom contracts between teams. Check it out here: (github.com)
MCP + x402: Now, if you’re using tools hosted behind MCP, you can price each tool call. With Cloudflare’s Agents SDK, tool invocation is wrapped to catch those 402s and create x402 payloads automatically. It even includes an optional human confirmation step. This feature allows you to run a marketplace of paid tools inside an agent browser securely. Learn more about it here: (blog.cloudflare.com)

Result: An agent can easily find a service (A2A), call a tool (MCP), and make a payment (x402) from start to finish using open standards over HTTP--without having to deal with captchas, cookie sessions, or any proprietary billing SDKs.

Settlement networks and token mechanics (EVM + Solana)

EVM with EIP‑3009 (USDC and compatible tokens): Clients can sign an EIP‑712 authorization that includes validAfter, validBefore, and nonce. This gets submitted by a facilitator, making gasless, one-step transfers possible--super handy for agents! It's better to use receiveWithAuthorization instead of transferWithAuthorization in your smart contract calls to avoid front-running issues. Also, keep those validity windows tight and use unique nonces to squash any replay attacks. Check it out here: (eips.ethereum.org)
Solana SPL: For those working with Solana, facilitators can handle SPL and Token‑2022 without needing EIP‑712; there are plenty of developer resources and templates available for x402 servers and clients. If you’re looking for super quick confirmations and the ability to handle larger concurrent micro-flows, Solana is the way to go. More details here: (docs.cdp.coinbase.com)
Network support today: Right now, CDP’s hosted facilitator is all set for Base mainnet and Solana, including their testnets. If you’re into community/self-hosted facilitators, you can expand to pretty much any EVM or Solana network; all facilitators will accept any EIP‑3009‑compatible token across supported networks. Dive in for more info: (docs.cdp.coinbase.com)

Pro tip: Show prices as easy-to-read strings (like “$0.01”) and let your facilitator take care of the asset math. This way, you can A/B test different price points without worrying about token decimals or exchange rates. (docs.cdp.coinbase.com)

Best emerging practices we’re applying for clients

Architect for Agent-Grade Latency

When it comes to your “read” endpoints, it’s a good idea to go with a verify-then-fulfill approach and settle asynchronously, especially if you can handle a bit of fraud risk for that sweet API-like latency. But for those high-value “write” actions, hold off on responding until you’ve settled things. Don’t forget to document these SLAs in your PaymentRequirements using maxTimeoutSeconds.

Use PaymentRequirements as an API Contract

Make sure to fill in mimeType and outputSchema! This way, agents can figure out if they need to make a payment before they dive into building the X-PAYMENT. Don't forget to include several accepts entries to showcase different options, like Base USDC versus Solana USDC. Check it out on GitHub!

Harden EIP‑3009 Flows

Make sure to use strictly monotonic, random nonces; don’t accept stale validBefore timestamps; log the authorizationState to stop replay attacks; and opt for receiveWithAuthorization in your contract paths. It's a good idea to keep mandate lifetimes short--just a few seconds--for those micro-calls. (eips.ethereum.org)

Treat the Facilitator as Your Payment Control Plane

Let a hosted facilitator (CDP) handle verification, chain connectivity, and KYT/OFAC checks for your production needs. If you have specific requirements for custom rails or data residency, you can always switch back to a self-hosted solution. Just keep an eye on any verify/settle errors and make sure to show them in your 402 error field. For more details, check out the documentation.

Instrument Everything with Receipts

Get the ball rolling by echoing X-PAYMENT-RESPONSE when a transaction is successful. Make sure to log the txHash, networkId, amount, and response time. These receipts will be super useful for figuring out your authorization success rate, settlement latency, and revenue from paid calls. Plus, check out public dashboards and explorers like ecosystem trackers or Solana’s x402 tools for some great insights into the overall ecosystem. (github.com)

Design for Discovery and Distribution

Make sure to register your endpoints with discovery layers like x402 Bazaar. This way, agents can easily find and test your paid resources. Don’t forget to include clear descriptions and preview responses in your “accepts” entries. This will help you cut down on those pesky failed payments. (coindesk.com)

Give Agents Safe Spending Autonomy

For the client side, make sure to set a maxValue per request and some daily spending limits. You'll want to get human confirmation for anything that goes over those thresholds. The official x402 wrappers have got you covered with built-in support for selective requirement choices and caps. Check it out here: (npmjs.com)

Map Paid Actions into A2A/MCP Cleanly

For A2A, make sure to wrap those paid skills in the x402 extension. This way, the downstream agents will have a clear idea of what they’re dealing with. Over in MCP, don’t forget to tag the tools with price metadata. Plus, run the Cloudflare wrapper to catch those 402s and put together the payment payloads. Check it out here: (github.com)

Practical patterns for common use cases

Pay‑per‑crawl Data Endpoints (B2B)

Server: Returns a 402 status code with tiered accept entries (e.g., $0.005 for cached data and $0.02 for fresh data with a 1-second SLA).
Client: Choose based on mimeType and maxTimeoutSeconds, depending on how urgent the task is.
Org Benefit: This setup lets you monetize without needing API keys, plus finance gets on-chain settlement receipts for each request. "Pay‑per‑crawl" is a clear design goal that Coinbase has discussed as agents look for top-notch web data. (coindesk.com)

2) Model Inference Metering (B2D)

MCP tools show you the price for each call; agent browsers handle payments automatically through x402. You can set it up to require a human to confirm before paying for any pricey tools.
For contracts, stick with the “exact” scheme if you’re going for fixed per-call pricing. As the specs develop, you might want to think about an “up to” scheme for token-metered LLM outputs. Check out the details here: github.com.

3) Enterprise API Monetization Without Accounts (B2D/B2C)

Just add the x402 middleware to your current Express or Hono routes. You can keep using your authentication for the enterprise SKUs, but make sure to accept x402 for one-off uses and trials.
When it comes to compliance, you can rely on the facilitator’s KYT/OFAC checks and country restrictions, which are already up and running in over 100 countries. You can find more info in the docs.cdp.coinbase.com.

Multi‑chain reach with a single client

Publish works with both Base and Solana, allowing your client heuristics to choose based on fee and latency. If you want to add more chains or custom tokens, you can self-host a facilitator as long as they support EIP‑3009 (EVM) or standard SPL flows. Check out the details here: (docs.cdp.coinbase.com)

Security, risk, and compliance checklist

Signature replay and windowing: Make sure to enforce validAfter/validBefore and keep the windows nice and tight (no more than 30 seconds for those micro-calls). It's a good idea to store nonces that have been used and maybe set up an endpoint so clients can check the authorizationState if they need to. Check it out here: (eips.ethereum.org)
Front-run protections: When you're integrating contracts, always call receiveWithAuthorization and double-check that the caller is the payee. Steer clear of accepting raw transferWithAuthorization from anyone you don’t trust. More details here: (eips.ethereum.org)
Idempotency: Use the X‑PAYMENT payload hash as your idempotency key, and make sure to return the same receipt on safe retries. You can find more information on this here: (github.com)
Regulatory posture: Consider using a hosted facilitator for top-notch KYT/OFAC compliance and to manage geographic restrictions. It's smarter to keep custody and chain operations out of the app servers. Details can be found here: (docs.cdp.coinbase.com)
Observability: Don’t forget to log the verify and settle results, along with the time it takes to get a receipt. It’s also helpful to have a health endpoint that shows the currently supported (scheme, network) pairs from GET /supported, which will help with agent routing. You can check this out here: (github.com)

Roadmap signals to watch

Foundation governance: So, Coinbase and Cloudflare are teaming up to create a neutral x402 Foundation. This group's job is to oversee the evolution of the spec and introduce some new billing methods--think deferred/mandated and credit-based options. As time goes on, you can expect broader multi-rail support. (coinbase.com)
Discovery and marketplaces: The growth of the x402 Bazaar will play a big role in how quickly agents can access new paid skills. If you have endpoints ready to go, consider publishing them there early on! (coindesk.com)
Solana/EVM parity: Exciting news--official templates and explorers for Solana x402 are now live! Meanwhile, EVM is still utilizing EIP-3009 to facilitate gasless transactions. Don't forget to keep an eye out for new chains and tokens being added! (docs.cdp.coinbase.com)
A2A and MCP deepening: With the A2A x402 extension and Cloudflare’s MCP integration, we're looking at a steady reduction in the glue code needed to transform any tool into a paid one. Pretty cool, right? (github.com)

KPI template to instrument on day one

Authorization success rate = verified / payment attempts
Settlement latency p50/p95 (by chain/network)
Paid request success rate (business 200s / paid requests)
Revenue per endpoint, per agent class, per geography
Refund/dispute rate (ideally close to zero with on-chain finality)

You should definitely highlight these metrics on your internal dashboards. Plus, the x402 ecosystem and some blockchain foundations provide public explorers and stats that can help you gauge how your service stacks up. Check it out here: docs.cdp.coinbase.com.

Implementation plan (30/60/90)

0-30 days:
- Pick your network(s) (Base, Solana) and set those price strings. Integrate x402 middleware on a couple of high-value endpoints.
- Use a hosted facilitator and wire those receipts straight to your analytics and billing systems.
- Set up a feature flag to gate things; start piloting with a few chosen customers or agents. (docs.cdp.coinbase.com)
31-60 days:
- Time to publish to x402 Bazaar! Also, don’t forget to add A2A x402 support for your agent skills.
- Ship out those client caps (maxValue) and build a cool confirmation UI; plus, add per-route SLAs using maxTimeoutSeconds. (coindesk.com)
61-90 days:
- Dive into Solana/EVM dual accepts and test out those EIP‑3009 custom tokens if they’re on your radar.
- Think about a self-hosted facilitator for custom rails or data residency; run a load/latency game day and keep track of those p95s. (docs.cdp.coinbase.com)

Final take

x402 offers agents a super intuitive way to handle payments that fits right in with how they’re already doing things. Whether it's using HTTP for communication, coordinating through A2A, or calling tools with MCP, this system just clicks. Thanks to features like 402 negotiation, EIP‑3009 signatures, and facilitator-backed settlement, you can roll out pay-per-use experiences in just a matter of days instead of having to wait for quarters. Plus, you get top-notch compliance and observability from day one. The quick movers in the game are already setting up priced endpoints and making them available in discovery layers, so agents can easily find, pay for, and integrate them into their workflows automatically. Check it out on GitHub!

Looking for a practical pilot or a complete architecture? Whether it's A2A/MCP integration, wallet user experience, or operational dashboards, our crew at 7Block Labs has the playbooks and reference code you need to launch in less than six weeks.