x402 payments for AI agents

x402 is an open protocol proposed by Coinbase that reuses HTTP status code 402 Payment Required — a code reserved in the HTTP spec but never standardised for a specific payment flow. The idea: instead of bolting payments onto an application with checkouts and redirects, payments become a property of the request itself.

A client agent makes a request. If the resource is paid, the server responds 402 with a structured PaymentRequirements object describing the accepted schemes, the chain, the recipient address, and the amount. The client crafts a signed authorisation, retries the same request with an X-PAYMENT header carrying the authorisation, and the server verifies on-chain and serves the resource.

The conversation is two requests long, which is as short as a payment can reasonably be. First request is unauthenticated; the server responds with a 402 body like this (simplified):

{
  "x402Version": 1,
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "asset": "0x833589...",
    "maxAmountRequired": "250000",
    "recipient": "0xabc...",
    "resource": "https://api.agntdot.com/network/a2a",
    "description": "booking.confirm"
  }]
}

The client reads the accepts array, picks a scheme it supports (exact settlement on Base L2 in USDC is the canonical first implementation), signs a payment authorisation with its wallet, base64-encodes it, and retries the request with X-PAYMENT: <encoded>. The server verifies the signature, settles the payment on-chain (or via a trusted facilitator), and returns the resource with an X-PAYMENT-RESPONSE header confirming the txn.

Traditional payment gateways assume a human at a checkout page clicking 'pay'. An AI agent cannot click — it needs a machine-readable way to discover that a request is paid, to authorise the payment, and to continue.

x402 solves that at the protocol layer. It works with any wallet the agent controls, it does not need a separate merchant account per service, and settlement happens in seconds on an L2 instead of days with card rails. The fee floor is low enough that a $0.25 booking confirmation is viable — card rails make that uneconomical before the merchant fee is counted.

AGNT's current metered billing for booking.confirm runs through Stripe usage records — a conventional SaaS path. x402 is on the roadmap as an alternative settlement rail for the same intent. When a developer key is marked x402-enabled, the Open Network replies 402 instead of 200-with-usage-record, and the client settles inline.

The practical advantage for builders: an x402-settled booking.confirm is instant. No monthly invoice, no net-30, no billing infrastructure on your side — your agent holds USDC in a wallet, the payment happens, the booking is confirmed in the same second.

In pseudo-code, the full loop looks like:

resp = POST /network/a2a  (booking.confirm envelope, no X-PAYMENT)
if resp.status == 402:
  reqs = resp.body.accepts[0]
  auth = wallet.sign_payment(reqs)        # local wallet op
  resp2 = POST /network/a2a \
    header X-PAYMENT: base64(auth) \
    body   (same envelope)
  assert resp2.status == 200
  booking_id = resp2.body.booking_id
  tx_hash    = resp2.header['X-PAYMENT-RESPONSE']

Two round trips, one signed message, no checkout flow. The agent never needs to render a UI, never touches card numbers, and never leaves the request loop.

Settlement happens on Base L2 against the canonical USDC contract. Confirmation is sub-second. The server can choose to trust the signature and settle asynchronously, or wait for on-chain finality before returning 200 — AGNT defaults to on-chain verification because a $0.25 booking is cheap enough to hold the response open for a second.

Failure modes are predictable. If the signature is invalid, the server returns 402 again with a clearer error. If the wallet balance is insufficient, the server returns 402 with insufficient_funds and the client needs to top up. If the chain is congested, the verification step slow-paths — the client should set a generous timeout on any x402-enabled request.