Screen a payee before an x402 payment
Check the quoted payee and spending rules before your agent creates a payment signature.
Start with the actual payment challenge
When a merchant responds with HTTP 402, preserve its x402 v1 or v2 challenge and the URL that returned it. Check the selected network, asset, atomic amount and payTo. Bind the quote to the intended resource in your payment client; a descriptive service name is not proof of ownership.
Screen, then decide
GET /v1/check screens an address, name or domain for $0.01. POST /v1/preflight evaluates a challenge or cart against caller rules for $0.02 and returns allow, hold or block with reasons and a signed receipt. Both paid services accept USDC on Base without a SpendPreflight account or API key.
- Receive the merchant challenge without paying it.
- Submit that challenge and your policy to preflight.
- Hold on unavailable screening, malformed results or an unaccepted decision.
- Only let your payment wrapper sign after your enforcement policy allows it.
The screening service never signs or settles the merchant payment. Its own screening fee is separate from the merchant price. An allow decision is informational evidence, not a guarantee of identity, delivery or legality.
Try without automatic spending
The shared HTTP/MCP trial allows three calls per IP per UTC day. Trial exhaustion must not silently switch your client to paid mode. See the tested examples for explicit trial and payment behavior.
Connect your payment client
Tested fetch, axios, Vercel and OpenAI Agents examples · Live default rules · OpenAPI
We operate SpendPreflight. Scout discovery and seller monitoring remain staging-only; these guides describe the live check/preflight service.
Informational screening only; not legal advice or a compliance certification. Trust and limitations · Privacy