x402 Header Decoder
Decode and build the x402 payment protocol headers — PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE (v2), or their v1 X-PAYMENT equivalents. Base64 → annotated fields, with amounts, networks, and EIP-3009 authorizations explained.
The three x402 headers
The x402 protocol (see the x402 Flow Simulator for the full handshake) moves all of its payment data in three base64-encoded JSON headers. The server quotes a price in PAYMENT-REQUIRED on a 402 response; the client answers with a signed EIP-3009 authorization in PAYMENT-SIGNATURE; and after on-chain settlement the server attaches the transaction receipt in PAYMENT-RESPONSE. Protocol v1 used X-PAYMENT / X-PAYMENT-RESPONSE headers and carried the payment requirements in the 402 response body — this decoder handles both generations and tells you which one it detected.
Reading the decoded fields
Amounts are atomic token units — "10000" means 0.01 USDC at 6 decimals; the decoder resolves the asset contract address against the Stablecoin Reference to convert automatically. Networks use CAIP-2 identifiers in v2 (eip155:8453 = Base) and plain strings in v1 (base). Inside a payment signature, the authorization block is the EIP-3009 TransferWithAuthorization message: validAfter/validBefore bound its lifetime and the 32-byte nonce prevents replay — the token contract burns it on settlement.
Common questions
Why does my decoded amount look 10,000× too big?
Amounts are always atomic units, never decimals. USDC has 6 decimals, so divide by 10⁶. Never assume 18 — check the token contract.
Is the PAYMENT-SIGNATURE header sensitive?
It authorizes exactly one transfer of a fixed value to a fixed recipient inside a short time window, and its nonce dies on first use. Intercepting it does not let an attacker redirect or increase the payment — but treat real headers as confidential anyway, since they can be settled by anyone until they expire.
Which header does my middleware actually read?
v2 servers read PAYMENT-SIGNATURE and fall back to the v1 X-PAYMENT for backward compatibility. If you are debugging a 402 loop, decode both directions here to check the version fields match.
Field layouts follow the x402 v1/v2 specifications (x402 Foundation). All decoding runs in your browser — headers are never uploaded.