Skip to content

Payment protocol · checked 9 November 2026

Agent payment safety checks for x402

An HTTP 402 payment protocol where an agent signs a payment authorization, retries the request, and a facilitator verifies and settles it on chain.

What your agent needs to know about x402

When it counts as settled
The client retries the request with a PAYMENT-SIGNATURE header carrying the signed payment payload (X-PAYMENT in v1). The resource server then verifies it, locally or through the facilitator /verify, and settles through /settle. The facilitator submits the transaction, waits for confirmation, and the server returns 200 with a PAYMENT-RESPONSE header holding the settlement JSON. Treat the payment as final only when settle returns success with a transaction hash, and then apply the underlying chain's finality. A settle timeout is indeterminate: the facilitator may have completed it. A settlement_pending response carries the hash so you can reconcile on chain before retrying.[1],[2],[3]
Fees
In the exact scheme the facilitator pays gas. Docs say the CDP facilitator gives 1,000 onchain transactions free each month, then charges $0.001 each, and verification is free. The Permit2 path needs a one-time approval; with the direct option the agent wallet pays gas for that approval and needs native gas currency, while sponsored options let the facilitator cover it.[2],[4]
Stablecoins
The default EIP-3009 path only works with tokens that natively implement transferWithAuthorization, such as USDC. Other ERC-20 tokens need the Permit2 path (extra.assetTransferMethod set to permit2). CDP docs list Base, Polygon, Arbitrum, Monad, World and Solana. Stripe documents x402 with USDC on Base. Circle can block addresses on its native USDC contracts; check the issuer's terms.[2],[4],[6],[7]
Issuer-published contract addresses. Compare all of it, not the first and last characters.
TokenAddressSource
USDC (Base mainnet, native)0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913[7]

How agent payments go wrong on x402

  1. 1. Settle timeout treated as failure

    A settle call that times out may still have been broadcast and confirmed. If the agent retries blindly it can pay twice or lose track of the first payment. Keep a pending-settlement record keyed by payment payload and reconcile by transaction hash before any retry.[2],[3]

  2. 2. Serving the resource before settlement

    Verify only checks the signature, balance and window, and simulates the transfer. Balance can move between verify and settle, so a server that delivers on verify alone can be left unpaid. Deliver after settle returns success, or accept the risk explicitly for cheap calls.[1],[2]

  3. 3. Expired authorization window

    The EIP-3009 payload carries validAfter and validBefore. If the agent signs, then queues or retries past validBefore, settlement reverts. Sign close to use and re-sign on a fresh nonce rather than reusing an old payload.[2],[5]

  4. 4. Untrusted facilitator or unpinned payment requirements

    The server relies on the facilitator's verify and settle results instead of checking chain state itself. The README says the public x402.org facilitator is for testnet. An agent should check that payTo, asset, network and amount in the 402 response match what it expects before signing, since a signed authorization is for exactly those values.[1],[3]

  5. 5. Duplicate submission on Solana and multi-instance servers

    Docs describe a 120-second in-memory SettlementCache on SVM and say multi-instance facilitators need a shared pending-settlement store. Without it, a retried request can broadcast twice. Run a shared store if you run more than one server instance.[3]

  6. 6. Unlimited or per-request spend with no cap

    Each 402 response is a fresh spend request. An agent that follows every 402 without a budget will pay whatever a hostile or buggy server asks, up to its balance. Enforce a per-request ceiling and a daily budget outside the model.[1]

Pre-flight checklist for a x402 agent

  • Compare payTo, asset, network and amount in the PAYMENT-REQUIRED header to an allowlist before signing.
  • Set a per-request price ceiling and a daily budget enforced in code, not in the prompt.
  • Sign with a short validBefore and a fresh random nonce; never reuse a payload.
  • Treat a settle timeout as unknown; look up the transaction hash before retrying.
  • Do not use the public x402.org facilitator for mainnet.
  • Check the facilitator's settle response for success and a transaction hash, then confirm chain finality for larger amounts.
  • Use a dedicated low-balance wallet for x402 spending.

Run the checks now, free

The free tools run in your browser: nothing you type leaves your browser, and wallet reads go only to a public RPC.

  • The Wrong-Money Test

    Write down what happens when your agent pays the wrong amount, the wrong address or the wrong token on x402, and see whether the answer holds up.

  • Agent Spend-Cap Stress Test

    Work out how much your agents can really move in one window once retries, parallel runs and per-key limits stack up.

  • Agent Money Trace

    Joins on-chain transfers on Base, Ethereum, Arbitrum, OP Mainnet or Polygon to your run log, so every payment maps to a decision.

Want a second pair of eyes on how your agent pays on x402? Book the free 48-hour integration review (opens Cal.com in a new tab).

Explorers to confirm a payment

Sources

  1. [1] x402-foundation/x402 README, GitHub (x402 Foundation)
  2. [2] Exact scheme, EVM spec, x402 repository
  3. [3] Facilitator, x402 docs
  4. [4] CDP Facilitator, Coinbase Developer Platform docs
  5. [5] EIP-3009: Transfer With Authorization, Ethereum EIPs
  6. [6] x402 (Stripe machine payments), Stripe docs
  7. [7] USDC contract addresses, Circle developer docs

Checked against these sources on 9 November 2026. Networks change: confirm against the live docs before you rely on a number. This page is a checklist from public documentation. It is not a security audit, legal, compliance or investment advice.