x402 payments

x402 puts payment into HTTP: a paid endpoint answers 402 with payment terms, the client signs a USDC authorization, and a facilitator settles it. Settlement cannot be reversed. There are two ways to use Chance with it.

	Verify before you sign	Pay from an escrow wallet
Who holds the wallet	Your agent	Chance, in an escrow wallet
Call	`POST /api/v1/intent` or `verify_intent` with `venue: "x402"`	`escrow_pay_x402` (MCP only)
Who reads the terms	Your agent sends them	Chance fetches them from the URL
Who signs	Your x402 client, on `ALLOW`	Chance, on `ALLOW` from an autonomous wallet, or after the owner confirms
Cost	1 credit	1 credit

Verify before you sign

Probe the paid URL without paying, decode the PAYMENT-REQUIRED header, and send the decoded object as action with venue: "x402". Let your x402 client sign only on ALLOW.

import { decodePaymentRequiredHeader } from "@x402/core/http";
import { wrapFetchWithPayment, x402Client } from "@x402/fetch";
import { ExactEvmScheme } from "@x402/evm";
import { privateKeyToAccount } from "viem/accounts";

const paidUrl = "https://api.example.com/data";
const account = privateKeyToAccount(process.env.PAYER_KEY as `0x${string}`);
const client = new x402Client().register("eip155:8453", new ExactEvmScheme(account));
const fetchWithPay = wrapFetchWithPayment(fetch, client);

const probe = await fetch(paidUrl);
if (probe.status === 402) {
  const terms = decodePaymentRequiredHeader(probe.headers.get("PAYMENT-REQUIRED")!);

  const res = await fetch("https://harness.chance.cc/api/v1/intent", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.CHANCE_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      intent: "May buy API data up to $1 per call, USDC on Base only, from established vendors only.",
      action: terms,
      venue: "x402",
    }),
  });
  const check = await res.json();

  if (res.status === 201 && check.verdict === "ALLOW") {
    const paid = await fetchWithPay(paidUrl); // your client signs and retries
  }
}

action can be a whole PaymentRequired object, one entry from its accepts array, or a signed PaymentPayload. For a signed payload, the signed recipient and amount are judged, not the displayed terms. Before the judge runs, Chance gathers its own evidence: when the terms include the resource URL, it re-fetches the resource’s 402 and compares it with the terms you sent. It also looks up the payee in the Coinbase x402 Bazaar and checks the payee (and, for a signed payload, the payer) on chain. Vendor text aimed at the verifier is kept out of the classifier’s summary and flagged to the judge as a manipulation attempt that must be blocked; the raw payload you send still contains it. These findings reach the judge and are recorded in the run’s transcript. The API response carries the verdict and reasoning, not the individual findings. Your intent is the policy. There is no default policy over the API. The x402 venue page lists the recognized payload shapes and their actionType values.

Pay from an escrow wallet

escrow_pay_x402 takes wallet, url, and optional method (GET or POST, default GET), maxAmount and note.

Chance fetches the terms

Chance requests the URL itself, with no body and no extra headers, and expects a 402. The agent never supplies the terms, so it cannot describe a cheap payment while having Chance sign an expensive one.

Chance picks an option

Among the accepts entries, only x402 v2, scheme exact, USDC on the wallet’s own chain are payable. The cheapest payable option is chosen.

The proposal goes through the gate

The payment is proposed like any other escrow action: checked against the wallet’s limits, judged against its mandate, 1 credit. The terms Chance fetched are given to the judge as trusted context.

Pay or hold

On an autonomous wallet an ALLOW signs the authorization, completes the paid request and returns what the resource sent back. Otherwise the tool returns an approval link.

The request is refused, with no credit charged, when:

the URL is not a public http(s) address, or the resource redirects (pass the final URL);
the resource does not answer 402, or needs a request body or headers;
no option is x402 v2, exact, USDC, on the wallet’s chain;
the invoice is above maxAmount (in whole tokens, for example "0.50"). Set it: you do not know the price until Chance fetches the terms;
the resource’s description addresses the verifier instead of describing the product;
the wallet is not a Base or Ethereum wallet, or has custody: "embedded";
the wallet has become a smart account by using sponsored gas or a batched transaction (a swap is one) and can no longer sign this kind of payment. Use a separate wallet for x402 payments.

Other rules:

The facilitator pays gas, so the wallet needs only USDC.
The signed authorization is valid for 2 hours.
A failed payment still counts toward the wallet’s rolling 24-hour cap, because a signed authorization may have been settled.
Chance checks again, when it signs, that the wallet address carries no contract code. If it does, the payment fails and nothing is signed. The credit for the verdict is not refunded.

The dashboard verifier

harness.chance.cc/x402 runs the same verification from a form. Paste a PaymentRequired object, an accepts entry or a signed PaymentPayload, and optionally your own mandate. Each run costs 1 credit. It shows the verdict and the six check categories below, and has six built-in examples: one legitimate vendor and five attacks. When you leave the mandate empty, the dashboard applies its default: allow only canonical USDC on a supported mainnet, a sane amount (over

5 per call counts as significant), live terms that match, and either a Bazaar listing with recent usage or a trivial amount (at most

0.10). It blocks unknown assets, price mismatches, spoofed terms, already-signed authorizations, significant payments to unlisted vendors, and any attempt to instruct the verifier. It escalates significant amounts with thin reputation or unconfirmed terms. This default applies only in the dashboard.

What the checks catch

Check	What it looks at	Pattern it catches	Built-in example
Asset and amount integrity	Whether the asset is canonical USDC, so the dollar amount is real	The seller picks the token: “$5” next to 5 whole units of an unknown 18-decimal token	Fake token as “$5”
Live terms verification	The endpoint’s current `402`, compared with the quoted terms	Bait-and-switch or stale terms	None
Vendor reputation and intent	The payee’s Bazaar listing: paid calls and unique payers over 30 days, and the last payment. Also vendor text aimed at the verifier.	A description telling the verifier the payment is pre-approved	Prompt injection
Payee on-chain profile	Whether the payee is a contract or a plain address, and its balance	A new address with no history	Unlisted, high value ($250 to an address with no Bazaar record)
Signed-payload integrity	The signed recipient and amount, and whether the payer can settle (balance, EIP-7702 delegation)	Displayed as $1 to a trusted vendor, signed as$ 999 to another address	Signature ≠ terms
Protocol and settlement safety	Scheme, network, expiry window	The `upto` scheme: advertised at about $0.02 per call, with a signed cap of$ 100 redeemable for an hour	upto blank check

An address missing from the Bazaar is a caution signal, not proof of fraud. Whether it blocks depends on the mandate.

Integrate

Chance verification

Payload adapters

HTTP endpoints

Verify before you sign

Pay from an escrow wallet

The dashboard verifier

What the checks catch

​Verify before you sign

​Pay from an escrow wallet

​The dashboard verifier

​What the checks catch

Verify before you sign

Pay from an escrow wallet

The dashboard verifier

What the checks catch