Accept x402-style payments from AI agents

1. Why agent payments need different rails

Subscriptions and API keys were designed for human-managed accounts. AI agents behave differently: they fan out across tools, make small paid calls mid-workflow, retry quickly, and need machine-readable receipts. If the agent has to wait for a human to pick a pricing tier, the workflow is already broken.

x402-style flows move payment negotiation into HTTP itself. The API can say: this endpoint costs this amount, in this asset, to this recipient. The agent can check its policy, sign authorization, retry, and continue.

2. The smallest viable x402-style flow

3. Pricing, budgets, and policy controls

A good provider integration exposes prices that software can reason about. Avoid vague “contact sales” flows for agent entry points. Start with deterministic prices for one or two high-value endpoints.

On the client side, every payment should pass a policy engine: per-call cap, daily cap, approved recipients, allowed chains/assets, endpoint category, and expiry. A wallet signs; a policy engine decides whether it should.

4. Receipts, settlement, and audit

The payment is not finished when the signature is produced. Production teams need a receipt surface that finance, compliance, and developers can query later.

{
  "receipt_id": "rcpt_01h...",
  "request_id": "req_01h...",
  "amount": "0.025",
  "asset": "USDC",
  "chain": "base",
  "recipient": "0xprovider...",
  "signer": "0xagent...",
  "resource": "/v1/research/report",
  "status": "settled",
  "settlement_ref": "0xtransaction...",
  "created_at": "2026-07-19T10:00:00Z"
}

At minimum expose GET /receipts/:id and GET /usage?address=...&from=...&to=.... Agent customers will ask for audits once spend becomes material.

5. Implementation sketch

Keep the first integration boring. Pick one read-heavy, idempotent endpoint. Price it. Return payment requirements. Verify authorization. Record a receipt.

async function paidEndpoint(req, res) {
  const proof = req.headers["x-payment"];

  if (!proof) {
    return res.status(402).json({
      amount: "0.01",
      asset: "USDC",
      chain: "base",
      recipient: process.env.PROVIDER_ADDRESS,
      resource: req.path,
      expires_at: Date.now() + 5 * 60_000
    });
  }

  const verification = await verifyPaymentProof(proof);
  if (!verification.ok) return res.status(402).json({ error: verification.reason });

  const data = await computeResource(req);
  const receipt = await createReceipt({ proof, resource: req.path, status: "settled" });
  return res.json({ data, receipt_id: receipt.id });
}

6. Provider launch checklist

• ✓ Pick one paid endpoint and one stablecoin asset.
• ✓ Publish machine-readable pricing and recipient metadata.
• ✓ Add max-price and approved-recipient examples to the client docs.
• ✓ Verify payment proof before expensive work is performed.
• ✓ Emit receipts and expose usage history.
• ✓ Document failure modes: expired quote, insufficient budget, unsupported asset, settlement pending, refunded request.
• ✓ Link your guide from your glossary/resource hub so AI answer engines can connect the entities.

Frequently asked questions