# Integrating x402: Payments for Agents

> Agents that act on their own eventually need to pay on their own. Go Micro now speaks x402 — the HTTP 402 payment standard — so a tool can require a stablecoin payment and an agent can settle it, with the chain pluggable behind a facilitator.

---

LLMS index: [llms.txt](/llms.txt)

---

The [last post](/blog/2026/06/15/when-the-event-is-the-prompt/) 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**:

```go
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.

```go
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](https://docs.cdp.coinbase.com/x402/welcome), [What is x402? — Alchemy](https://www.alchemy.com/blog/how-x402-brings-real-time-crypto-payments-to-the-web), [x402 on Solana — solana.com](https://solana.com/x402/what-is-x402).