Before an x402 payment: seven checks for your agent
Guides
Check price, network, recipient, resource and result before an agent authorizes a paid API request.
An HTTP 402 response is a payment request, not a completed purchase. In the x402 protocol it carries the accepted payment requirements. An agent should read those requirements and compare them with its own rules before creating a signature.
1. Check the resource and inputs. The stated URL and description must match the intended task. For POST endpoints, the request schema, required fields and examples are part of the check. A correct payment cannot repair unsuitable or incorrectly formatted input.
2. Check amount and denomination. x402 v2 carries the amount in the smallest unit of the stated asset. The agent therefore has to evaluate amount, asset and decimals together. A price page read earlier is useful guidance; the payment requirement for the particular request is the authoritative offer.
3. Check network, scheme and recipient. The agent should select only a payment option supported by its wallet. x402 v2 describes networks with CAIP-2 identifiers, such as eip155:8453 for Base mainnet. The recipient address and maximum validity period also belong in an explicit authorization rule.
4. Limit budget and retries. An agent needs a per-call limit and preferably an additional limit per task or time period. The protocol specification does not provide a general client budget manager. If settlement or delivery is unclear, the agent should not create a new payment authorization merely because the first response is missing.
5. Store payment and delivery results separately. A successful x402 response carries a PAYMENT-RESPONSE settlement result. That documents payment, while the returned work still needs its own checks for content, format and completeness. For settlement_pending, Coinbase documentation recommends reconciling the transaction before requesting another payment.
6. Use free sources before the call. Public specifications, price information and service status can be read without payment. Status describes reachability and known limitations; it does not guarantee a later paid delivery. For an unresolved purchase, retain the request, payment requirement, payment response and purchase reference together.
7. Do not mix protocol versions or headers. x402 v2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. The older X-PAYMENT headers belong to v1. A version mismatch produces rejected payloads and should be detected before signing.