{"glossary_note":"One entry per term. Each entry answers its own address as JSON.","glossary_rules":{"Sources":"Each entry is pinned to primary sources — a specification, an RFC, an EIP, or a party's own published documents — listed on the entry.","Numbers":"Entry text carries links rather than figures. Where a quantity matters, the entry links the source that holds it, so nothing here can go stale in silence.","Named parties":"A party is described as what it is and does, per its own documents. No ranking, no endorsement, and no comparison between parties."},"glossary":[{"slug":"facilitator","title":"facilitator","kind":"term","short":"A facilitator is a service that verifies and settles x402 payments on behalf of a seller. The seller's endpoint quotes a price, the buyer's client signs a payment authorization, and the facilitator checks that authorization against the quote and submits it to the blockchain.","path":"/glossary/facilitator"},{"slug":"payto","title":"payTo","kind":"term","short":"payTo is the field in an x402 payment quote that names the address a payment is sent to. It is part of the challenge the endpoint returns, so whoever controls that endpoint chooses it at the moment of the quote. It can differ between one request and the next.","path":"/glossary/payto"},{"slug":"catalogue","title":"catalogue","kind":"term","short":"A catalogue is a published list of x402 endpoints that a buyer or an agent can read to discover what is payable. Facilitators operate them, each listing the endpoints that settle through it. A listing is therefore a curation decision, not a property of the endpoint itself.","path":"/glossary/catalogue"},{"slug":"verify-and-settle","title":"verify and settle","kind":"term","short":"Verify and settle are the two operations an x402 facilitator exposes. Verify checks a signed payment payload against the quote the endpoint issued; settle submits that payload to the blockchain. They are separate calls, and a payload that passes verification has still moved no money.","path":"/glossary/verify-and-settle"},{"slug":"accepts-array","title":"accepts array","kind":"term","short":"The accepts array is the list of payment options in an x402 payment challenge: what an endpoint returns with HTTP 402 when a request arrives unpaid. Each element of that array is one payment option the endpoint will take, stated in machine-readable terms.","path":"/glossary/accepts-array"},{"slug":"http-402","title":"HTTP 402","kind":"rail","short":"HTTP 402 is the response status code named Payment Required. RFC 9110 reserves it and defines no payment format, which leaves the meaning of such a response to whatever protocol is layered above it. x402 is one such protocol, and the status code is not the same thing as the protocol.","path":"/glossary/http-402"},{"slug":"settlement","title":"settlement","kind":"term","short":"Settlement is the step where an authorised x402 payment is submitted to the blockchain and the transfer actually happens. A quote, a signature and a successful verification all precede it, and none of them is a settlement.","path":"/glossary/settlement"},{"slug":"x402","title":"x402","kind":"rail","short":"x402 is an open standard for paying for an HTTP request itself. The server answers an unpaid request with HTTP 402 and machine-readable terms; the client pays for one of them and retries; the resource is served. It is built for software rather than for people — no account, no subscription, no form anywhere in the exchange.","path":"/glossary/x402"},{"slug":"eip-3009","title":"EIP-3009","kind":"term","short":"EIP-3009 is an Ethereum token standard extension that lets a token holder sign a transfer authorization off-chain, which anyone can then submit on-chain. It is the mechanism under x402's exact scheme: the payer signs, and the facilitator pays the network fee to submit it.","path":"/glossary/eip-3009"},{"slug":"mpp","title":"MPP","kind":"rail","short":"MPP — the Machine Payments Protocol — is an open protocol for paying for an HTTP request with no checkout and nobody present. The server answers an unpaid request with HTTP 402 and a challenge; the agent retries with a payment credential; the resource comes back with a receipt. It reuses HTTP's own authentication headers rather than defining its own.","path":"/glossary/mpp"},{"slug":"coinbase-cdp","title":"Coinbase Developer Platform (CDP)","kind":"player","short":"Coinbase Developer Platform (CDP) is Coinbase's developer product suite. In the x402 ecosystem it operates a facilitator: the service that verifies and settles payments for sellers that configure it. It also publishes the discovery catalogue attached to that facilitator, the x402 Bazaar.","path":"/glossary/coinbase-cdp"},{"slug":"x402-foundation","title":"x402 Foundation","kind":"player","short":"The x402 Foundation is the organization that stewards the x402 specification. The protocol's public repository is published under its GitHub organization, which is the source of record for the schemes, the challenge format and the facilitator operations.","path":"/glossary/x402-foundation"},{"slug":"x402-org-facilitator","title":"x402.org facilitator","kind":"player","short":"The x402.org facilitator is the public facilitator served from the protocol's own project site. It verifies and settles payments for sellers that configure it, and it maintains a discovery catalogue of its own, separate from any other facilitator's.","path":"/glossary/x402-org-facilitator"},{"slug":"payment-challenge","title":"payment challenge","kind":"concept","short":"A payment challenge is what a paid endpoint returns when a request arrives without payment: a machine-readable statement of what it would cost and how to pay it. Each of the HTTP payment protocols defines one, and they do not agree on where it travels or what it carries.","path":"/glossary/payment-challenge"},{"slug":"machine-payment","title":"machine payment","kind":"concept","short":"A machine payment is a payment made by software for a resource it is using, with no checkout page and nobody entering card details. The seller's endpoint returns a payment challenge, the buyer's software presents a payment credential, and the request is served. That is what separates it from an agent buying goods through a merchant's checkout.","path":"/glossary/machine-payment"},{"slug":"agentic-commerce","title":"agentic commerce","kind":"concept","short":"Agentic commerce is an agent completing a purchase for somebody through a merchant's own checkout. The merchant keeps the order, the payment and the customer relationship; the agent presents the buyer, the cart and a payment credential. The commerce stack stays the merchant's, and the agent is a party to it.","path":"/glossary/agentic-commerce"},{"slug":"payment-required-header","title":"PAYMENT-REQUIRED header","kind":"term","short":"The PAYMENT-REQUIRED header is where a current x402 endpoint states its price. The protocol's current HTTP transport carries every protocol field in headers rather than in the response body. A client reads the terms from the header value, and the body is left to the server.","path":"/glossary/payment-required-header"},{"slug":"transport","title":"transport","kind":"term","short":"A transport is the carrier a protocol's messages travel on. x402 defines its payment fields once and then specifies separately how they are carried, so the same protocol can look materially different depending on the channel a client meets it through.","path":"/glossary/transport"},{"slug":"agent","title":"agent","kind":"term","short":"An agent is software that acts for somebody and can pay for what it uses. The word is the sector's, not the specification's. x402 calls the paying party the client, and defines it by what it does in the exchange rather than by what kind of software it is.","path":"/glossary/agent"},{"slug":"payment-receipt","title":"payment receipt","kind":"concept","short":"A payment receipt is a statement issued after a machine payment saying that it happened. The HTTP payment specifications that define one make it something the seller returns on success and never on an error. That makes a receipt the paid party's own account of the transaction.","path":"/glossary/payment-receipt"},{"slug":"scheme","title":"scheme","kind":"term","short":"A scheme is x402's word for how a payment is formed, checked and settled. The specification defines several, and a client and a facilitator have to support the same scheme on the same network before a payment between them is possible at all.","path":"/glossary/scheme"},{"slug":"status-class","title":"status class","kind":"concept","short":"A status class is the group an HTTP status code belongs to, identified by the digit it starts with. It tells a client what kind of answer arrived: a success, a client-side problem, a server-side problem. About a paid endpoint, that is a great deal less than it sounds.","path":"/glossary/status-class"},{"slug":"rate-limiting-vs-payment-gating","title":"rate limiting vs payment gating","kind":"concept","short":"Rate limiting and payment gating are two different answers to the same request. A rate limit says a client has asked too often and may ask again later; a payment gate says the resource has a price and names it. They arrive as different status codes, and reading them as one refusal loses the difference between a wall and a price.","path":"/glossary/rate-limiting-vs-payment-gating"},{"slug":"pay-per-call","title":"pay-per-call API","kind":"concept","short":"A pay-per-call API is one that charges for each request rather than through an account or a subscription. The price arrives with the response to an unpaid call, so a client can decide and pay inside the same exchange — which is what makes the pattern usable by software with nobody watching.","path":"/glossary/pay-per-call"},{"slug":"buyer","title":"buyer","kind":"term","short":"A buyer is the party whose money is spent. x402 names the software that pays — the client — and says nothing about who stands behind it. That is why the other agentic-payments specifications treat the buyer and the agent as separate roles.","path":"/glossary/buyer"},{"slug":"seller","title":"seller","kind":"term","short":"A seller is the party that charges for a resource. x402 calls it the resource server: the HTTP server providing an API or other resource to a client. It sets the price, names the receiving address, and picks the facilitator that settles its payments.","path":"/glossary/seller"},{"slug":"agent-wallet","title":"agent wallet","kind":"concept","short":"An agent wallet is where the money an agent spends is held and where the limits on that spending are set. The wallet holds the credential and the agent presents something derived from it. What differs between rails is who approves a spend, and what the agent is given to present.","path":"/glossary/agent-wallet"},{"slug":"micropayment","title":"micropayment","kind":"concept","short":"A micropayment is a payment small enough that the cost of collecting it matters. On the machine-payment rails that is not a figure of speech: each rail publishes a minimum amount it will accept. The minimums differ, so the rail an endpoint settles on decides what it can charge for.","path":"/glossary/micropayment"},{"slug":"stablecoin","title":"stablecoin","kind":"concept","short":"A stablecoin is a cryptocurrency whose value is pegged to another asset, usually a national currency, so that it does not move the way an ordinary token does. It is what the HTTP payment rails settle in, which is why a payment protocol that never mentions currencies still depends on one.","path":"/glossary/stablecoin"},{"slug":"usdc","title":"USDC","kind":"concept","short":"USDC is a stablecoin issued by regulated affiliates of Circle and redeemable one-for-one for US dollars. It is the asset the machine-payment rails name for stablecoin settlement, and a payment quote identifies it by contract address on a stated network rather than by its name.","path":"/glossary/usdc"},{"slug":"mcp","title":"MCP","kind":"rail","short":"MCP — the Model Context Protocol — is an open standard for connecting AI applications to external systems: data sources, tools and workflows. It is not a payment protocol. It belongs in a payments glossary because x402 defines a transport for it: a payment can travel over MCP with no HTTP status code involved.","path":"/glossary/mcp"},{"slug":"ap2","title":"AP2","kind":"rail","short":"AP2 — the Agent Payments Protocol — is an open protocol for authorising an agent's purchase and recording what the person actually asked for. Its unit is the mandate: a cryptographically signed object holding the instruction. It governs authorisation and evidence rather than the movement of money.","path":"/glossary/ap2"},{"slug":"acp","title":"ACP","kind":"rail","short":"ACP — the Agentic Commerce Protocol — is an open standard for commerce flows between buyers, AI agents and businesses, published under an open-source licence. It runs a merchant's own checkout from inside an agent's conversation, and it does not use HTTP 402.","path":"/glossary/acp"},{"slug":"ucp","title":"UCP","kind":"rail","short":"UCP — the Universal Commerce Protocol — describes itself as a common language for platforms, agents and businesses: building blocks for agentic commerce from discovery through checkout. It is assembled from transports and agent standards that already exist rather than defining its own.","path":"/glossary/ucp"},{"slug":"l402","title":"L402","kind":"rail","short":"L402 is an HTTP payment scheme that pairs a bearer token with a Lightning invoice. A server answers an unpaid request with HTTP 402 and a WWW-Authenticate header carrying both; the client pays the invoice and presents the token together with the payment preimage as proof.","path":"/glossary/l402"},{"slug":"pay-per-crawl","title":"pay per crawl","kind":"rail","short":"Pay per crawl lets a site owner charge AI crawlers for access instead of blocking them. A crawler that has not paid receives HTTP 402 with a price; a crawler willing to pay repeats the request carrying a price of its own, inside the components its request signature covers.","path":"/glossary/pay-per-crawl"},{"slug":"eip-712","title":"EIP-712","kind":"term","short":"EIP-712 is the Ethereum standard for hashing and signing typed structured data rather than an opaque string. It is what makes a payment authorization readable before it is signed, and it is the form an x402 payment signature takes.","path":"/glossary/eip-712"},{"slug":"tamper-evidence","title":"tamper evidence","kind":"concept","short":"Tamper evidence is a property of a record: not that it cannot be altered, but that an alteration can be detected afterwards by somebody who was not there when it was written. For an archive of observations it is the difference between a claim about the past and evidence about it.","path":"/glossary/tamper-evidence"},{"slug":"payment-authorization","title":"payment authorization","kind":"concept","short":"A payment authorization is the signed instruction a payer produces that permits a payment, before any money has moved. It names an amount, a recipient and a window in which it may be used, and it travels back with the retried request. Every machine-payment rail separates the signing from the settling, which is what lets a payment happen inside one HTTP exchange.","path":"/glossary/payment-authorization"},{"slug":"replay-protection","title":"replay protection","kind":"concept","short":"Replay protection is what stops a signed payment authorization being presented more than once. An authorization is a bearer instrument until it is used, so each rail binds one to a single use and to a window of time. The mechanisms differ; the property they reach for is the same.","path":"/glossary/replay-protection"},{"slug":"extension","title":"extension","kind":"term","short":"An extension is an optional piece of x402 functionality outside the core payment mechanics. A server advertises the extensions it supports in the payment challenge, and a client echoes them back when it pays. The core stays small, and what a particular deployment needs beyond it arrives as a named extension rather than as a new version of the protocol.","path":"/glossary/extension"},{"slug":"caip-2","title":"CAIP-2","kind":"concept","short":"CAIP-2 is a way of naming a blockchain in one string: a namespace, a colon, and a reference. It exists so that a single identifier means the same chain everywhere, instead of each system keeping its own list of names. It is the form an x402 payment quote states its network in.","path":"/glossary/caip-2"},{"slug":"upto-scheme","title":"upto scheme","kind":"term","short":"The upto scheme is the x402 scheme for a payment whose final amount is not known when the client signs. The client authorizes a maximum, the server runs the request, and the amount settled afterwards is decided by what was actually consumed. It is the shape metered pricing needs, where a fixed price cannot be quoted in advance.","path":"/glossary/upto-scheme"},{"slug":"payment-intent","title":"payment intent","kind":"concept","short":"A payment intent is the kind of obligation a payment challenge is asking for: a one-off charge, metered usage, or a recurring subscription. MPP names the three and puts the choice in the challenge itself, so a client learns which commitment it is being asked to make before it pays.","path":"/glossary/payment-intent"},{"slug":"on-chain-vs-off-chain","title":"on-chain vs off-chain","kind":"concept","short":"On-chain and off-chain describe where a step of a payment happens. Signing an authorization is off-chain: it touches no network, costs nothing, and produces a message. Submitting that authorization is on-chain: it costs a fee, waits for confirmation, and is what anybody can look up afterwards.","path":"/glossary/on-chain-vs-off-chain"},{"slug":"gas","title":"gas","kind":"term","short":"Gas is the fee a blockchain charges for doing work, paid in that network's own token. An agent paying over x402 usually holds none of it: the client signs off-chain and the facilitator that submits the authorization is the account that pays. Where a token cannot be approved by signature alone, the protocol has extensions that let the facilitator cover that step too.","path":"/glossary/gas"},{"slug":"erc-20","title":"ERC-20","kind":"term","short":"ERC-20 is the Ethereum standard interface for a token: how it is transferred, and how a holder lets somebody else spend on their behalf. That second half is a pair of functions, approve and transferFrom, and the awkwardness of that pair is why the agent-payment rails reach for a signature instead.","path":"/glossary/erc-20"},{"slug":"eip-2612","title":"EIP-2612","kind":"term","short":"EIP-2612 adds a permit function to an ERC-20 token, so a holder can grant a spending allowance with a signed message instead of a transaction. It removes the separate approval step, and with it the need for the holder to hold the chain's own fee token.","path":"/glossary/eip-2612"},{"slug":"custody","title":"custody","kind":"term","short":"Custody is holding somebody else's money. An x402 facilitator does not: the protocol's documentation states that it neither holds funds nor acts as a custodian, and that it verifies and executes on-chain transactions from payloads the client signed. What that property buys, and what it leaves open, are different questions.","path":"/glossary/custody"},{"slug":"discovery","title":"discovery","kind":"term","short":"Discovery is how an x402 endpoint becomes findable at all: the endpoint describes itself in its own payment challenge, and a facilitator collects those descriptions into a catalogue. The description is the mechanism; the catalogue is the list it produces.","path":"/glossary/discovery"},{"slug":"rfc-9421","title":"RFC 9421","kind":"concept","short":"RFC 9421 is the IETF standard for HTTP Message Signatures: signing chosen parts of an HTTP request so a server can check who sent it and that it arrived unaltered. The signer names which components it covered, and the receiver rebuilds the same string to check the signature. It is the mechanism the agent-identity work in this sector is built on.","path":"/glossary/rfc-9421"},{"slug":"web-bot-auth","title":"Web Bot Auth","kind":"concept","short":"Web Bot Auth is a proposal for letting an automated HTTP client sign its requests so a server can tell who is asking. It defines a header field that points at the client's own key directory, so the identity is checkable without the server having been told about that client in advance. It answers who, and deliberately nothing else.","path":"/glossary/web-bot-auth"},{"slug":"visa-trusted-agent-protocol","title":"Visa Trusted Agent Protocol","kind":"rail","short":"The Visa Trusted Agent Protocol is a specification for letting a merchant recognise that an approved agent with commerce intent is the thing visiting its site, rather than a crawler or something worse. It carries a signed agent-recognition header and a way for the merchant to ask the agent for what it needs. It answers who is asking, not what a resource costs.","path":"/glossary/visa-trusted-agent-protocol"},{"slug":"robots-txt","title":"robots.txt","kind":"concept","short":"robots.txt is the file at the root of a site that tells automated clients which parts of it they are asked not to fetch. It is the Robots Exclusion Protocol, standardised as RFC 9309, and it is a request rather than an enforcement. It is also the layer the paid-crawl work is built above.","path":"/glossary/robots-txt"},{"slug":"rsl","title":"RSL","kind":"concept","short":"RSL — Really Simple Licensing — is an open standard for stating machine-readable licensing terms for content, including attribution, pay per crawl and pay per inference compensation. It is published by the RSL Internet Collective and can be expressed in the same places a crawler already looks.","path":"/glossary/rsl"},{"slug":"kya","title":"KYA","kind":"concept","short":"KYA — Know Your Agent — is the idea that verifying a party in an agent payment means verifying two things: the person or organization behind the agent, and the agent itself. The existing checks answer the person; the agent's own identity and its delegated permissions are the part they were never built to cover.","path":"/glossary/kya"},{"slug":"a2a","title":"A2A","kind":"rail","short":"A2A — the Agent2Agent protocol — is an open standard for communication between AI agents that know nothing about each other's internals. It is not a payment protocol: it is the substrate two of the payment rails ride on, which is why the same words turn up in both places.","path":"/glossary/a2a"},{"slug":"visa-intelligent-commerce","title":"Visa Intelligent Commerce","kind":"rail","short":"Visa Intelligent Commerce is a card-network programme for letting an agent pay at ordinary merchants. It issues a pass-through payment token specific to agents, and the person authenticates each payment instruction with a passkey before the agent presents it. The rail underneath is the existing card rail, reached through an agent-scoped credential.","path":"/glossary/visa-intelligent-commerce"},{"slug":"tempo","title":"Tempo","kind":"concept","short":"Tempo is a blockchain purpose-built for stablecoin payments at scale, which its own site describes as putting payments ahead of everything else. The difference it names is that fees are paid in US dollar stablecoins rather than in a volatile gas token, which makes it a settlement layer designed around the thing being settled.","path":"/glossary/tempo"},{"slug":"uma","title":"UMA","kind":"rail","short":"UMA — a Universal Money Address — is a human-readable address for receiving money, described by its publishers as being like an email address but for money. It uses the Bitcoin Lightning Network underneath. It names a recipient rather than pricing a resource, which is what separates it from the HTTP payment rails.","path":"/glossary/uma"}],"selected":{"slug":"uma","kind":"rail","title":"UMA","question":"What is UMA?","short":"UMA — a Universal Money Address — is a human-readable address for receiving money, described by its publishers as being like an email address but for money. It uses the Bitcoin Lightning Network underneath. It names a recipient rather than pricing a resource, which is what separates it from the HTTP payment rails.","mechanism":["The problem it states is cross-border payment being expensive, slow and complicated, and its answer is an addressing layer: unique, human-readable addresses that are easy to remember and share, resolved over the Bitcoin Lightning Network for the payment itself.","It sits beside the HTTP rails rather than on them, and the distinction is worth keeping. A [payment challenge](/glossary/payment-challenge) is a server saying what a resource costs and how to pay for it; an address standard is a way of naming who receives a payment somebody has already decided to make. [L402](/glossary/l402) is the entry that pairs the same underlying network with an HTTP challenge."],"citations":[{"url":"https://www.uma.me/","publisher":"Universal Money Address","title":"UMA: Universal Money Address","read_on":"2026-08-31"},{"url":"https://github.com/lightninglabs/L402/blob/master/protocol-specification.md","publisher":"Lightning Labs","title":"The L402 protocol specification","read_on":"2026-08-31"}],"handoff":{"routes":["/coverage"],"sentence":"probe402 records the receiving address each tracked endpoint quoted, in the form it arrived — open an endpoint from [the endpoint list](/coverage)."},"related":[{"slug":"l402","title":"L402","path":"/glossary/l402"},{"slug":"payto","title":"payTo","path":"/glossary/payto"},{"slug":"payment-challenge","title":"payment challenge","path":"/glossary/payment-challenge"}],"terms_used":["payment-challenge","l402"],"last_reviewed":"2026-08-31","review_hash":"49ed7108c0c70f22","url":"https://probe402.com/glossary/uma"},"requested_entry_problem":null}