{"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 it is chosen by whoever controls that endpoint at the moment of the quote, and 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, listing the endpoints that settle through the facilitator, so a listing is a curation decision rather than 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 authorizes a payment for one of those terms and retries carrying it; the resource is served. It is built for software rather than for people, so there is no account to create, no subscription to choose and no form to fill in 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 gas to submit.","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 in a WWW-Authenticate header; the agent retries with a payment credential in an Authorization header; the response carries the resource and a receipt. It reuses HTTP's own authentication machinery rather than defining headers of 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 — and 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 — which 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, and the agent presents the buyer, the cart and a payment credential — so 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, so 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 rather than the specification's: x402 names 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 define it as something the seller returns on success and never on an error, which 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 — and 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, which 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 — and it is the party that sets the price, names the receiving address and decides which facilitator 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, and the minimums differ enough that the choice of rail decides what an endpoint 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, so a payment can travel over MCP without an HTTP status code being involved at all.","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"}],"selected":{"slug":"machine-payment","kind":"concept","title":"machine payment","question":"What is a machine payment?","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 — which is what separates it from an agent buying goods through a merchant's checkout.","mechanism":["The category is named for the step it removes. Stripe's documentation for the pattern states that monetizing an API or service typically requires account creation, subscription selection and payment entry, and that those flows require human input, which blocks agents from completing tasks autonomously. Machine payments, in the same document's words, let agents pay for APIs and services programmatically: the server returns a payment challenge, the agent presents a valid payment credential, and the payment settles.","The boundary against [agentic commerce](/glossary/agentic-commerce) is drawn in that same documentation's own integration table, and it is drawn by capability rather than by opinion. Sharing a product catalogue with agents belongs to selling through them and is listed as unsupported for machine payments; the protocols each side is pointed at differ accordingly, with [MPP](/glossary/mpp) and [x402](/glossary/x402) named for accepting machine payments and the commerce protocols named for selling through agents.","For anything reading endpoints from outside, the consequence is that the terms are on the wire. A machine payment starts with a response a client can read without a person, so what an endpoint charges, on which network and to which address, is stated in the answer itself rather than inside an account somebody opened earlier. That is also the whole of what a single reading shows: the terms offered, at the moment they were asked for."],"citations":[{"url":"https://docs.stripe.com/payments/machine","publisher":"Stripe documentation","title":"Machine payments","read_on":"2026-08-31"},{"url":"https://docs.stripe.com/agentic-commerce","publisher":"Stripe documentation","title":"Agentic commerce","read_on":"2026-08-31"},{"url":"https://mpp.dev","publisher":"Machine Payments Protocol","title":"The Machine Payments Protocol specification site","read_on":"2026-08-31"}],"handoff":{"routes":["/coverage"],"sentence":"probe402 tracks endpoints that answer a request with machine-readable payment terms and archives every reading — the tracked set is at [the endpoint list](/coverage)."},"related":[{"slug":"agentic-commerce","title":"agentic commerce","path":"/glossary/agentic-commerce"},{"slug":"payment-challenge","title":"payment challenge","path":"/glossary/payment-challenge"},{"slug":"x402","title":"x402","path":"/glossary/x402"}],"terms_used":["agentic-commerce","mpp","x402"],"last_reviewed":"2026-08-31","review_hash":"786c556ffc3b8c08","url":"https://probe402.com/glossary/machine-payment"},"requested_entry_problem":null}