Quack AI (@QuackAI_AI): The Buyer Side of x402

The Buyer Side of x402 The seller side of x402 has been complete for a while. If you want to charge per HTTP request, the protocol gives you a machine-readable 402 response, a facilitator that verifies signatures and settles the payment, and a discovery layer (Bazaar) that indexes what you offer. A seller can go from an idea to a live paid endpoint on Base without leaving the reference implementation. The buyer side is not in the same shape. When the client is an AI agent instead of a human clicking through a checkout, four questions still have to be answered inside the buyer's process, and the shipped toolchain leaves them to the application layer. The four buyer-side problems 1. How does one client pay any x402 endpoint? The x402 v2 spec defines SettleResponse and returns it to the buyer over PAYMENT-RESPONSE. The reference client parses that header. Neither of those is a client an agent can just plug into. An agent needs a general-purpose fetch that reads any 402 response, matches the accepted terms, signs the right authorization, and retries with the correct header. 2. How does the buyer stay inside a budget? Nothing about x402 itself keeps an agent from signing away the wallet on a single call. Spend limits are the buyer's job, or nobody's. 3. When the wallet was charged and the content never came back, what does the client say? The x402 spec has error semantics for payment failure. It has no error semantics for "settled on-chain, no service grant." That case is real: the seller can accept payment and return an error response. The reference SDK throws when the settlement header is missing and treats the "seller took payment, replied with an error body" path as a plain HTTP error. Nothing is classified, nothing is retained. 4. When the amount is large or delivery is uncertain, how does the buyer avoid handing over funds up front? Instant transfer is the default settlement path. Locking funds until the buyer confirms delivery is out of scope for the standard 402 exchange. Every one of these has an answer somewhere in the seller-side ecosystem: facilitator KYT, Bazaar discovery, the official Offer & Receipt extension (seller opt-in), third-party escrow with arbiters. All of those require the seller to change something, or to route through a different rail. None run inside the buyer's process. What Q402 shipped on Base Over the last 30 days, four pieces landed that answer the four questions above from the buyer side, without asking the seller to change anything about their endpoint. q402_x402_fetch: one buyer client for any x402 endpoint q402_x402_fetch ships in @quackai/q402-mcp as a general-purpose x402 buyer client. It reads the accepts payload, validates the seller is asking for scheme=exact, network=base, and Base USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913), signs an EIP-3009 TransferWithAuthorization against USDC's own EIP-712 domain, and retries with the correct header: PAYMENT-SIGNATURE for x402 v2 sellers, X-PAYMENT for v1 legacy. Non-402 responses pass through unchanged, so the same tool works as a plain HTTP fetch on non-paid endpoints. Two guardrails run inside the client, before any signature is produced: • Two-phase consent. The initial call returns needs_confirmation with a preview containing amount, recipient, and chain. The agent has to re-call with the returned consentToken before the signature is produced. An LLM saying "yes" to itself does not spend money. • Session cap. Q402_X402_SESSION_CAP_USD (default $5) is a cumulative cap across the whole MCP session, on top of Q402_MAX_AMOUNT_PER_CALL (default $200). When the running total plus the next call would breach the cap, the request is blocked before the signature is produced. The session cap resets on MCP server restart. Settlement forensics with three states, not two q402_x402_fetch does not collapse the world into "success" and "failure." Every failed paid request is classified into one of three settlement states, with machine-readable fields: success: true (paid: true, payTo, amountUsd, body): Content delivered, payment settled. success: false, status: "settled_no_delivery" (fundsMoved: true, retrySafe: false, txHash, recipient, amount, guidance): The response carried a txHash that proves funds moved, and the seller returned an error body. Do not tell the caller the payment did not go through. Do not retry: a retry is a second payment. Surface the txHash so the caller can reconcile with the seller. success: false, status: "settled_status_unknown" (fundsMovedUnknown: true, retrySafe: false, txHash: null, guidance): The payment header was sent, but the response contained no settlement proof. Funds may or may not have moved. Do not retry with the same parameters, funds may already have moved. Surface guidance so the caller can check the wallet balance. success: false (other) (error): Blocked or rejected before settlement. No funds moved. Safe to retry. Every 402 attempt (settled, settled_no_delivery, settled_status_unknown, or blocked) is appended to a local audit log at ~/.q402/x402-audit.json and surfaced in q402_agent_spend_report. settled_no_delivery and settled_status_unknown both count as spend. Scope note: this is forensics and safe-retry logic, not fund recovery. The txHash primitive comes from the x402 v2 spec itself. What the client adds is state classification, evidence retention, and a retry policy on top of it. A 2026-09-03 scan of x402 non-delivery handling looked at Coinbase CDP + Bazaar, the x402 Offer & Receipt extension, x402r, Google AP2, Stripe ACP, Virtuals ACP, PayAI, Skyfire, Nevermined, and ERC-8004 reputation. Every published mitigation attacks non-delivery from the seller side or the protocol side. A buyer-side three-state classifier does not appear in that surveyed set. Escrow on Base: lock, release, refund For amounts and workflows where instant settlement is the wrong default, the Q402 escrow vault is now live on Base mainnet. The whitelist is Circle USDC and bridged Tether USDT. Single-transaction cap is $500. Gas is sponsored by the Q402 relayer. Three tools cover the happy path: • q402_escrow_create returns a pending escrow id, no funds move yet. • q402_escrow_lock funds the escrow gaslessly, and the seller can verify it on chain. • q402_escrow_release moves funds to the seller when the buyer approves. On the server-managed Agent Wallet path, release approval is a manual step in the Q402 dashboard: the human owner of the Agent Wallet signs off on release, not the agent by itself. Two more tools finish the lifecycle: • q402_escrow_refund returns funds to the buyer permissionlessly after the deadline. • q402_escrow_dispute is available when the escrow was created with a named arbiter. The buyer does not have to send funds forward on the strength of a promise. Same signing path, three signing modes All four pieces settle gaslessly. The buyer signs, the Q402 relayer pays the gas. The buyer picks who holds the signing key: • The buyer's own EOA signs locally. • An exported Agent Wallet key signs locally. • The server-managed Agent Wallet signs on the buyer's behalf, with no private key on the client. The three modes share the same EIP-712 + EIP-7702 relay path for q402_pay and the same EIP-3009 authorization path for q402_x402_fetch. Server-managed signing is optional, any of the three modes is a supported route. The buyer side, closed The seller side of x402 answered how an agent gets paid. The buyer side is what has to be in place for an agent to spend on the same rail without a human sitting next to it on every call: a general-purpose x402 client, guardrails the agent cannot bypass, a settlement classifier that tells the truth when things go wrong, and a lock-then-release option for when instant is the wrong default. With those four pieces on Base, an agent building on x402 has a buyer side that developer teams can plug into today.