Integrating x402: Payments for Agents

June 15, 2026 • Asim Aslam

The last post was about agents that run on their own — triggered by an event, acting without a human prompt. Follow that one step further and you reach something agents can't do yet in most systems: pay. An autonomous agent that calls an API, rents compute, or uses another agent's service will, sooner or later, need to settle for it — without a person reaching for a credit card. There is now a standard for exactly that, and we're integrating it.

What x402 is

x402 is an open payment protocol built on the HTTP 402 Payment Required status code. The flow is simple: a client requests a resource, the server answers 402 with machine-readable payment requirements (amount, asset, network, where to pay), the client pays and retries with an X-PAYMENT header, and the server verifies the payment and serves the resource. It's designed for stablecoins and for machine-to-machine use — agents paying for things, per request.

It started at Coinbase, it's multi-chain (Base, Solana, Ethereum, Polygon, and more), and as of April 2026 it's governed by the x402 Foundation under the Linux Foundation, with founding members including Google, Visa, Stripe, AWS, Mastercard, Circle, and Shopify. That governance is why we're comfortable integrating it: it's an open standard with the payments industry behind it, not a single vendor's API.

How Go Micro integrates it

The same way it integrates everything else — interface-first, with a default, and pluggable.

The core is HTTP middleware in wrapper/x402. It enforces the 402 challenge and verifies payments, but it carries no chain or crypto code. Verification and settlement are delegated to a pluggable Facilitator:

type Facilitator interface {
    Verify(ctx context.Context, payment string, req Requirements) (Result, error)
}

So Go Micro stays chain-agnostic. "Base through Coinbase" and "Solana through Alchemy" are not two integrations — they're the same middleware pointed at two facilitators. The facilitator does the on-chain work; the framework speaks the protocol.

pay := x402.Middleware(x402.Config{
    PayTo:   "0xYourAddress",      // where payments go
    Network: "solana",            // or "base", ...
    Amount:  "10000",             // smallest units, e.g. 0.01 USDC
})
mux.Handle("/paid", pay(handler))

Opt-in, at the gateway

Because every Go Micro endpoint is already an AI-callable tool through the MCP gateway, that's the natural place to charge: a tool call is the thing worth a payment. So x402 is wired into both the built-in micro mcp serve and the standalone micro-mcp-gateway, and it is strictly opt-in — off unless you set a pay-to address.

bash

micro mcp serve --address :3000 \
    --x402-pay-to 0xYourAddress \
    --x402-network solana \
    --x402-amount 10000 \
    --x402-facilitator https://facilitator.example

With payments enabled, the /mcp/call endpoint requires a verified payment; listing tools and health checks stay free. Without the flag, nothing changes. The standalone gateway takes the same options via flags or environment variables, so you can put a paid gateway in front of services you didn't write.

Different tools can cost different amounts. Because pricing is an operator concern — the payTo address is the operator's, and prices change without redeploying anyone's service — it's set at the gateway with a config file, the same way per-tool scopes and rate limits already are:

json

{ "payTo": "0xYourAddress", "network": "solana", "asset": "USDC",
  "amount": "0",
  "amounts": { "weather.Weather.Forecast": "10000", "search.Search.Query": "5000" } }

bash

micro mcp serve --address :3000 --x402-config x402.json

amount is the default (here 0 — free), and amounts sets per-tool overrides. There's no "pricing" abstraction in the framework; it's just the x402 amount, resolved per tool, in the protocol's own vocabulary.

Why this matters

Go Micro's premise has been that every service is a tool an agent can call. x402 adds one word: a paid tool. That turns "tools as services" into something with an economic side — a service can charge per call, and an agent can pay for it, with no human in the loop on either end. It gives the services people build a native way to be paid for, and it gives Go Micro a place in the supply side of an agent economy: the rails for agents to act and transact.

Honest about the edges

It's opt-in and dependency-light. No pay-to address, no payments. Go Micro pulls in no chain libraries — the facilitator does that work.
Amounts start simple. A default amount, or per-tool amounts via the gateway config today; metered usage and prepaid balances (the place a "credit" concept would actually fit) are the harder design work to come.
A paying agent needs a budget. Blog 21 argued that unattended agents need guardrails; an unattended agent that spends money needs them most. A spend cap belongs next to MaxSteps and ApproveTool, and it's the next piece to build on the agent side.

Agents that act, and now can pay. Services, agents, workflows, and payments — the substrate for software that operates, and transacts, on its own.

Sources: x402 — Coinbase Developer Docs, What is x402? — Alchemy, x402 on Solana — solana.com.