What x402 is actually for: six agentic-payment patterns on Solana

It's easy to nod along to "x402 lets machines pay for things" and walk away with no idea what to build. The protocol and the seller mechanics are covered elsewhere; this is the catalog of patterns — the six shapes x402 actually takes in production on Solana, each with a real deployment, and an honest note on where it's the wrong tool.

1. Pay-per-API-call (no signup)

The canonical pattern: an endpoint charges a fraction of a cent per request, no account, no key. A script, a scraper, or an agent pays and gets the response. The flagship Solana deployment is Pay.sh (Solana Foundation × Google Cloud) — an API proxy that fronts Google Cloud services (Gemini, BigQuery, BigTable, Cloud Run) and 50+ community APIs, settling in stablecoins on Solana with fiat reconciliation to providers behind the scenes. Exa (search) is another live x402 seller. This is x402's home turf.

2. Agent-to-agent commerce

One agent sells a service; another agent buys it — no human and no pre-arranged contract on either side. Because the x402 client is just a wallet wrapper, an autonomous agent can discover and pay any x402 endpoint on the open internet. Marketplaces like Agentic.Market lean into this: keyless, pay-per-use services designed to be consumed by other agents. This is the pattern most "agent economy" demos were missing a payment layer for — and it's why the agent-wallet guardrails matter so much here.

3. Metered LLM / model inference

Charge per inference instead of per subscription. Venice (private AI inference, image, code) sells model access over x402; Gemini is reachable the same way through Pay.sh. The fit is natural: inference cost is genuinely per-call, so per-call payment aligns price with usage without a billing relationship. For streaming token-by-token metering under a pre-authorized budget, note this is exactly where MPP's session model competes with x402's per-request settlement — pick by whether you're billing discrete calls or a continuous stream.

4. Data & RPC monetization

Solana infra providers were among the fastest x402 adopters because their product is metered API access. Helius, Alchemy, and QuickNode expose paid RPC and data; analytics platforms like Nansen, Dune, and Messari sell query access over x402. For an agent doing on-chain research, "pay $0.001 for this RPC call" beats provisioning an API key it can't sign up for. Monetizing your own data endpoint is one of the lowest-friction ways to ship something real with x402.

5. Paywalled content

The oldest dream of HTTP 402: charge a few cents to read an article or fetch a file, with no subscription and no ad model. x402 ships paywall packages for exactly this. It's the least agent-specific pattern — and, candidly, the one with the least proven human demand — but it's a clean fit for machine-readable content an agent wants to fetch and pay for inline.

6. Paid MCP tools

The newest pattern: monetize a tool in an agent's MCP toolbox directly. Vercel's x402-mcp lets a server author put a price on a tool (paidTool), and the official Python SDK ships an x402[mcp] extra. Instead of selling an API and hoping agents find it, you publish a tool the agent already knows how to call and charge per invocation. Covered in depth in the agent-payments piece.

Operational patterns that cut across all six

• Prepaid credits / batching. For latency-sensitive or high-frequency paths, don't settle every call. Sell a block ("$1 for 1,000 calls") and meter against it. This is an application pattern — x402 has no refund or credit primitive in-spec, so you build it.
• Gas sponsorship. A facilitator like PayAI can front gas for both sides, so buyers need only the stablecoin, not SOL. Removes a real onboarding cliff for agents.
• Discovery. Service-discovery layers (x402's own registry, explorers like x402scan) let agents find paid endpoints, not just pay known ones.

When x402 is the wrong tool

Reach for something else when:

• It's B2B with a relationship. Contracts, SLAs, invoicing, identity, abuse controls — that's an API key and a billing system, not permissionless micropayments.
• The path is latency-critical. A settlement round-trip (~400ms on Solana, more elsewhere) on every call hurts hot loops — batch with prepaid credits or don't gate that path.
• A human is at a checkout. That's Solana Pay (or cards), not x402.
• Value per transaction is high. Don't trust a hosted facilitator's yes/no for large settlements — verify on-chain yourself, or use a different settlement design entirely.

The honest read

The patterns are real and some are genuinely live — Pay.sh and the infra-monetization cases are the most convincing because the seller already had a metered product and x402 just removed the signup. The weaker cases are the speculative ones (human-facing paywalls, agent-to-agent "economies" with no agents yet), and the ecosystem's eye-popping transaction counts don't yet translate to large dollar volume — treat the "agent economy" framing as a bet, not a fact. The pragmatic move: if you run a metered API or a data endpoint on Solana, adding x402 is low-risk and opens you to a buyer (agents) that cannot use your signup form. Start there, where the demand is real, not where the narrative is loudest.

References

• x402.org — ecosystem & live sellers
• Solana Foundation — Pay.sh (Google Cloud APIs over x402)
• How an AI agent actually pays — x402 + MCP + agent wallets
• Build an x402 seller on Solana
• The agentic payments landscape — x402 vs AP2, MPP, L402

x402 isn't a product, it's a primitive — and primitives earn their keep one concrete pattern at a time. The six above are where it's already paying off on Solana.