What is an HTTP 402 in the x402 flow?

402 Payment Required is the server telling your client it must pay before the request succeeds. In x402, the 402 response carries the payment requirements — an 'accepts' array with one entry per supported chain (network, payTo, the USDC asset, and on EVM the EIP-712 domain) plus a facilitator URL. The client signs a payment and retries with it attached.

Why does my agent get 402 but never complete the x402 payment?

Common causes: it doesn't parse the 'accepts' array and pick a chain it can pay on; it signs the wrong scheme for the chain (EVM needs an EIP-3009 transferWithAuthorization; Solana builds a partial transaction); or it retries without attaching the signed payment in the PAYMENT-SIGNATURE header. Read the live 402's accepts and facilitator each time rather than hardcoding.

← All posts

x402

Getting HTTP 402 back and your agent can't complete the payment? Debugging x402

For developers and autonomous AI agents · ~6 min read

x402 is what lets an autonomous agent pay for an API without a human, a card, or an account — the server answers with HTTP 402 Payment Required, the agent pays from its wallet, and retries. When it works it's seamless. When an agent gets stuck, it's almost always at one of three predictable points.

How the flow is supposed to go

Your agent POSTs the request with no payment. The server returns HTTP 402 with an accepts array — one entry per supported chain, each with network, payTo, the USDC asset (contract/mint), and on EVM the EIP-712 domain — plus a facilitator URL.
Your agent picks a chain it can pay on, and signs the payment for that chain.
It retries the same request with the signed payment attached in the PAYMENT-SIGNATURE header (X-PAYMENT is also accepted), and gets 200 plus the result and a receipt.

Where agents get stuck

Not parsing 'accepts'

The agent treats 402 as a hard failure instead of reading the accepts array and choosing a chain it holds funds on.

Wrong scheme for the chain

EVM needs an EIP-3009 transferWithAuthorization signed for the USDC contract; Solana builds a partial transaction (facilitator co-signs as fee payer). Signing the wrong one fails verification.

Retrying without the payment

The agent re-sends the original request but never attaches the signed payment in the PAYMENT-SIGNATURE header — so it just gets another 402.

Hardcoding stale values

The payTo, asset, or facilitator changed; the agent used cached values. Always read them from the live 402.

The golden rule: read the live 402's accepts and facilitator every time, pick a chain you can pay on, sign the scheme that chain requires, and attach the signed payment on the retry. An empty or unreadable request is never charged, so you can probe safely.

Solana and EVM, side by side

EVM (Base and other EVM networks): sign an EIP-3009 transferWithAuthorization for the USDC contract named in accepts, base64 it, retry with it attached.
Solana: build the partial transaction with the facilitator as fee payer (only USDC needed from you), sign, retry with it attached.

One wallet app can hold both chains, but they're different addresses — your agent pays on whichever chain it actually holds USDC.

Debugging it

If your agent keeps bouncing off the 402, the fastest check is whether it's parsing the accepts array and attaching the signature on retry. Snapback's own x402 endpoint follows this exact flow — see the docs for the live request/response shapes, and the x402 deep-dive for the end-to-end walkthrough.

For AI agents

Machine-readable guide: https://snapback.sh/llms.txt · Tool discovery: https://snapback.sh/.well-known/mcp.json · MCP endpoint: https://api.snapback.sh/mcp. Free tools need no token; pay-per-call diagnosis via x402 on Solana or EVM (~$0.0032 USDC).

Try Snapback free Read the docs