On this page
This checklist turns the x402 V2 core, HTTP transport and exact scheme specifications into 43 controls: 18 for resource servers, 14 for facilitators and 11 for agent clients. 32 of them map to at least one automated Settlens check. For the others, the coverage line says what helps, or that the control needs your own review.
Use the identifiers (RS-01, FA-01, AG-01) to track findings. The page is printable: navigation, footer and the table of contents are hidden in the print view.
How to read the coverage line
Under each control, a check id names the Settlens check that tests it, followed by the mode the check needs; see check modes below. Full definitions, severities and remediation are in the check reference.
Resource servers
The service that sells the resource. Most of these controls are visible from outside, so a passive scan tests them without paying.
| ID | Control and coverage |
|---|---|
| RS-01 | Answer HTTP 402 to every request that carries no valid payment, before any business logic runs. Settlens: transport.status_402 (passive) |
| RS-02 | Send the terms in the PAYMENT-REQUIRED header as Base64-encoded JSON. Do not rely on the response body.Settlens: transport.payment_required_header (passive), transport.payment_required_encoding (offline) |
| RS-03 | Emit a V2 object (x402Version 2, a resource object, a non-empty accepts array) that the official @x402/core schema accepts.Settlens: schema.payment_required (offline), schema.official_x402_sdk (offline) |
| RS-04 | Set resource.url to the exact URL the client requested, including path and query.Settlens: binding.resource_url (offline) |
| RS-05 | Make every accepts entry complete: scheme, CAIP-2 network, positive integer amount in atomic units, asset, payTo (a 20-byte address on eip155 networks) and a positive maxTimeoutSeconds.Settlens: schema.payment_requirements (offline) |
| RS-06 | For EIP-3009 tokens, publish the token's real EIP-712 name and version in extra.name and extra.version.Coverage: Not scanned. verify-payment uses them to rebuild the EIP-712 domain. |
| RS-07 | Advertise each payment option once. Settlens: schema.duplicate_requirements (offline) |
| RS-08 | Keep maxTimeoutSeconds as short as settlement allows.Settlens: freshness.timeout_window (offline) |
| RS-09 | Serve paid resources over HTTPS only. Settlens: transport.https (passive) |
| RS-10 | Serve the paid resource at its canonical URL, without redirects. Settlens: transport.redirect (passive) |
| RS-11 | Keep the 402 response small and never put protected content in it. Settlens: transport.response_body_limit (passive). Size only: a scan cannot tell whether the body holds protected content. |
| RS-12 | Return the same terms for identical requests, or bind any dynamic pricing to the request on purpose. Settlens: stability.payment_requirements (passive) |
| RS-13 | Fail closed: run the handler only after the payment is verified (or settled, under the upfront and escrow flows), never on a missing, malformed or invalid signature.Settlens: security.invalid_signature_fail_closed (active) |
| RS-14 | Answer 400 to a malformed payment and 402 to a payment that fails verification or settlement. Settlens: transport.invalid_payment_status (active) |
| RS-15 | Match the client's accepted object against your own accepts entries, and send your own requirement to /verify and /settle.Coverage: No automated check: review manually. |
| RS-16 | Reject transfer methods and payment flows you do not support (extra.assetTransferMethod, extra.paymentFlow).Coverage: No automated check: review manually. |
| RS-17 | When settlement fails, do not deliver: answer 402 with a PAYMENT-RESPONSE whose success is false. Treat settlement_pending as unresolved and reconcile on chain before retrying.Coverage: Not covered: Settlens never calls /settle. |
| RS-18 | Re-test after every deploy and on a schedule, so a regression is caught before agents pay into it. Coverage: settlens monitor and the GitHub Action re-run the passive checks. |
Facilitators
The service that verifies and settles payments. Its capability endpoint can be scanned passively; its /verify behavior is tested only during an authorized active probe. The facilitator security guide explains the risks behind these controls.
| ID | Control and coverage |
|---|---|
| FA-01 | Serve GET /supported with HTTP 200 and a JSON content type.Settlens: facilitator.reachable (facilitator), facilitator.supported_status (facilitator), facilitator.content_type (facilitator) |
| FA-02 | Return the standard SupportedResponse: kinds, extensions and signers.Settlens: facilitator.supported_schema (facilitator) |
| FA-03 | List at least one x402Version 2 kind.Settlens: facilitator.v2_capability (facilitator) |
| FA-04 | List each version, scheme and network combination once. Settlens: facilitator.duplicate_kinds (facilitator) |
| FA-05 | Publish signer addresses for every network you settle on, or for its CAIP-2 namespace wildcard such as eip155:*.Settlens: facilitator.signer_coverage (facilitator) |
| FA-06 | Support every scheme and network that the resource servers you serve advertise. Settlens: facilitator.requirement_coverage (facilitator) |
| FA-07 | Serve the facilitator API over HTTPS only. Settlens: facilitator.https (facilitator) |
| FA-08 | Keep /supported small.Settlens: facilitator.response_body_limit (facilitator) |
| FA-09 | Answer /verify with a standard VerifyResponse carrying a boolean isValid.Settlens: facilitator.verify_reachable (active), facilitator.verify_response_schema (active) |
| FA-10 | Verify the signature cryptographically before answering isValid: true. A forged or all-zero signature must be rejected.Settlens: security.facilitator_rejects_invalid_signature (active) |
| FA-11 | Keep /verify read-only: it must not commit payment state or write on chain.Coverage: No automated check: review manually. |
| FA-12 | For EIP-3009, check that the signer is authorization.from and never the zero address, the balance, the exact amount, the validity window, the token and the network, then simulate transferWithAuthorization.Coverage: verify-payment checks signer, recipient, amount and window offline; balance and simulation need the chain. |
| FA-13 | Make settlement produce exactly one transfer of amount of asset to payTo, and return a failure, never a success, when the authorization's nonce is already used.Coverage: Not covered: Settlens never calls /settle. |
| FA-14 | Return settlement_pending with the broadcast transaction hash when confirmation cannot be established.Coverage: Not covered: Settlens never calls /settle. |
Agent clients
The software that pays, often an AI agent with a wallet. These controls decide whether to sign at all. The policy checks run offline in the Settlens MCP server, so an agent can apply them to every 402 before paying. How to write the policy is covered in the agent spending policy guide.
| ID | Control and coverage |
|---|---|
| AG-01 | Read the terms from PAYMENT-REQUIRED and validate them before signing: Base64 JSON, V2 shape, the official schema and well-formed options.Settlens: transport.payment_required_encoding (offline), schema.official_x402_sdk (offline), schema.payment_required (offline), schema.payment_requirements (offline) |
| AG-02 | Check that resource.url equals the URL you requested.Settlens: binding.resource_url (offline) |
| AG-03 | Pay only over HTTPS. Settlens: transport.https (passive) |
| AG-04 | Allowlist recipients (payTo).Settlens: policy.recipient (offline) |
| AG-05 | Allowlist assets: token contract addresses or mints. Settlens: policy.asset (offline) |
| AG-06 | Cap the amount in atomic units and pair the cap with an asset allowlist: a ceiling means nothing without the asset, because tokens have different decimals. Settlens: policy.maximum_amount (offline) |
| AG-07 | Restrict networks and schemes to the ones you can verify. Settlens: policy.network (offline), policy.scheme (offline) |
| AG-08 | Pay only with an option that satisfies every constraint at once; when none does, do not pay. Settlens: policy.acceptable_option (offline) |
| AG-09 | Skip options whose paymentFlow you do not recognize, and prefer authorization when a resource also offers upfront or escrow.Coverage: No automated check: review manually. |
| AG-10 | Sign exactly the advertised amount to the advertised payTo, with a short validBefore and a random 32-byte nonce.Coverage: verify-payment checks the signed authorization offline. |
| AG-11 | Treat terms that change between identical requests as a reason to stop and review. Settlens: stability.payment_requirements (passive) |
Check modes
Each Settlens check runs in one mode. The descriptions below come from the check catalog.
| Mode | What it needs |
|---|---|
| passive | Needs a live, unauthenticated request to the paid resource (settlens scan, settlens monitor, MCP scan_endpoint). Never sends a payment. |
| offline | Evaluated from the PaymentRequired content alone: runs offline in the MCP tool evaluate_payment_requirements and in every passive scan (policy.acceptable_option only in the agent tools). |
| active | Runs only with --active --authorized --authorization-ref: one intentionally invalid PAYMENT-SIGNATURE is sent. /settle is never called and no wallet or key is used. |
| facilitator | Reads a facilitator's GET /supported capabilities (settlens facilitator, scan --facilitator, MCP scan_facilitator). |
Active checks need written authorization
Checks in the active mode run only with --active --authorized --authorization-ref and the endpoint owner's approval. They send one intentionally invalid PAYMENT-SIGNATURE, never call /settle, never move funds and need no wallet or private key.
What this checklist does not cover
It covers the x402 exchange itself. It does not replace an application security review, smart contract audits of the tokens you accept, key management for the wallets that sign or settle, or legal and regulatory advice. A Settlens report is evidence of observed behavior, not a certification.
To understand the protocol behind each control, read What is x402?, the V2 headers reference and the EIP-3009 guide, with terms defined in the glossary. To see these controls fail in practice, read x402 security failure modes. For signature-level details of the EVM flow, see the exact EVM scheme specification.