Building payment-native AI agents with aixyz and x402

Everyone's building AI agents. But almost nobody's figured out how agents get paid.

Think about it: you build a weather agent, a flight search agent, a code review agent. You want to expose it to other developers or other AI systems. What's the business model? API keys with monthly caps? Stripe subscriptions? Bearer tokens?

These all require accounts, signups, billing infrastructure. They work fine for humans. They're terrible for agent-to-agent communication.

The problem with paying for AI services today

When an AI agent needs to call another service, it typically:

1. Needs a pre-registered API key
2. Pays in bulk (subscription or credits)
3. Can't dynamically discover new services

This works when a human sets everything up in advance. It breaks down when agents need to autonomously discover and pay for services on the fly. Imagine your orchestrator agent finds a better translation service mid-task — it can't just use it. Someone has to sign up, add a credit card, generate a key, and redeploy. That's a human bottleneck in what's supposed to be an autonomous system.

HTTP 402 — the forgotten status code

There's a status code that's been "reserved for future use" since 1991: 402 Payment Required.

For 30+ years, nobody agreed on what it should actually do. The x402 protocol is one attempt to finally define it. The idea: a server returns a 402 with payment details (amount, token, chain), the client pays with a cryptographic header, and retries the original request. No accounts. No subscriptions. Pay per request, verified on-chain.

The flow looks like:

Agent A → GET /api/translate → 402 {price: $0.005, payTo: 0x...}
Agent A → signs USDC payment → retries with X-PAYMENT header
Server  → verifies on-chain → 200 {translation: "..."}

It's stateless and composable. Exactly the properties that made HTTP itself successful.

The emerging stack

x402 creates a viable payment rail for AI agents, but agents also need identity and discovery. A few complementary protocols are converging:

• ERC-8004 — a proposed standard for on-chain agent identity. Think of it as ENS for agents: a way to verify who you're paying and who is calling you, without a centralized registry.
• A2A — Google's Agent-to-Agent protocol. Agents publish a card at /.well-known/agent-card.json describing their capabilities, and communicate via JSON-RPC. It's basically a service mesh for AI.
• MCP — Anthropic's Model Context Protocol. While A2A handles agent-to-agent, MCP handles tool sharing with AI clients like Claude Desktop and Cursor.

None of these require each other, but they compose well. An agent can be discoverable via A2A, expose tools via MCP, and gate access via x402, all at once.

What the developer experience looks like

To make this concrete, here's roughly what a payment-gated agent looks like using aixyz, an open-source framework that wires these protocols together:

bunx create-aixyz-app my-agent
cd my-agent
bun install
bun run dev

Your agent is already running with three endpoints:

• /.well-known/agent-card.json — A2A discovery
• /agent — JSON-RPC with x402 payment gate
• /mcp — MCP tool sharing (works with Claude Desktop, Cursor, etc.)

Now define your agent and set a price in app/agent.ts:

// Define your agent's pricing
export const accepts = {
  scheme: "exact",
  price: "$0.005",  // per request, settled in USDC on Base
};

// Define your agent
export default new ToolLoopAgent({
  model: openai("gpt-4o-mini"),
  instructions: "You are a helpful weather assistant.",
  tools: { weather },
});

This gives you three endpoints out of the box: an A2A agent card for discovery, a JSON-RPC endpoint with x402 gating, and an MCP endpoint for tool sharing.

On the caller side, any agent (or human with a CLI) that speaks x402 can call this without prior registration. The payment handshake is just part of the HTTP exchange.

The honest tradeoffs

This approach isn't without friction, and it's worth being upfront about the downsides:

On-chain settlement adds latency. Even on L2s like Base, you're adding a verification step that a simple API key check doesn't need. For latency-sensitive pipelines, this matters. Optimistic verification and payment channels can help, but they add complexity.

Crypto is a hard sell for many developers. Plenty of teams building agents have zero interest in wallets, USDC, or anything blockchain-adjacent. Stripe is actively exploring agent billing with a more traditional model — OAuth-based, fiat-native, and already integrated with their existing merchant base. For teams already in the Stripe ecosystem, that path has much lower friction.

Micropayment economics are tricky. At $0.005 per request, gas fees need to be negligible or batched. Base and other L2s help here, but "negligible" is relative — if your agent makes thousands of calls per minute, even small per-transaction overhead compounds.

Discovery is still early. The A2A ecosystem is small. There's no mature marketplace where you can browse hundreds of agents with reputation scores and usage metrics. We're closer to "here are some repos on GitHub" than "here's an app store."

Where this is heading

The interesting thing isn't any one protocol. It's that the shape of the stack is becoming clear. Agents need:

1. Identity — verifiable, not just an API key
2. Discovery — dynamic, not hardcoded URLs
3. Payment — per-request, not pre-negotiated
4. Communication — structured, not bespoke REST endpoints

Whether the winning stack is x402 + ERC-8004 + A2A, or Stripe + OAuth + some future discovery protocol, or something else entirely — the problem is real and the design space is narrowing.

If you're building agents today and thinking about how they'll eventually pay and get paid, these are the protocols worth tracking:

• x402 spec
• ERC-8004 proposal
• Google A2A
• aixyz (open-source framework implementing this stack)
• Stripe Agent Toolkit (the fiat-native alternative)

Disclaimer: I'm a contributor to aixyz and use-agently. I've tried to present the landscape fairly, including alternatives like Stripe's agent toolkit, but you should know where I sit.