Skip to main content
This is a reference for the verification API’s payload adapter. For apps you can use inside a Desk, see Desk apps.
venue: x402. Over HTTP, 402, x402payments, coinbasex402 and http402 also resolve to it. An x402 endpoint answers an unpaid request with HTTP 402 and payment terms. The client signs a USDC authorization and retries, and a facilitator settles it on chain. Settlement cannot be reversed. Verify the terms after you receive them and before you sign. On this path Chance does not sign or settle anything.

What to send

Both shapes are detected without venue, and both are in the payment family. v1 terms that use maxAmountRequired are accepted and noted. The first accepts entry is judged as the payment, and the others are listed as alternatives. For a signed payload, authorization.to and authorization.value are what settle, so the summary uses them, and any difference from the displayed terms is flagged as critical. Anyone holding a signed payload can settle it, so verify before signing.

Checks on the payload

  • The dollar value is shown only when asset is the canonical USDC contract for the network (Ethereum, Base, Polygon, Arbitrum or Base Sepolia). Any other asset is shown as raw units of an unrecognized token.
  • An extra.name that does not match canonical USDC’s EIP-712 domain name, which suggests spoofed terms.
  • A scheme other than exact or upto. With upto, the signature authorizes a maximum and the seller settles actual usage.
  • An unknown network, a testnet, a payTo that is not an EVM address, and an amount that is not an integer.
  • maxTimeoutSeconds above 3,600, a plain http:// resource URL, and a missing resource URL.
  • The classifier never copies the seller’s resource description or 402 error text into its summary or notes. If either contains text aimed at the verifier, a note flags it as a manipulation attempt and requires a BLOCK.
  • For signed payloads, the time left before validBefore, or that it has passed.

Live checks

The adapter runs these at the same time, within 6 seconds in total:
  1. Live terms. It requests the resource URL itself (GET, then POST if the server answers 405, without following redirects) and decodes the 402 from the PAYMENT-REQUIRED header or the body. It compares scheme, network, asset, payTo and amount with the quoted terms and reports a match, a price mismatch, terms the endpoint does not offer, or a status other than 402. Local and private addresses are never requested. Cached for 60 seconds.
  2. Vendor history. It searches the Coinbase x402 Bazaar for the resource’s host. For a listing with the same payTo, it reports paid calls and unique payers over the last 30 days and the last payment date, and flags fewer than 5 payers. No listing is noted as a caution. Cached for 5 minutes.
  3. Payee profile, on Base and Ethereum: whether payTo is a contract, and its USDC balance.
  4. Payer checks, for signed payloads on Base and Ethereum: whether the payer holds enough USDC, and whether it has EIP-7702 delegated code, which would stop the signature from settling.

Examples

Probe the endpoint, verify the decoded terms, and sign only on ALLOW:
With curl, against Chance’s own credit top-up endpoint. Read your top-up code, fetch the live terms, and submit them unchanged:
The terms ask for the price of 20 credits in USDC on Base (1.00at1.00 at 0.05 a credit). The live-terms check requests the same URL and should report an exact match.

From an MCP client

Instruct the agent to call verify_intent before signing any x402 payment, with your rules as intent, the decoded terms as action and venue: "x402", and to act only on ALLOW. To have Chance pay from an escrow wallet instead, use escrow_pay_x402: it fetches the terms itself, puts them through the wallet’s rules and pays only if they pass. See Pay from an escrow wallet, and the dashboard verifier for running the same checks by hand.