Settlens use cases for x402 payments

An x402 payment involves a paying agent, a paid API and a facilitator. Each one fails in its own way and each needs different evidence. Pick your role to see which checks apply, how to run them and what you get.

In short

Settlens serves four roles around an x402 payment: API sellers scan, gate and monitor their paid endpoints; facilitator operators test /supported and /verify; agent builders check each 402 against a spending policy before paying; security teams get reports and signed evidence they verify offline.

Choose your role

Each page lists the failure modes Settlens checks for that role, the commands or configuration to run, an example you can adapt and the limits you should know about.

Where each team sits in the payment

Settlens never joins the payment itself. It observes the challenge, checks the facilitator's capabilities and, with explicit authorization, sends one invalid signature that must be refused.

Settlens checks each party from outside. It never calls /settle and never holds a wallet or payment key.

Which stage each team relies on

Every stage draws on one check catalog, so a check id names the same property in CI, in a pilot report and in a preflight answer. One rule differs: a scan requires every advertised option to fit your policy, while the agent preflight needs one acceptable option.

Settlens stages by role
StageAPI sellersFacilitatorsAgent buildersSecurity teams
Passive scan of a paid resourcePrimaryOptionalOptionalPrimary
Authorized active probePrimaryPrimaryNot available over MCPPrimary
Facilitator /supported scanOptionalPrimaryNot usedOptional
Offline signature verificationOptionalOptionalOptionalOptional
MCP preflight before payingOptionalNot usedPrimaryNot used
CI gate with SARIFPrimaryPrimaryOptionalPrimary
Monitor against a baselinePrimaryOptionalOptionalOptional
Signed evidenceOptionalOptionalNot usedPrimary

Every check is documented in the check reference, with what it verifies, why it matters and how to fix it. The methodology explains what a pass, fail, warning or skip proves.

What holds for every team

  • Passive by default

    A scan sends ordinary requests without any payment header, follows no redirect and refuses a user-supplied PAYMENT-SIGNATURE.

    How a scan works
  • No wallet, no custody, no settlement

    Settlens never needs a wallet or a payment key, never calls /settle and never moves funds. The only key it uses is the optional ed25519 key that signs evidence. It is not a blockchain and has no token.

    Read the security model
  • Evidence you can re-check

    JSON reports carry a deterministic SHA-256 digest, and an ed25519 attestation binds that digest to a signing key and a timestamp.

    See signed evidence
  • Official x402 parsing

    PaymentRequired objects are validated with the pinned official @x402/core 2.28.0 SDK, plus the x402 V2 core shape and per-requirement rules.

    Learn how x402 works

How to get Settlens

The code lives in a private repository. Pilot participants receive the CLI (Node.js 20.19 or newer), the GitHub composite Action and the local MCP server. The remote MCP endpoint at https://settlens.com/mcp exposes the offline tools publicly; its network tools need a Settlens API token. See pricing for pilot options.

Sources

  1. x402 protocol specification, version 2 (§2 core payment flow, §7 facilitator interface)x402 Foundation · github.com

Start with one endpoint, facilitator or agent flow

A pilot usually starts with one paid endpoint, facilitator or agent flow and ends with a report and a signed attestation you can verify yourself.