x402 glossary: agentic payment terms defined

Definitions follow the x402 V1 and V2 specifications, EIP-3009 and EIP-712. Terms specific to Settlens say so. For the protocol in context, start with What is x402?; for field-level detail, see the V2 headers reference.

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

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.
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.
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 and Settlens for 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.

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

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 and V1 to V2 migration and section 6.1 of the V2 specification.
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.
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.
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.
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.
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.
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.
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?.
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, or read how the terms fit together in the x402 security checklist.

Sources

x402 protocol specification, version 2x402 Foundation · github.com
x402 protocol specification, version 1x402 Foundation · github.com
ERC-3009: Transfer With AuthorizationEthereum Improvement Proposals · eips.ethereum.org
EIP-712: Typed structured data hashing and signingEthereum Improvement Proposals · eips.ethereum.org
CAIP-2: Blockchain ID SpecificationChain Agnostic Standards Alliance · github.com