---
title: "x402 glossary: agentic payment terms defined | Settlens"
description: "Plain definitions of x402, EIP-3009, EIP-712 and agentic payment terms, from PAYMENT-REQUIRED and CAIP-2 to facilitators, nonces, payment flows and replay."
url: https://settlens.com/learn/glossary
last_updated: 2026-10-13
published: 2026-10-13
---

# x402 and agentic payments glossary

> **In short:** A glossary of x402 and agentic payment terms, from PAYMENT-REQUIRED, CAIP-2 and atomic units to facilitators, EIP-3009 nonces, payment flows and settlement_pending. Definitions follow the x402 V1 and V2 specifications and the EIPs, and say when a term is specific to Settlens.

66 terms you meet when building, paying or testing x402 payments, each with a stable link you can share.

Definitions follow the x402 V1 and V2 specifications, EIP-3009 and EIP-712. Terms specific to [Settlens](https://settlens.com/about) say so. For the protocol in context, start with [What is x402?](https://settlens.com/learn/what-is-x402); for field-level detail, see the [V2 headers reference](https://settlens.com/learn/x402-v2-headers).

## A

- **accepts:** The array of payment options in a `PaymentRequired` object. Each entry is a `PaymentRequirements` object; the client chooses one and echoes it as `accepted`. See [x402 V2 headers](https://settlens.com/learn/x402-v2-headers).
- **Active probe:** A Settlens test that runs only with the endpoint owner's authorization (`--active --authorized --authorization-ref`). It sends one intentionally invalid `PAYMENT-SIGNATURE` and expects the resource and the facilitator's `/verify` to reject it. It never calls `/settle` and moves no funds. See [Check reference](https://settlens.com/docs/checks).
- **Agentic payment:** A payment made by software acting for a person or an organization, typically an AI agent paying per request for an API, a dataset or a tool, without a human filling in a checkout form.
- **asset:** The field of a payment requirement that names what is paid: a token contract address, or an ISO 4217 currency code for fiat rails. For EIP-3009 payments it is also the EIP-712 `verifyingContract`.
- **Asset transfer method:** `extra.assetTransferMethod`, a reserved protocol key that says how value is authorized or moved for a scheme on a network, for example `eip3009` or `permit2` on the EVM `exact` scheme, where the default is `eip3009`.
- **Atomic units:** The smallest indivisible unit of a token. x402 amounts are integer strings in atomic units: for a token with 6 decimals, `"10000"` means 0.01. An amount ceiling is meaningless without knowing the asset.
- **Authorization flow:** The default x402 payment flow: verify, run the resource, then settle. Funds move only after the handler succeeds. Clients should prefer it when a resource also offers another flow. See [What is x402?](https://settlens.com/learn/what-is-x402).
- **authorizationState:** The EIP-3009 view function that returns whether a given nonce has already been used by a given authorizer. Checking it requires reading the chain.

## B

- **Base64:** The text encoding used for the JSON values of the three x402 V2 headers. A client Base64-decodes the header value, then parses the result as JSON.
- **Bazaar:** The x402 discovery concept: a catalog where x402-enabled resources can be found, exposed through the discovery API (`GET /discovery/resources`).

## C

- **CAIP-2:** Chain Agnostic Improvement Proposal 2, the `namespace:reference` format x402 V2 uses for networks. The namespace is 3 to 8 characters, the reference 1 to 32: `eip155:8453` is Base mainnet, `eip155:84532` is Base Sepolia.
- **Client:** In x402, any application or agent that requests a paid resource, reads `PAYMENT-REQUIRED` and pays with `PAYMENT-SIGNATURE`.

## D

- **Domain separator:** The EIP-712 hash of the domain struct (for EIP-3009: `name`, `version`, `chainId`, `verifyingContract`). It scopes a signature to one contract on one chain, which prevents cross-chain replay. See [EIP-3009 guide](https://settlens.com/learn/eip-3009).
- **Drift:** In Settlens, a change in payment terms (resource, options or extensions) between identical requests in one scan. Settlens monitoring also compares each scan with a stored baseline and flags checks that regress. See [Monitor](https://settlens.com/product/monitor).

## E

- **ecrecover:** Recovery of the Ethereum address that produced a secp256k1 signature over a digest. It returns the zero address for a malformed signature, which verifiers must reject.
- **EIP-155 chain id:** The integer that identifies an EVM chain, introduced by EIP-155 for transaction replay protection. It is the reference in `eip155:` CAIP-2 identifiers and the `chainId` of an EIP-712 domain.
- **EIP-2 low-s rule:** EIP-2 made transaction signatures with an `s` value above half the secp256k1 order invalid, because every signature otherwise has a second valid form. The `ecrecover` precompile still accepts high-s values; Settlens rejects them.
- **EIP-3009:** Transfer With Authorization, a draft ERC that lets a token holder authorize a transfer by signing an EIP-712 message that anyone can submit. It is the default transfer method of the x402 `exact` scheme on EVM chains. See [EIP-3009 guide](https://settlens.com/learn/eip-3009).
- **EIP-712:** The Ethereum standard for hashing and signing typed structured data. The signed digest is `keccak256(0x1901 ‖ domainSeparator ‖ hashStruct(message))`.
- **Escrow flow:** An x402 payment flow in which a first settle commits a deposit or ceiling before the resource runs and a second settle records the final charge.
- **Evidence attestation:** In Settlens, an ed25519 signature that binds a report's SHA-256 digest to a signing identity and a timestamp, so a third party can verify the report offline. See [Evidence](https://settlens.com/product/evidence).
- **exact scheme:** The x402 scheme that transfers a specific amount, known in advance, from the client to the recipient. On EVM chains it uses EIP-3009 by default, Permit2 or ERC-7710 otherwise.
- **Extensions:** Optional protocol features advertised in the `extensions` object of `PaymentRequired`, each with `info` and a JSON `schema`. Clients echo them in the payload and may add information but not remove it.
- **extra:** Additional data in a payment requirement. `assetTransferMethod` and `paymentFlow` are reserved protocol keys; for EIP-3009 tokens, `name` and `version` carry the token's EIP-712 domain.

## F

- **Facilitator:** The service that verifies payment authorizations (`POST /verify`) and settles them (`POST /settle`), and publishes its capabilities (`GET /supported`). A resource server can use a third-party facilitator or host these endpoints itself. See [x402 facilitator security](https://settlens.com/learn/x402-facilitator-security) and [Settlens for facilitators](https://settlens.com/use-cases/facilitators).
- **Fail closed:** Refusing access when a payment is missing, malformed, invalid or cannot be verified. A resource that serves content for an invalid signature fails open.
- **Fee payer:** On Solana, the account that pays the transaction fee and provides the final required signature. In the x402 `exact` scheme on Solana it is the sponsor named in `extra.feePayer`.

## H

- **HTTP 402 Payment Required:** The HTTP status code that RFC 9110 reserves for future use. x402 gives it a meaning: the resource requires payment, and the terms are in the `PAYMENT-REQUIRED` header.

## I

- **invalidReason and errorReason:** The fields of `VerifyResponse` and `SettleResponse` that carry an x402 error code, such as `insufficient_funds`, when verification or settlement fails. See [x402 error codes](https://settlens.com/learn/x402-error-codes).

## M

- **maxAmountRequired:** The x402 V1 field of a payment requirement that held the amount in atomic units. V2 renames it `amount`. See [V1 to V2 migration](https://settlens.com/learn/x402-v1-to-v2-migration).
- **maxTimeoutSeconds:** The maximum time, in seconds, allowed for payment completion in a payment requirement. Settlens warns when it exceeds 3600 seconds.
- **MCP (Model Context Protocol):** A protocol that connects AI applications to external tools and data. The Settlens MCP server lets an agent check an x402 payment request before paying. See [Settlens MCP server](https://settlens.com/mcp).

## N

- **Nonce (EIP-3009):** A random 32-byte value in an EIP-3009 authorization. The token contract accepts each nonce once per payer, which prevents replay; random rather than sequential nonces let many authorizations be pending at once.

## P

- **Payment bypass:** A paid resource that can be obtained without a valid payment, for example because the server accepts an invalid signature. Settlens tests for it with `security.invalid_signature_fail_closed`.
- **Payment flow:** `extra.paymentFlow`: when settlement happens relative to the resource handler. V2 defines `authorization` (the default), `upfront` and `escrow`, and clients must not pay with a flow they do not recognize. See [Payment flows](https://settlens.com/learn/what-is-x402#payment-flows) and [V1 to V2 migration](https://settlens.com/learn/x402-v1-to-v2-migration) and [section 6.1 of the V2 specification](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md).
- **payment-identifier:** An x402 extension in which the client attaches an `id` of 16 to 128 characters to its payment payload as an idempotency key, so resource servers and facilitators can deduplicate repeated submissions.
- **PAYMENT-REQUIRED:** The x402 V2 response header, sent with HTTP 402, that carries a Base64-encoded `PaymentRequired` object. See [x402 V2 headers](https://settlens.com/learn/x402-v2-headers).
- **PAYMENT-RESPONSE:** The x402 V2 response header that carries a Base64-encoded settlement response: HTTP 200 on success, HTTP 402 when settlement failed.
- **PAYMENT-SIGNATURE:** The x402 V2 request header in which the client sends a Base64-encoded `PaymentPayload`. It replaces the V1 `X-PAYMENT` header.
- **PaymentPayload:** The object a client sends in `PAYMENT-SIGNATURE`: `x402Version`, the optional `resource`, the chosen requirement in `accepted`, the scheme-specific `payload` and optional `extensions`.
- **PaymentRequired:** The object in `PAYMENT-REQUIRED`: `x402Version` (2), an optional `error`, the `resource` description, the `accepts` array and optional `extensions`.
- **PaymentRequirements:** One payment option: `scheme`, `network`, `amount`, `asset`, `payTo`, `maxTimeoutSeconds` and optional `extra`.
- **payTo:** The recipient of a payment requirement: an address, or a role constant such as "merchant". On `eip155` networks Settlens requires a 20-byte address.
- **Permit2:** The fallback transfer method of the EVM `exact` scheme for tokens without EIP-3009. The payer approves the Permit2 contract once, then signs transfers whose recipient is enforced by the x402 Permit2 proxy.

## R

- **Replay:** Reusing a payment authorization, on the same chain or another one. EIP-3009 nonces stop reuse on chain, `validBefore` limits the lifetime and the EIP-712 domain ties a signature to one chain and one token.
- **Report digest:** In Settlens, the deterministic SHA-256 integrity block of a JSON report. `verify-report` recomputes it to show the report has not changed. See [Reports](https://settlens.com/docs/reports).
- **resource (ResourceInfo):** The object in `PaymentRequired` that describes the protected resource. Its `url` is required and should equal the URL the client requested; `description`, `mimeType`, `serviceName`, `tags` and `iconUrl` are optional.
- **Resource server:** The service that requires payment for a resource. It answers 402 with the terms, verifies and settles payments through a facilitator and returns the resource.

## S

- **SARIF:** Static Analysis Results Interchange Format, a JSON format for analysis findings. Settlens writes SARIF so code-scanning tools can display x402 findings.
- **Scheme:** The payment logic of a payment requirement, independent of transport. The x402 specifications define `exact`, `upto`, `batch-settlement` and `auth-capture`, each with per-network bindings.
- **Settle (/settle):** The facilitator endpoint that durably commits a payment, typically by broadcasting a transaction, and returns a settlement response. Settlens never calls it.
- **settlement_pending:** A non-terminal x402 error: the settlement transaction was broadcast but its confirmation could not be established. The response must include the transaction hash so the caller can reconcile on chain before retrying. See [x402 error codes](https://settlens.com/learn/x402-error-codes#settlement-pending).
- **SettleResponse:** The result of settlement: `success`, `transaction`, `network`, and optionally `errorReason`, `payer`, `amount` and `extensions`. The resource server returns it in `PAYMENT-RESPONSE`.
- **signers:** The map in a facilitator's `/supported` response from CAIP-2 patterns, such as `eip155:*`, to the facilitator's public signer addresses. See [x402 facilitator security](https://settlens.com/learn/x402-facilitator-security).
- **Spending policy:** The limits an agent applies before paying. In the Settlens MCP tools: allowed recipients (`pay_to`), assets (`assets`), networks, schemes and a maximum amount in atomic units (`max_amount`). Cumulative budgets are not part of it. See [Agent spending policy](https://settlens.com/learn/agent-spending-policy).
- **Supported (/supported):** The facilitator endpoint that lists its capabilities: `kinds` (x402 version, scheme and network), `extensions` and `signers` per network.

## T

- **transferWithAuthorization:** The EIP-3009 function that moves tokens from `from` to `to` given a signed authorization and its `v`, `r`, `s` signature. The x402 facilitator calls it at settlement.

## U

- **Upfront flow:** An x402 payment flow that settles before the resource runs. If the handler then fails, the client has paid; the core specification defines no refund for this case.
- **upto scheme:** An x402 scheme in which the requirement's `amount` is the maximum authorized at verification time, and the amount actually settled is set at settlement time.

## V

- **validAfter and validBefore:** The Unix times that bound an EIP-3009 authorization. The token contract accepts it only after `validAfter` and before `validBefore`.
- **Verify (/verify):** The facilitator endpoint that checks a payment authorization against the requirements without executing it. It is read-only and must not commit payment state.
- **VerifyResponse:** The answer of `/verify`: a boolean `isValid` and, optionally, `invalidReason`, `payer`, `extensions` and scheme-specific `extra`.

## X

- **X-PAYMENT:** The x402 V1 request header that carried the client's Base64-encoded payment payload. V2 replaces it with `PAYMENT-SIGNATURE`. See [V1 to V2 migration](https://settlens.com/learn/x402-v1-to-v2-migration).
- **X-PAYMENT-RESPONSE:** The x402 V1 response header that carried the Base64-encoded settlement response. V2 replaces it with `PAYMENT-RESPONSE`.
- **x402:** An open payment standard that lets any client pay for a resource as part of a request-response exchange. Over HTTP it uses status 402 and three headers; a facilitator typically verifies the payment and settles it on a blockchain. See [What is x402?](https://settlens.com/learn/what-is-x402).
- **x402Version:** The protocol version field present in x402 objects. V2 objects carry `2`; V1 objects carry `1` and use a different layout.

Missing a term? Tell us at [contact@settlens.com](mailto:contact@settlens.com), or read how the terms fit together in the [x402 security checklist](https://settlens.com/learn/x402-security-checklist).

## Sources

1. [x402 protocol specification, version 2](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v2.md) — x402 Foundation
2. [x402 protocol specification, version 1](https://github.com/x402-foundation/x402/blob/main/specs/x402-specification-v1.md) — x402 Foundation
3. [ERC-3009: Transfer With Authorization](https://eips.ethereum.org/EIPS/eip-3009) — Ethereum Improvement Proposals
4. [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) — Ethereum Improvement Proposals
5. [CAIP-2: Blockchain ID Specification](https://github.com/ChainAgnostic/CAIPs/blob/main/CAIPs/caip-2.md) — Chain Agnostic Standards Alliance