---
title: "x402 payment security use cases | Settlens"
description: "How API sellers, facilitator operators, AI agent builders and security teams use Settlens to check, gate, monitor and prove x402 payment behavior."
url: https://settlens.com/use-cases
last_updated: 2026-10-13
---

# Settlens use cases for x402 payments

> **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.

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.

[Find your role](https://settlens.com/use-cases#roles) [Request a pilot](https://settlens.com/contact)

## 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.

- **[API sellers](https://settlens.com/use-cases/api-sellers)**

  Check that your x402 paid API returns a valid 402 challenge, binds each payment to the right URL, recipient and price, fails closed and stays that way.

- **[Facilitators](https://settlens.com/use-cases/facilitators)**

  Check that your x402 facilitator advertises valid V2 capabilities and signers, covers the terms resources advertise, and rejects forged signatures at /verify.

- **[Agent builders](https://settlens.com/use-cases/agent-builders)**

  Give your AI agent a spending policy and an MCP preflight: Settlens checks each x402 payment request and answers pay, review or do_not_pay with reasons.

- **[Security teams](https://settlens.com/use-cases/security-teams)**

  Evidence for auditors, AppSec and risk teams: reproducible x402 checks, SARIF findings, SHA-256 report digests and ed25519 attestations you verify offline.

## 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.

_Diagram: Map of an x402 payment. The AI agent receives an HTTP 402 challenge from the paid API and retries with a signature; the paid API calls the facilitator's /verify and /settle endpoints. Settlens stages sit under each party: MCP preflight for the agent, scan, CI and monitor for the paid API, facilitator scan for the facilitator. Reports and signed evidence from the scans go to security teams._

_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_

| Stage | API sellers | Facilitators | Agent builders | Security teams |
| --- | --- | --- | --- | --- |
| Passive scan of a paid resource | Primary | Optional | Optional | Primary |
| Authorized active probe | Primary | Primary | Not available over MCP | Primary |
| Facilitator /supported scan | Optional | Primary | Not used | Optional |
| Offline signature verification | Optional | Optional | Optional | Optional |
| MCP preflight before paying | Optional | Not used | Primary | Not used |
| CI gate with SARIF | Primary | Primary | Optional | Primary |
| Monitor against a baseline | Primary | Optional | Optional | Optional |
| Signed evidence | Optional | Optional | Not used | Primary |

Every check is documented in the [check reference](https://settlens.com/docs/checks), with what it verifies, why it matters and how to fix it. The [methodology](https://settlens.com/docs/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](https://settlens.com/product/assess)

- **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](https://settlens.com/docs/security)

- **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](https://settlens.com/product/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](https://settlens.com/learn/what-is-x402)

> **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](https://settlens.com/pricing) for pilot options.

## 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.

[Request a pilot](https://settlens.com/contact) [Connect the MCP server](https://settlens.com/mcp)

## Sources

1. [x402 protocol specification, version 2 (§2 core payment flow, §7 facilitator interface)](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md) — x402 Foundation