Skip to main content
This page explains how an x402 payment works and defines the terms used across the Fireblocks x402 docs. Read it once and the rest of the documentation reads clearly. If you are deciding where to start, see Get Started with x402.

​
The 402 handshake

x402 revives the long-reserved HTTP 402 Payment Required status code and gives it a job. A single payment follows the same four-step handshake every time:
  1. A caller makes a normal HTTP request to a resource it wants.
  2. The server responds 402 Payment Required with a JSON quote: how much, in which asset, on which network, and to which address.
  3. The caller signs a one-time authorization to pay exactly that amount, then retries the same request with a payment-signature header.
  4. The server verifies the signature, settles the transfer on-chain, and returns the resource.
The authorization covers a single transfer of a specific amount. There is no long-lived approval, no subscription, and no payment account to maintain. The caller signs off-chain and spends no gas at signing time; the on-chain settlement happens on the server side.

​
Roles

Resource server (merchant). The server that owns the paid resource. It returns the 402, then calls the facilitator to verify and settle. In the Fireblocks model it keeps serving its own traffic; payments are a side call. Facilitator. The service that verifies a payment signature off-chain and settles the transfer on-chain. The Fireblocks facilitator settles through your Fireblocks vault, so raw private keys never leave Fireblocks. See Facilitator Overview. Caller, client, or payer. Whatever makes the request and signs the payment. It can be a browser, a script, or an AI agent. The x402 Agent is a payer that signs through a Fireblocks vault. Buyer and seller. The two sides of the market. Sellers run a facilitator and publish products; buyers run agents that pay for them. See Build an Agentic Product Catalog and Fund and Control Agent Spending.

​
Payment terms

Product. A payment-gated endpoint on the facilitator, with a price, accepted assets, and metadata. The unit a catalog is built from. See Build an Agentic Product Catalog. PaymentRequired body. The JSON the server returns with a 402. It carries an accepts[] array, one entry per way to pay. Each entry names a scheme, network, amount, asset, and the recipient address (payTo). See the Protocol Reference. Scheme. How the amount is interpreted. exact charges precisely the quoted amount. upto authorizes a ceiling and lets the facilitator settle any amount up to it, which suits metered or usage-based billing. payTo. The on-chain address that receives the payment, derived from the merchant’s Fireblocks vault. Settlement. The on-chain step where the authorized transfer actually moves tokens. The Fireblocks facilitator settles with a CONTRACT_CALL transaction through your vault. Asset. The token used to pay, identified to Fireblocks by a native asset ID (for example, USDC_BASE). Stablecoins like USDC are the common choice. See Supported Networks and Assets.

​
Transfer mechanisms

A transfer mechanism is the on-chain method that moves the tokens once a payment is authorized. It determines what the payer signs and how settlement executes. The Fireblocks facilitator supports four: The x402 Agent signs eip-3009 and permit2. It does not sign erc7710, because Fireblocks cannot sign delegation payloads. For how a merchant chooses and offers mechanisms, see Transfer mechanisms.

​
Cryptography and standards

EIP-712. The Ethereum standard for signing structured, human-readable data. An x402 payment authorization is an EIP-712 typed message, so the payer signs a clearly defined object (amount, recipient, deadline) rather than opaque bytes. See EIP-712. EIP-3009 (TransferWithAuthorization). A token standard that lets a holder authorize a transfer with a signature, which a third party then submits. USDC implements it. This is what the eip-3009 mechanism uses. See EIP-3009. Permit2. A Uniswap-deployed contract that enables signature-based transfers for any ERC-20, used by the permit2 and upto-permit2 mechanisms. See Permit2. Nonce. A unique value included in each authorization so a signature cannot be replayed for a second payment. Payment Instruction Integrity (PII). An optional extension where the facilitator signs the payment-critical part of the 402 body (the accepts[] entries) with an ES256 key published at a did:web address. A wallet or agent fetches that key and refuses to sign if the instructions were altered in transit. See Payment Instruction Integrity.

​
Networks and money

Network. The EVM-compatible blockchain a payment settles on, identified in the CAIP-2 form eip155:<chainId> (for example, eip155:8453 for Base). x402 supports many networks; cost and finality differ across them. Testnet and mainnet. Test networks (Base Sepolia, Ethereum Sepolia) use valueless tokens from faucets and are where you evaluate x402. Mainnet moves real value. The Fireblocks facilitator is testnet-only unless you explicitly opt in. See Supported Networks and Assets. Gas. The on-chain transaction fee paid to settle. Because settlement cost varies by network (cents on Base, more on Ethereum mainnet), the network you accept affects the economics of small payments. See Pricing modes.

​
Discovery

Discovery API. A public catalog the facilitator exposes at GET /api/discovery/resources, listing products marked discoverable so agents can find them. See Publish to the discovery catalog. Bazaar. The Coinbase-run directory of x402-enabled services. The Fireblocks discovery response follows the same shape, so Bazaar-aware agents can read your catalog. See x402 Ecosystem and Interoperability.