Create Your First Payment

x402 is Brain's protocol for machine-native payments over standard HTTP. Agents can pay for services in real time without API keys, without subscriptions, without manual billing.

How x402 Works

x402 operates entirely at the HTTP layer. When an agent requests a paid resource, the server responds with 402 Payment Required and a structured payment header. Brain handles the rest: policy check, on-chain payment, and retry.

1. Agent  ──── GET /resource →  Server
2.        ← 402 { amount, asset, merchant, nonce } ──
3.        → Brain Policy Engine → On-chain Settlement
4.        ──── GET /resource + X-402-Receipt →  Server ✓

Handling a 402 Response

import { handle402 } from '@brain-protocol/sdk';

async function callPaidApi(agentId: string) {
  const response = await fetch('https://api.example.com/v1/infer', {
    headers: { 'Agent-ID': agentId },
  });

  if (response.status === 402) {
    // Brain automatically handles payment evaluation,
    // on-chain settlement, and the retry
    return handle402(response, agentId, brainClient);
  }

  return response.json();
}

The PaymentIntent Object

When Brain parses a 402 response, it creates a PaymentIntent that is evaluated by the policy engine before any funds move:

type PaymentIntent = {
  agentId: string;      // The agent making the request
  resourceUri: string;  // The endpoint being accessed
  amount: string;       // e.g. "0.50"
  asset: string;        // e.g. "USDC"
  merchant: string;     // Merchant's on-chain address
  expiry: number;       // Unix timestamp — prevents stale charges
  nonce: string;        // Prevents replay attacks
};

Policy Checks Before Payment

The policy engine evaluates every PaymentIntent against the agent's configured rules before approving:

• Budget availability and daily/period limits

• Merchant allowlists or blocklists

• Approved assets and slippage constraints

• Frequency limits and rate limiting

x402 payment requirements include nonces and expiries to prevent replay attacks and stale charges. Payment receipts are tied to specific HTTP requests, providing end-to-end auditability from HTTP to on-chain settlement.

Full Payment Flow

1

Step 1: Initial request (no payment)

Agent sends GET /resource with Agent-ID header. No funds committed yet.

2

Step 2: Server returns 402

Response includes X-402-Payment header containing amount, asset, merchant address, expiry, and nonce.

3

Step 3: Brain parses and creates PaymentIntent

The Payment Orchestrator constructs the intent, linking agentId, resource URI, and all payment parameters.

4

Step 4: Policy engine evaluates

Budget, allowlists, and rate limits are all checked. If blocked, the payment is rejected before any funds move.

5

Step 5: On-chain settlement via ERC-4337

A UserOperation is submitted via the bundler and executed on Base.

6

Step 6: Retry with receipt

Brain replays the original request with the X-402-Receipt header. The server verifies and serves the resource.

Common Use Cases

Service	Description
AI Inference	Pay per call to OpenAI, Anthropic, or other model providers
Data Feeds	Real-time market data, oracles, or analytics endpoints
Agent-to-Agent	One Brain agent paying another for a sub-task or service
API Services	Any HTTP endpoint that accepts x402 payment headers