What you will build

An AI agent that earns revenue by charging for the work it does, settled in USDC on Base, per call, with no signup for the caller. A request that has not paid gets a 402; a request that has paid runs and returns the result. You decide what is worth charging for and how much, and the wallet collects.

This page covers both halves: the judgment (what to charge for) and the mechanism (how to gate and price it). For the pure receive mechanics, see how-to-receive-payments-as-ai-agent. If your agent is specifically an MCP server, the MCP monetization guide is the version shaped for that. The payment API product page is the broader reference.

When an agent is worth monetizing

Before any code, decide whether monetizing is the right move, because gating the wrong thing just adds friction.

An agent is worth charging for when it produces something a caller would pay for: a researched answer, a generated image or document, a specialized analysis, a lookup against data the caller cannot easily get. The signal is value or cost on your side. If every call costs you real money in upstream APIs or compute, charging recovers that. If the result is genuinely useful and hard to reproduce, charging captures that value.

An agent is not worth monetizing when it relays something cheap and public, or when it has no users yet. Gating a thin wrapper around a free API earns nothing and slows everyone down. An agent with zero traffic should optimize for adoption, not revenue; keep it free until callers actually want it. The honest rule is to charge where the work is worth paying for, and to leave everything that supports discovery and evaluation free.

Who pays a monetized agent

It helps to picture the buyer, because it is usually not a human filling in a checkout form. Three kinds of callers pay a monetized agent, and all three pay the same way.

The first is other agents. An agent that needs a research answer or a generated asset calls yours, hits the 402, and its own wallet settles the charge. This is agent-to-agent commerce, and it is the largest growth area, because an agent with a wallet can pay yours with no human involved on either side.

The second is applications. A product that wants your agent's capability wires a call to your endpoint and funds the payments from its own wallet. To the app, your agent is a paid API that happens to be smart.

The third is people, indirectly, through a runtime that holds a wallet on their behalf. The person never sees a 402; their tool pays it. In every case the caller pays per request with no account on your side, which is why a monetized agent can earn from callers it has never met. You are not building a signup funnel; you are putting a price on a route and letting anyone who speaks the protocol pay it.

Prerequisites

• A Blockchain0x account, so the agent has a wallet to receive into.
• A sk_test_ API key, the agent's wallet address as the payToAddress, and a paymentRequestId for the priced route.
• Node 18 or newer. The SDK targets >=18.

export B0X_API_KEY=sk_test_...
export B0X_PAYTO_ADDRESS=0x...     # the agent's wallet, receives USDC
export B0X_PRICE_REQUEST_ID=pr_... # payment-request id for the priced route

Gate what the agent sells

Put the x402 server adapter in front of the route that does the paid work. An unpaid request gets a 402; the adapter verifies payment on the retry and only then runs your handler.

import Fastify from "fastify";
import { createClient } from "@blockchain0x/node";
import { createX402Plugin } from "@blockchain0x/x402/server/fastify";

const sdk = createClient({ apiKey: process.env.B0X_API_KEY! });
const app = Fastify();

await app.register(createX402Plugin, {
  sdk,
  defaultNetwork: "testnet",
  pricing: {
    "POST /agent/research": {
      amountUsdc: "0.05",
      payToAddress: process.env.B0X_PAYTO_ADDRESS!,
      paymentRequestId: process.env.B0X_PRICE_REQUEST_ID!,
    },
  },
});

// Only runs once payment is verified.
app.post("/agent/research", async (req) => runResearchAgent(req.body));

// Discovery stays free: capabilities, schema, health. Not in the pricing table.
app.get("/agent/capabilities", async () => listCapabilities());

await app.listen({ port: 8080 });

Express works the same way with createX402Middleware. Pricing is keyed per route, so the paid work lives on its own path and anything that helps a caller decide to buy, capabilities and health, stays on unpriced paths.

Price the call

Two frameworks, used in order. Start cost-plus: take your real per-call cost (upstream APIs, compute) and add a margin. This is the safe floor because you cannot lose money on a call. If a research call costs you two cents in upstream data, charging five cents covers it with room to spare.

Then move toward value-based as you learn. If the answer is worth a dollar to the caller's downstream decision, five cents leaves most of that value on the table, and you can raise the price without losing the sale. Watch the conversion from 402 to settled payment as you adjust: if a higher price converts about as well, you were under-pricing; if conversion falls off a cliff, you found the ceiling. Keep changes gradual and let the data, not a competitor's number or a revenue target, set the price.

Get paid and confirm

The adapter verifies each payment server-side by calling paymentRequests.settle, so a request only reaches your handler once the on-chain transfer is confirmed against the quoted requirement. You do not trust the caller's claim of payment.

To act on revenue as it lands, subscribe to the payment.received webhook and verify it:

import { webhooks } from "@blockchain0x/node";

// inside your raw-body webhook route:
const result = webhooks.verify({ headers: req.headers, rawBody: req.body, secret: process.env.B0X_WEBHOOK_SECRET! });
if (result.ok && result.eventType === "payment.received") {
  recordEarning(JSON.parse(req.body.toString("utf8")));
}

That gives you a real-time earnings feed. For reconciliation after the fact, look a payment up with client.transactions.get(id). The full receive-side detail is in how-to-receive-payments-as-ai-agent.

Test on Base Sepolia

Exercise the whole loop on testnet before going live. With a sk_test_ key the agent settles on Base Sepolia (eip155:84532). Call the priced route with no payment and confirm the 402; pay it from a test wallet and confirm the handler runs and returns. Watch the payment.received event land. When the unpaid and paid paths both behave, swap to a sk_live_ key for Base mainnet and re-check the price and the agent's wallet address on the live agent.

Common pitfalls

Three traps when monetizing an agent.

Gating discovery. If a caller has to pay just to learn what the agent does, most never get to the paid call. Keep capabilities, schema, and health on free routes; charge only for the work.

Pricing from a vanity number. A price you picked because it sounds right, rather than from cost-plus and conversion data, is usually wrong in one direction or the other. Start from real cost and let conversion guide you.

Forgetting the agent can also overspend. A monetized agent that also buys upstream data is on both sides of the ledger. Set a spend limit on its wallet too, the same one that protects any paying agent, so its costs cannot run away while it earns.

What to ship today

Pick the one thing your agent does that is worth paying for, gate that route with the adapter at a cost-plus price, and confirm an unpaid call gets a 402 while a paid one runs. Watch one payment.received event land. That is a monetized agent. Then tune the price on real conversion data. Production pricing for the platform is on the pricing page.