x402 Payment Checklist: 7 Checks Before an AI Agent Signs

When an x402 server answers with HTTP 402 Payment Required, the agent holding the wallet has to decide whether to sign. The 402 response is untrusted input from a third party, and it tells the agent who to pay, how much, in what asset, and on which chain. An agent that signs whatever the challenge says is trusting the seller completely.

This post is a checklist of seven things to verify on an x402 challenge before an agent signs a payment authorization. It applies to x402 v1 and v2, and to any facilitator, including Coinbase's CDP facilitator. For each check it says what to look for, what a bad value looks like, and what ContextIQ's x402 Inspector and Policy Check automate versus what your own agent policy has to enforce. (If you're new to the protocol, start with What Is x402?.)

What an x402 Challenge Looks Like

A v2 challenge is a JSON envelope, delivered base64-encoded in the PAYMENT-REQUIRED response header. A decoded example, for a $0.001 USDC payment on Base:

{
  "x402Version": 2,
  "error": "Payment required",
  "resource": {
    "url": "https://api.example.com/paid",
    "description": "Example paid endpoint",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "1000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x5b078ab958921613B71bc2A849b092dB83f07b46",
      "maxTimeoutSeconds": 120,
      "extra": { "name": "USD Coin", "version": "2" }
    }
  ]
}

Every check below maps to a field in this object. For how v1 differs (maxAmountRequired, plain network names like base), see x402 v1 vs v2.

Check 1: Read the Right Copy of the Challenge

In x402 v2 the PAYMENT-REQUIRED header is the authoritative copy of the challenge. The response body is optional, and a seller can send a body that parses fine but contains no usable accepts[], while the real challenge sits only in the header.

Do: parse the header first and fall back to the body only when there's no header.
Red flag: the header and body disagree on payTo, amount or network. Treat the header as authoritative, and treat the disagreement itself as a reason for a human to look.
Automated: the x402 Inspector reads the header first, falls back to the body, and warns when the two differ.

Check 2: Verify `payTo`

payTo is where the money goes. Two separate questions:

Is it a well-formed address for that network? An EVM address is 0x plus 40 hex characters. A Solana address is a base58 string. A malformed payTo means the payment can never complete.
Is it the recipient you expect? Format validity says nothing about identity. If your agent is meant to pay a specific counterparty, compare payTo against that counterparty's known wallet. For an agent registered on ERC-8004, the Identity Registry's getAgentWallet is one source (see the ERC-8004 Inspector).

Automated: format validation per network family.
Your policy: an allowlist of recipients or hosts.

Check 3: Decode the Amount, Don't Trust the Label

The amount field is a string of integers in the asset's smallest unit. USDC has 6 decimals, so "1000" is 0.001 USDC and "1000000" is 1 USDC. Three ways this goes wrong:

Unit confusion: an agent that reads "1000000" as cents sends $10,000.
Not an integer string: a decimal, a negative number or a missing field.
Zero: "0" passes a pure format check. A zero amount can be a legitimate free tier, or a sign that the challenge isn't what it claims. Don't treat it as automatically safe.
Do: decode with the correct decimals and compare against a per-request spending cap.
Automated: the Inspector checks the amount is a non-negative integer string and renders a human-readable USDC amount for known USDC contracts.
Your policy: the maximum you're willing to pay per call.

Check 4: Verify the Asset Contract

asset is the token contract address. A challenge that says "USDC" in its extra.name but points asset at a different contract is asking you to pay in a different token.

Do: keep a table of the stablecoin contracts you accept per network. USDC on Base is 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913.
Red flag: an asset that isn't in your table, or whose on-chain name() doesn't match extra.name. For EIP-712 signing the extra.name and extra.version also have to match the token contract, or the signature is rejected on settlement.
Automated: address-format validation and, on supported EVM networks, a comparison of the token's on-chain name() with extra.name.
Your policy: which assets you accept at all.

Check 5: Classify the Network Identifier

v2 networks are CAIP-2 identifiers: eip155:8453 is Base, eip155:84532 is Base Sepolia, and Solana uses a genesis-hash reference. v1 used plain names like base. There are three different situations, and they call for different responses:

Network string	Class	What it means
`eip155:8453`, `base`	Recognized	A chain your agent knows and can pay on
`eip155:999999`, `xrpl:0`	Plausible but unknown	Well-formed, but not a chain your tooling knows. Likely a newer network, not a typo
`eip155: 84 53`, empty string	Malformed	Not a valid identifier. A seller bug to report

An unknown-but-plausible network is not an invalid challenge, but you probably can't pay it, so skipping it is the safe default. A malformed one is a misconfigured endpoint.

Automated: ContextIQ tags each offer's network as recognized, plausible-unknown or malformed, and no longer reports a well-formed unknown chain the same way as a garbage string.
Your policy: the networks your agent is willing to pay on.

Check 6: Know Which Payment Scheme You're Signing

scheme determines what the amount means:

exact — the amount is the price. You pay exactly this.
upto — the amount is a maximum. The final charge can be lower, but you're authorizing up to the cap. Variable pricing needs a spending limit more than a fixed price does.
batch-settlement — payments are settled in batches rather than per request, which changes when and how funds move.

If your agent only understands exact, an unfamiliar scheme means it shouldn't sign.

Automated: the Inspector flags any scheme other than exact as one it doesn't treat as the standard case.
Your policy: which schemes you allow, and whether to permit variable pricing.

Check 7: Match `resource` to the URL You Requested

The challenge's resource.url says what you're paying for. It should match the URL your agent actually requested. A mismatch can be harmless, such as a trailing slash or http versus https, or it can mean the payment is attached to a different host.

Do: compare the hosts exactly. A different host between request and resource deserves the most suspicion.
Automated: the Inspector warns when resource doesn't match the requested URL.
Your policy: require an exact match, or allow normalization differences.

When `accepts[]` Has More Than One Offer

Many sellers publish several offers: different networks, assets or schemes. Run the checks on the offer your agent will actually pay, not just the first one in the array. A problem on an offer you won't use is a note, not a blocker.

What to Automate and What to Enforce Yourself

Check	ContextIQ checks it	Your agent policy decides
1. Header vs body	Yes	What to do on disagreement
2. `payTo`	Format	Which recipients to allow
3. Amount	Format and decoding	Per-call spending cap
4. Asset	Format and on-chain name	Which assets to accept
5. Network	Recognized, plausible-unknown or malformed	Which networks to pay on
6. Scheme	Flags non-`exact`	Which schemes to allow
7. Resource	Warns on mismatch	Strict or lenient matching

ContextIQ reports what's structurally wrong or unusual about a challenge. Limits, allowlists and "should I pay this" are your policy, because the right answer depends on what your agent is for. Policy Check combines the challenge scan with an ERC-8004 identity and reputation lookup into a single allow, warn or block decision, with an itemized reason for every point of the score. The worked examples post shows what those decisions look like on real endpoints.

FAQ

Should an AI agent pay every x402 402 response?

No. A 402 response is untrusted input. The agent should verify the recipient, amount, asset, network, scheme and resource against its own policy before signing, and only then authorize payment.

What does `upto` mean in an x402 challenge?

upto means the amount is a maximum charge rather than a fixed price. The actual charge can be lower, but the agent is authorizing up to that cap, so a spending limit matters more than it does for exact.

Is an unrecognized x402 network a malformed challenge?

Not necessarily. A well-formed CAIP-2 identifier like eip155:999999 can be a valid chain your tooling doesn't know yet. A string that isn't a valid identifier at all is malformed.

Is an x402 amount of zero safe?

Not automatically. A zero amount passes format validation and can be a legitimate free tier, but it can also indicate a misconfigured or misleading challenge. Treat it as a signal to review.

How do I check an x402 endpoint without paying?

Use the x402 Inspector. It sends a request, reads the 402 challenge and reports what's wrong or unusual about it, without making a payment.

Try It

Paste any endpoint into the x402 Inspector to see how it scores against these checks, or run Policy Check to get a pre-payment decision from your own agent framework. Policy Check is a Pro feature, and the Inspector is free.