Install in an agent runtime

Check before payment and check the answer, inside your agent’s runtime

Your team installs 402Signal once in the payment path the agent already uses. After that, each supported paid call is checked before the agent’s own payment client pays, and the answer is checked against requirements fixed before paying. Nobody has to open 402signal.com, create an account or set up a separate wallet for a purchase.

Official x402 client (Node)

@402signal/route-guard/purchase wraps your x402Client and wrapFetchWithPayment. One call reads the seller’s offer once, runs the check (your client pays the $0.003 fee), verifies the signed receipt against that same offer, lets your client pay the seller once, and checks the answer.

import { checkedPurchases } from "@402signal/route-guard/purchase";

const purchases = checkedPurchases({ client, wrapFetchWithPayment, trustedLogVkey, store });
const result = await purchases.fetch(url, { method: "GET" }, { acceptance: contract, taskId });
// result.state, result.decision, result.acceptance.verdict

At most one checking fee and one seller payment happen per purchase. A timeout, a lost answer or an error without a settlement report is recorded as unresolved and, with a task id and a durable store, blocks that task until you reconcile it; nothing is retried. Outcomes, policies and records

AWS Bedrock AgentCore Payments (Python)

Turn off AgentCore’s automatic payment and add Signal402PaymentsMiddleware to a LangGraph agent, or Signal402PaymentsHooks to a Strands agent. A seller’s 402 is checked first; AgentCore then pays only the offer 402Signal verified, once, from the same payment session, which also pays the checking fee. AgentCore keeps the credentials, the payment instrument and the budget.

pip install "402signal[agentcore-langgraph]"

payments = AgentCorePaymentsMiddleware(AgentCorePaymentsConfig(..., auto_payment=False))
signal = Signal402PaymentsMiddleware(payments, trusted_log_vkey=VKEY, network="eip155:8453")
agent = create_agent(model=model, tools=[...], middleware=[payments, signal])

Integration notes and limits

Cloudflare Agents SDK

For paid MCP tools called through withX402Client, use the payment approval callback: it approves only when every advertised offer fits your policy (recipient, amount, how long the authorization stays valid), and checks the tool’s answer against requirements fixed at approval. A tool’s offer is not something the hosted check can observe, so this path applies your policy locally; for paid HTTP APIs, use the checked purchase above. Cloudflare example

Check the answer

An acceptance contract lists machine-checkable requirements, written before paying. json-acceptance-v1 covers fields, types, ranges, allowed values and links in a JSON answer; search-results-v1 covers search results, where you say where the results, links and titles are.

{"type": "402signal.acceptance_contract", "version": 1, "profile": "search-results-v1",
 "mapping": {"results": "/results", "url": "/url", "title": "/title"},
 "requirements": {"min_results": 5, "min_distinct_urls": 5, "require_titles": true}}

The check runs in your app on the bytes you received and returns PASS, REJECT, INDETERMINATE or UNSUPPORTED, with the required and observed value for every rule. A cut-off or oversized answer is never PASS. It checks shape, not truth: it does not show that a link works, that facts are right or who the seller is. No result authorizes another payment, a retry or a refund, and the answer is not sent to 402Signal. The requirement format

No payment method yet

A runtime that cannot pay the offer gets a typed payment_capability_required result. 402Signal does not create wallets or accounts; connect the payment method your agent already uses.

Available in @402signal/route-guard@0.8.0 and 402signal==0.2.0. Supported integrations · Before production