Glossary

/.well-known/agent-registration.json

Also: domain proof

Plain

An optional file an agent serves on a service domain to show it controls that domain, with a registrations entry that matches its on-chain id. ^{Source [1]}

STE

A file on a web domain that shows that the agent controls the domain.

Protocols:ERC-8004

3-D Secure

Also: 3DS, 3DS2, EMV 3DS, authentication_required

Plain

The EMVCo protocol in which the merchant and the card issuer exchange data so the issuer can authenticate the cardholder in an online payment, sometimes with a challenge. ACP added the `authentication_required` checkout status and a Delegate Authentication API for it, and UCP handles it through an authentication extension with device data and challenge actions. AP2 v0.2 defines no step-up mechanism of its own. ^{Source [2, 3, 4]}

STE

3-D Secure is the EMVCo protocol that lets the card issuer authenticate the cardholder in an online payment. ACP and UCP have functions for 3-D Secure.

Protocols:OpenAI ACPUCP

A2A

Also: Agent2Agent, Agent2Agent protocol, A2A protocol

Plain

The Agent2Agent protocol, an open standard hosted at the Linux Foundation that lets independent AI agents discover each other and exchange messages and tasks. IBM's Agent Communication Protocol merged into it in August 2025. AP2, UCP and x402 all define A2A bindings, and A2A is about agent messaging, while AP2 is about payment mandates. ^{Source [5, 6, 7, 8]}

STE

A2A is an open protocol for messages and tasks between AI agents. AP2, UCP and x402 can send their data over A2A.

Protocols:x402UCPAP2

AAIF

Also: Agentic AI Foundation

Plain

The Agentic AI Foundation, formed under the Linux Foundation on 2025-12-09 with founding contributions from Anthropic, Block and OpenAI. Its first projects were the Model Context Protocol, goose and AGENTS.md. None of the eight payment protocols in this atlas is an AAIF project. ^{Source [9]}

STE

The Agentic AI Foundation (AAIF) is a Linux Foundation group for open agent standards. MCP is one of its projects.

Accept-Payment

Also: Accept-Payment header

Plain

A request header in which an MPP client lists the method and intent pairs it supports, with optional q weights. The server's challenge stays authoritative. ^{Source [10, 11]}

STE

A header that lists the payment methods and intents that the client can use.

Protocols:Stripe MPP

Access key (Tempo)

Also: accessKey, keyAuthorization

Plain

A Tempo key authorization with limits that the payer signs once so a server can collect recurring MPP subscription charges. ^{Source [12]}

STE

A key with limits that the payer approves. The server uses it to collect each subscription payment.

Protocols:Stripe MPP

ACP discovery document

Also: acp.json, /.well-known/acp.json

Plain

The unauthenticated JSON file at /.well-known/acp.json that lists a seller's ACP versions, transports and services. ^{Source [13]}

STE

A public file on the server of the seller. It gives the ACP versions and services.

Protocols:OpenAI ACP

Agent card

Also: Agent Card, AgentCard, agent-card.json

Plain

In A2A, the JSON document that describes an agent: its name, endpoint, skills, security schemes and supported extensions, served at `/.well-known/agent-card.json`. Payment extensions such as a2a-x402 are declared in its `capabilities.extensions`, and UCP's A2A binding uses the Agent Card URL as its endpoint. An ERC-8004 registration file can list an A2A endpoint among its services. ^{Source [1, 5, 8, 14]}

STE

An agent card is the A2A document that describes an agent and its endpoint. A client reads the agent card before it sends a task.

Protocols:ERC-8004x402UCP

Agent Pay Acceptance Framework

Also: Acceptance Framework

Plain

Mastercard's rules and integration paths for merchants accepting agent payments, launched in October 2025. Mastercard's guides refer to it for full details, but its specification is not public. ^{Source [15, 16]}

STE

The Mastercard rules for merchants that accept payments from agents. The full text is not public.

Protocols:Mastercard Agent Pay

Agent Pay for Machines

Also: AP4M

Plain

A Mastercard service launched on 2026-06-10 for high-frequency, low-value payments by agents and machines, with credentialing, permissioning, transacting and settlement across cards, accounts and stablecoins. No API or pricing is published. ^{Source [17]}

STE

A Mastercard service for many small payments by agents and machines. It can settle on cards, accounts or stablecoins.

Protocols:Mastercard Agent Pay

Agent Pay Trust Framework

Also: Trust Framework

Plain

The name Mastercard gave on 2026-09-30 to the identity, intent, controls, execution and intelligence parts of Agent Pay, together with a probability score test in the US. No white paper was found. ^{Source [18]}

STE

The name for the five trust parts of Agent Pay: identity, intent, controls, execution and intelligence.

Protocols:Mastercard Agent Pay

Agent Provider

Also: Agent

Plain

In TAP, a certified AI platform that a payment scheme has onboarded and approved to pay on behalf of its account holders. It holds the signing key. ^{Source [19]}

STE

An AI platform that a payment scheme approved. It signs requests for the consumer.

Protocols:Visa TAP

Agentic Directory

Also: Agent Directory, Agentic Registry

Plain

Visa's directory, announced 2026-06-10, of agents and merchants it has verified as legitimate participants in agentic commerce. No public list was found. ^{Source [20]}

STE

A Visa list of agents and merchants that Visa verified.

Protocols:Visa TAP

Agentic token

Also: Mastercard Agentic Token, agentic network token, Agentic Tokens

Plain

A network token issued for purchases made by an AI agent, but the phrase names different products at different networks. At Mastercard, Agentic Tokens are Agent Pay credentials issued only to registered agents and built on Mastercard's existing tokenization. Stripe and Visa call Visa's agent credentials agentic network tokens, which are a separate product on a separate network. ^{Source [21, 22, 23, 24]}

STE

An agentic token is a network token for purchases by an AI agent. Visa and Mastercard use this name for different products.

Protocols:Visa TAPMastercard Agent Pay

agentId

Also: agent ID, agent identifier, agentRegistry

Plain

The number that identifies an agent in an ERC-8004 Identity Registry. It is the ERC-721 `tokenId` of the agent's identity token and is assigned in sequence when someone calls `register`. A globally unique reference pairs it with `agentRegistry`, a string of the form `{namespace}:{chainId}:{identityRegistry}`, such as `eip155:1:` plus the registry address. ^{Source [1, 25]}

STE

The agentId is the number of an agent in the ERC-8004 Identity Registry. The registry gives the next number to each new agent.

Protocols:ERC-8004

agentRegistry

Also: agent registry identifier

Plain

The string that names the Identity Registry an agent lives in: chain family, chain id and registry address joined by colons, such as eip155:1 plus the address. Together with agentId it identifies an agent globally. ^{Source [1]}

STE

A text value with the chain family, the chain number and the address of the registry.

Protocols:ERC-8004

agentURI

Also: agent URI, tokenURI, setAgentURI

Plain

The URI stored on-chain for an ERC-8004 agent that points to its registration file. The spec names `ipfs://`, `https://` and base64 `data:` URIs, and the owner or an approved operator can change it with `setAgentURI`. An `https://` file can change without any on-chain event, so only content-addressed URIs pin the content. ^{Source [1, 25]}

STE

The agentURI is the address of the registration file of an agent. The owner of the agent can change the agentURI at any time.

Protocols:ERC-8004

agentWallet

Also: agent wallet, setAgentWallet, getAgentWallet

Plain

A reserved metadata key in the ERC-8004 Identity Registry that holds the address where the agent receives payments. It defaults to the owner at registration and cannot be written through `setMetadata`. To change it, the owner calls `setAgentWallet` with a signature from the new wallet: an EIP-712 signature for an ordinary account or an ERC-1271 check for a contract wallet. ^{Source [1, 25]}

STE

The agentWallet is the address that receives payments for an agent. A change to this address needs a signature from the new wallet.

Protocols:ERC-8004

AI agent probability score

Also: probability score

Plain

A Mastercard signal, in US testing since 2026-09-30, that estimates how likely it is that an AI agent initiated a transaction. Fields and thresholds are not published. ^{Source [18]}

STE

A Mastercard value that shows how probable it is that an agent started a payment.

Protocols:Mastercard Agent Pay

Allowance

Also: Allowance, max_amount

Plain

The limits attached to an ACP delegated payment token. It holds `reason` (only `one_time` is defined), `max_amount` in minor units, `currency`, `checkout_session_id`, `merchant_id` and `expires_at`. The payment provider is expected to enforce it, but the spec does not define the errors when a limit is exceeded. ^{Source [26]}

STE

An allowance sets the limits of a delegated payment token. The limits are the maximum amount, the currency, the merchant, the checkout session and the expiry time.

Protocols:OpenAI ACP

ANS

Also: Agent Name Service

Plain

The Agent Name Service, a proposal for a DNS-based directory in which AI agents can be found and checked through certificates. Its first IETF draft, `draft-narajala-ans-00` (2025-05-16), expired and was replaced by an ANS v2 draft. It is an individual draft, not a working group standard. ^{Source [27]}

STE

The Agent Name Service (ANS) is a proposal for a directory of AI agents that uses DNS. ANS is an individual IETF draft.

API-Version header

Also: API-Version

Plain

The ACP request header that names the dated protocol version a client speaks, such as 2026-04-17. ^{Source [28]}

STE

The header that gives the version date of ACP that the client uses.

Protocols:OpenAI ACP

Auth-capture

Also: auth-capture scheme, AuthCaptureEscrow

Plain

An x402 scheme that copies the card pattern of authorize first, capture later. The client authorizes a hold, the server runs the work, then captures up to the held amount or voids the hold, and refunds stay possible until `refundDeadline`. On EVM the default contract is `AuthCaptureEscrow` from Base commerce-payments. ^{Source [29, 30]}

STE

Auth-capture is an x402 scheme that holds funds first and captures the funds later. The server can capture, void or refund the payment.

Protocols:x402

Authorization header

Also: Authorization: Payment, Payment-Authorization

Plain

The standard HTTP request header that carries credentials. In MPP the client retries the request with `Authorization: Payment` followed by a base64url credential, or with `Payment-Authorization` when the challenge asks for that header so the normal `Authorization` header stays free for other logins. A request with more than one Payment credential should be rejected. ^{Source [10]}

STE

The Authorization header carries the credential of the client. In MPP, the client sends the payment proof in this header.

Protocols:Stripe MPP

Autonomous mode (Verifiable Intent)

Also: three-layer mode

Plain

The Verifiable Intent mode in which the user signs open mandates with constraints and the agent key, and the agent later signs L3a and L3b. ^{Source [31, 32]}

STE

The mode where the user signs limits and the agent signs the final credentials later.

Protocols:Mastercard Agent Pay

Batch settlement

Also: batch-settlement, cloudflare:402

Plain

An x402 scheme that collects many small payments and settles them together. On EVM the client deposits into a payment channel, then sends a signed cumulative voucher with each request, and the server claims and settles many vouchers in one transfer. A separate `cloudflare:402` variant is credit backed: the client signs requests with RFC 9421 and Cloudflare bills that identity later. ^{Source [33, 34]}

STE

Batch settlement collects many small payments and settles them in one transfer. On EVM networks, it uses a payment channel and signed vouchers.

Protocols:x402

Bazaar

Also: bazaar extension, x402 Bazaar

Plain

A discovery extension for x402. A resource server describes its paid endpoint (HTTP inputs and outputs, or an MCP tool) in the `bazaar` extension, and a facilitator lists those endpoints at `GET /discovery/resources`. Agents can then search a catalog of paid services before they call one. ^{Source [35, 36]}

STE

Bazaar is an x402 extension for the discovery of paid services. A facilitator shows a list of the services that use this extension.

Protocols:x402

Builder code (ERC-8021)

Also: builder-code extension, ERC-8021

Plain

An x402 extension that appends an ERC-8021 suffix to settlement calldata, naming the app, the wallet or facilitator, and the service, so indexers can attribute payments. ^{Source [37]}

STE

A short code at the end of the settlement data. It shows which application and facilitator sent the payment.

Protocols:x402

Business Network Profile

Also: networkId, profile_

Plain

The Stripe merchant identity that the stripe MPP method puts in methodDetails.networkId so an SPT can be scoped to that seller. ^{Source [38]}

STE

The Stripe identifier of the seller. The payment token works only for this seller.

Protocols:Stripe MPP

Business profile

Also: /.well-known/ucp, UCP profile, platform profile

Plain

The JSON document a UCP business publishes at `/.well-known/ucp` to say which protocol versions, services, capabilities and payment handlers it supports, plus its public signing keys in `keys`. The platform (the agent side) publishes a matching platform profile at a URL it names in the `UCP-Agent` header. Comparing the two profiles is how UCP negotiation works. ^{Source [14, 39]}

STE

The business profile is a JSON document that tells the capabilities and payment handlers of a business. The business publishes the profile at a well-known address.

Protocols:UCP

CAIP-2

Also: chain ID, eip155:8453

Plain

A Chain Agnostic Improvement Proposal that names a blockchain with a `namespace:reference` string, such as `eip155:8453` for Base or a `solana:` genesis hash. x402 V2 uses CAIP-2 strings in its `network` field, where V1 used plain names such as `base-sepolia`. ERC-8004 builds its `agentRegistry` reference on the same pattern. ^{Source [36, 40]}

STE

CAIP-2 is a standard text format for the identifier of a blockchain. x402 uses this format in the network field.

Protocols:ERC-8004x402

CAIP-10

Also: clientAddress

Plain

A Chain Agnostic Improvement Proposal that names an account by adding an address to a CAIP-2 chain id, for example `eip155:1:` followed by the address. The ERC-8004 feedback file example writes `clientAddress` in this form. It lets one string say both which chain and which account. ^{Source [1, 41]}

STE

CAIP-10 is a standard text format for an account on a blockchain. The format adds the account address to a CAIP-2 chain identifier.

Protocols:ERC-8004

Capability

Also: capabilities, dev.ucp.shopping.checkout, capability negotiation

Plain

A named unit of functionality that both sides of a commerce protocol can declare, such as checkout, cart, order or identity linking. In UCP, capability names are reverse-domain strings like `dev.ucp.shopping.checkout`, and the business keeps only those both sides support, at the highest shared version. ACP has its own `capabilities` object for payment handlers, interventions and extensions. ^{Source [14, 42]}

STE

A capability is a function that a business or a platform can do. UCP keeps only the capabilities that the two sides both support.

Protocols:OpenAI ACPUCP

Capability intersection

Also: capability negotiation

Plain

The UCP negotiation step in which the business keeps only capabilities both profiles list, picks the highest version both support, and prunes extensions whose parent capability is gone. ^{Source [14]}

STE

The set of capabilities that the business and the platform both support, at the highest common version.

Protocols:UCP

Cart Mandate (v0.1)

Also: CartMandate

Plain

AP2 v0.1 object holding merchant-signed cart contents with a W3C PaymentRequest. Removed in v0.2, though a2a-x402 still embeds it. ^{Source [43, 44]}

STE

An old AP2 cart mandate that v0.2 removed.

Protocols:AP2

Challenge

Also: payment challenge, challenge id

Plain

In MPP, the server's offer to be paid, sent in `WWW-Authenticate: Payment`. It names the payment `method`, the `intent`, an encoded `request` with amount and currency, an optional `expires` time and an `id` that the server binds to all of those values, for example with an HMAC. A challenge is single use: a reused or unknown `id` fails with `invalid-challenge`. ^{Source [10]}

STE

In MPP, a challenge tells the client the payment method, the amount and the currency. The client can use each challenge one time only.

Protocols:Stripe MPP

Challenge binding

Also: HMAC binding, challenge id binding

Plain

Tying an MPP challenge id to all its parameters, usually with an HMAC-SHA256 over them, so a client cannot change what it pays for and a server can verify statelessly. ^{Source [10]}

STE

The server makes the challenge identifier from the challenge values with a secret key. Thus, nobody can change the values.

Protocols:Stripe MPP

Charge

Also: charge intent

Plain

The MPP intent for a single payment of a fixed `amount` in a given `currency`. The client pays through the named method and retries with a credential, and the server verifies and settles before it sends any part of the response. Every MPP payment method defines a charge. ^{Source [45]}

STE

Charge is the MPP intent for one payment of a fixed amount. The server must verify the payment before it sends the resource.

Protocols:Stripe MPP

Chargeback

Also: card dispute

Plain

The card-network process by which a cardholder's bank reverses a payment the cardholder disputes and takes the funds back from the merchant. In ACP the merchant, not OpenAI or the payment provider, handles refunds and chargebacks as merchant of record. AP2 mandates are meant as evidence in such disputes, but no network has published agent-specific chargeback rules. ^{Source [46, 47, 48]}

STE

A chargeback is the reversal of a card payment after the cardholder disputes it. The merchant of record handles chargebacks.

Protocols:OpenAI ACPAP2

ChatGPT payment sheet

Also: payment sheet

Plain

An Apps SDK checkout surface in ChatGPT, in private beta for select marketplace partners, that sends a payment token to the merchant's MCP server. ^{Source [49]}

STE

A payment window in ChatGPT apps. Only some partners can use it.

Protocols:OpenAI ACP

Checkout Enabler

Plain

In TAP, an intermediary that an agent may use to reach merchant sites. TAP only expects it to pass signatures and query parameters through unchanged. ^{Source [19]}

STE

A service between the agent and the merchant. It must send the signatures to the merchant without a change.

Protocols:Visa TAP

Checkout Mandate

Also: mandate.checkout.1, checkout_mandate, checkout_jwt, checkout_hash

Plain

The AP2 v0.2 mandate that approves one specific checkout. A closed Checkout Mandate (`vct` `mandate.checkout.1`) carries the merchant-signed `checkout_jwt` and its `checkout_hash`, and the merchant verifies it before it completes the order. UCP's AP2 extension sends it as `ap2.checkout_mandate` on the complete call. ^{Source [50, 51, 52]}

STE

A Checkout Mandate is the AP2 mandate for one checkout. The merchant verifies the mandate before it completes the order.

Protocols:UCPAP2

Checkout session

Also: CheckoutSession, checkout_sessions, checkout-sessions

Plain

The server-side record of one purchase in progress in ACP and UCP. The agent creates it with line items, updates it as the buyer picks shipping and payment, then completes or cancels it, and every response returns the full authoritative state, including `status`, totals and messages. ACP uses `/checkout_sessions` and UCP uses `/checkout-sessions`. ^{Source [28, 53]}

STE

A checkout session is the record of one purchase on the server of the business. The agent can create, update, complete or cancel the session.

Protocols:OpenAI ACPUCP

checkout_hash

Plain

Base64url hash of checkout_jwt inside the closed Checkout Mandate; SHA-256 unless the SD-JWT names another algorithm. ^{Source [50]}

STE

The hash of the signed checkout in the Checkout Mandate.

Protocols:AP2

checkout_jwt

Also: Checkout JWT

Plain

The merchant-signed JSON Web Token of the checkout that a Checkout Mandate carries. Its hash binds every mandate and receipt to one purchase. ^{Source [50]}

STE

The checkout that the merchant signs. Its hash links the mandates.

Protocols:AP2

Client Enabler

Also: token service provider (card method)

Plain

In the Visa-authored MPP card method, the party that provisions a network token and cryptogram for the client and encrypts them for the server. ^{Source [54]}

STE

The party that gets a card token for the client and encrypts it for the server.

Protocols:Stripe MPP

Closed mandate

Also: closed Checkout Mandate, closed Payment Mandate, human present

Plain

An AP2 v0.2 mandate for one exact checkout or payment, with all values fixed. The user can sign it directly on a Trusted Surface, or the agent can sign it under an open mandate the user approved earlier. Verifiers check the closed mandate and, when present, the chain back to its open mandate. ^{Source [55, 56]}

STE

A closed mandate is an AP2 mandate for one exact checkout or one exact payment. All the values in a closed mandate are fixed.

Protocols:AP2

cloudflare:402

Also: credit-backed batch settlement

Plain

A credit-backed binding of the x402 batch-settlement scheme in which Cloudflare is merchant of record, clients sign requests with RFC 9421, and Cloudflare bills the identity later. It is separate from the Monetization Gateway beta, which settles USDC on Base. ^{Source [34, 57]}

STE

A batch settlement network where Cloudflare gives credit and sends the bill later. The payment does not go to a blockchain.

Protocols:x402

cnf claim

Also: cnf, confirmation claim, RFC 7800

Plain

The confirmation claim from RFC 7800, which places a public key inside a token and says that whoever presents the token must prove control of that key. In AP2 open mandates `cnf` holds the agent's key, so only that agent can turn the open mandate into closed ones. Verifiable Intent uses `cnf` the same way to delegate from user to agent. ^{Source [32, 58, 59]}

STE

The cnf claim puts a public key in a token. Only the holder of the related private key can use the token.

Protocols:AP2Mastercard Agent Pay

Constraint

Also: constraints, unresolved_constraint, payment.amount_range, checkout.line_items

Plain

A machine-checkable rule inside an AP2 open mandate or a Verifiable Intent credential that a later purchase must meet. AP2 v0.2 defines keys such as `checkout.allowed_merchants`, `checkout.line_items`, `payment.amount_range`, `payment.budget` and `payment.agent_recurrence`. A verifier that does not recognize a constraint must treat it as failed and return `unresolved_constraint`. ^{Source [56, 59, 60]}

STE

A constraint is a rule that a future purchase must obey. If a verifier does not know a constraint, the verifier rejects the mandate.

Protocols:AP2Mastercard Agent Pay

Consumer recognition object

Also: agenticConsumer, Agentic Consumer Recognition Object, contextualData

Plain

The Visa TAP request body object `agenticConsumer` that lets a merchant recognize a returning shopper without receiving their identity in the clear. It carries the same `nonce` as the message signature, an `idToken`, `contextualData` (country, postal code, IP address, device data), `kid`, `alg` and a `signature` over the other fields. The merchant matches obfuscated email and phone values to its own accounts. ^{Source [19]}

STE

The consumer recognition object helps a merchant to identify a known customer. The object contains an ID token and a signature from the agent.

Protocols:Visa TAP

Content digest

Also: Content-Digest, RFC 9530, digest

Plain

A hash of an HTTP message body, sent in the `Content-Digest` header defined by RFC 9530. MPP challenges can carry a `digest` parameter so a payment is bound to one exact request body, which matters for POST requests. RFC 9421 signatures can cover the digest header to protect the body, but Visa TAP does not require it, so TAP signatures leave the body unbound. ^{Source [10, 19, 61]}

STE

A content digest is a hash of the body of an HTTP message. MPP uses the digest to connect a payment to one request body.

Protocols:Stripe MPP

Contextual data

Plain

The TAP object inside the consumer recognition object with countryCode, zip, ipAddress and deviceData of the consumer. ^{Source [19]}

STE

Data about the device and location of the consumer: country, postal code, IP address and device data.

Protocols:Visa TAP

Continue URL

Also: continue_url

Plain

A link in an ACP or UCP checkout where the buyer can finish the purchase on the merchant's own site. In UCP it must be present when the checkout status is `requires_escalation`, and the agent must open it for the buyer. It is the hand-off point when the agent cannot complete a step by itself. ^{Source [53, 62]}

STE

The continue URL is a link to the site of the business. The buyer uses this link to complete a checkout that the agent cannot complete.

Protocols:OpenAI ACPUCP

Cooperative close

Also: action close

Plain

Ending an MPP session channel by agreement: the client sends a final voucher and the server closes on chain, capturing only what was spent and refunding the rest. ^{Source [63]}

STE

The server closes the channel with the last voucher. The server keeps the used amount and returns the remainder.

Protocols:Stripe MPP

Covered components

Also: @authority, @path, @method, @target-uri

Plain

The list of HTTP message parts that an RFC 9421 signature protects, such as `@authority`, `@path`, `@method` or a header like `content-digest`. Anything not listed can be changed without breaking the signature. Visa TAP requires only `@authority` and `@path`, so the method, query string and body are not bound. ^{Source [19, 64]}

STE

Covered components are the parts of an HTTP message that a signature protects. A change to a part that is not covered does not make the signature fail.

Protocols:Visa TAPMastercard Agent Pay

Credential

Also: payment credential, MPP credential

Plain

In MPP, the client's answer to a challenge. It echoes the `challenge` parameters, adds a method-specific `payload` (a signed transaction, a Shared Payment Token, an encrypted card token and so on) and can name the payer in `source`, preferably as a DID. In verifiable credential systems the same word means a signed claim about a subject, which is a different thing. ^{Source [10]}

STE

In MPP, a credential is the reply of the client to a challenge. The credential contains the proof of payment for the payment method.

Protocols:Stripe MPP

Credential provider

Also: Credential Provider, Payment Credential Provider

Plain

The party that holds the user's payment credentials, such as a digital wallet or a payment network. In AP2 it checks the Payment Mandate before it returns a credential scoped to that checkout. UCP uses the same idea: the credential provider writes the payment handler specification, and the platform calls it to obtain a token. ^{Source [14, 55]}

STE

A credential provider keeps the payment credentials of the user. In AP2, the credential provider verifies the Payment Mandate before it gives a credential.

Protocols:UCPAP2

Cryptogram

Also: transaction cryptogram, dynamicData, DSRP cryptogram, dCVV

Plain

A one-time value computed for a single card transaction that proves the token was used by its legitimate holder for this payment. It travels with a network token, for example in the UCP `cryptogram` field, the ACP `cryptogram` field or the MPP `card` method's `dynamicData`. Mastercard's Level 3 Agent Pay guide mentions a DSRP cryptogram in its tokenized payload. ^{Source [16, 54, 65]}

STE

A cryptogram is a value for one card transaction only. The issuer uses the cryptogram to verify the use of a network token.

Protocols:OpenAI ACPUCPStripe MPPMastercard Agent Pay

Delegate Authentication

Also: delegated authentication

Plain

ACP endpoints, added in 2026-04-17, that run 3-D Secure 2 fingerprinting, challenges and results on behalf of an agent. ^{Source [3]}

STE

ACP endpoints that do 3-D Secure checks for the agent.

Protocols:OpenAI ACP

Delegate SD-JWT

Also: dSD-JWT

Plain

An individual IETF draft for chaining SD-JWTs through key binding, which AP2 uses to chain open and closed mandates. ^{Source [66]}

STE

A draft standard that links one signed token to the next.

Protocols:AP2

delegate_payload

Plain

An L2 and L3 claim in Verifiable Intent that lists references to the mandate disclosures, so a verifier can see that mandates exist even when it cannot read them. ^{Source [32, 67]}

STE

A claim that shows which mandates are in the credential.

Protocols:Mastercard Agent Pay

Delegated payment

Also: Delegate Payment, delegate_payment, Delegated Payment Spec

Plain

The part of ACP in which the agent sends the buyer's card to a payment provider or vault and gets back a token that only the merchant can use, within set limits. The call is `POST /agentic_commerce/delegate_payment` with the card and an `allowance`, and the answer is a vault token. Stripe's Shared Payment Token is the first implementation OpenAI names. ^{Source [46, 68]}

STE

Delegated payment lets an agent give a limited payment token to a merchant. The token does not show the card number to the merchant.

Protocols:OpenAI ACP

DID

Also: Decentralized Identifier, did:pkh, did:key

Plain

A Decentralized Identifier, a W3C standard (v1.0, 2022) for an identifier such as `did:key:...` or `did:pkh:...` that resolves to a document with public keys, without a central registry. MPP recommends a DID in the credential `source` field to name the payer, and ERC-8004 registration files can list a DID endpoint. x402 receipts can use a DID URL as the key id. ^{Source [1, 10, 69, 70]}

STE

A DID is an identifier that refers to a document with public keys. A central registry is not necessary for a DID.

Protocols:ERC-8004x402Stripe MPP

Digital Credentials API

Also: DC API, navigator.credentials.get digital

Plain

A W3C browser API, still a Working Draft on 2026-09-04, that lets a website request a credential from a wallet on the user's device through the browser or operating system. AP2 v0.2 recommends it as the way to run its OpenID4VP delegation flow. It keeps the wallet exchange inside a trusted platform channel rather than a custom redirect. ^{Source [56, 71]}

STE

The Digital Credentials API is a W3C browser API for a credential request to a wallet. AP2 recommends this API for the delegation of mandates.

Protocols:AP2

DSRP cryptogram

Also: Digital Secure Remote Payment

Plain

A one-time cryptogram for remote token payments. Mastercard says the Level 3 Agent Pay payload contains a DSRP cryptogram and card metadata. ^{Source [16]}

STE

A cryptographic value for one remote payment with a token.

Protocols:Mastercard Agent Pay

DTVC

Also: Dynamic Token Verification Code, Dynamic Token Validation Code, Virtual Card Token

Plain

A one-time code that Mastercard issues with a Virtual Card Token for guest checkouts, where the agent types the token into ordinary card fields. Mastercard validates the code and tells the issuer whether it did so. Mastercard's own pages expand the acronym both as Dynamic Token Validation Code and as Dynamic Token Verification Code. ^{Source [72, 73]}

STE

A DTVC is a code for one use that Mastercard gives with a virtual card token. Mastercard validates the DTVC during the payment.

Protocols:Mastercard Agent Pay

ECI

Also: Electronic Commerce Indicator, eci_value, eci

Plain

The Electronic Commerce Indicator, a short code sent with a card authorization that says what level of authentication took place, for example after 3-D Secure. UCP's network token credential and ACP's card object carry it as `eci_value`, and the MPP `card` token object carries `eci`. Issuers read it when they decide whether to approve. ^{Source [26, 54, 65]}

STE

The ECI is a code that tells the level of authentication for a card payment. The issuer reads the ECI before it approves the payment.

Protocols:OpenAI ACPUCPStripe MPP

EIP-712

Also: typed data, typed structured data, EIP-712 domain

Plain

The Ethereum standard for hashing and signing typed, structured data instead of opaque bytes, so a wallet can show the user what they sign. A domain separator (name, version, chain id, contract) binds the signature to one app and chain. x402 uses EIP-712 for every EVM payment signature, and ERC-8004 uses it for `setAgentWallet`. ^{Source [1, 36, 74]}

STE

EIP-712 is the Ethereum standard for signatures on typed data. The signature is valid only for one domain and one chain.

Protocols:ERC-8004x402

EIP-3009

Also: ERC-3009, transferWithAuthorization, TransferWithAuthorization, receiveWithAuthorization

Plain

An Ethereum token standard, still in Draft, that lets a holder sign an off-chain authorization so that someone else submits the transfer and pays the gas. The signed message carries `from`, `to`, `value`, `validAfter`, `validBefore` and a random 32-byte `nonce`. It is the default method of the x402 `exact` scheme on EVM, and USDC implements it. ^{Source [75, 76]}

STE

EIP-3009 lets a token holder sign a transfer that another party sends to the chain. Each authorization has a time window and a nonce.

Protocols:x402

EMVCo

Also: EMV

Plain

The technical body, formed in 1999 and owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa, that maintains the EMV specifications for chip cards, payment tokenization, 3-D Secure and Secure Remote Commerce. On 2026-09-01 it published a draft framework for card-based agent payments for comment. It lists Know Your Agent and agentic transaction indicators as possible future work. ^{Source [77, 78, 79]}

STE

EMVCo is the technical body that writes the EMV specifications for card payments. Six card networks own EMVCo.

Protocols:Visa TAPMastercard Agent Pay

ERC-721

Also: non-fungible token, tokenId

Plain

The Ethereum standard for non-fungible tokens, where each `tokenId` is unique and has one owner. ERC-8004 makes every agent identity an ERC-721 token, so an identity can be transferred and approved with ordinary NFT tools. ERC-721 status is Final. ^{Source [1, 80]}

STE

ERC-721 is the Ethereum standard for unique tokens. In ERC-8004, each agent identity is one ERC-721 token.

Protocols:ERC-8004

ERC-1271

Also: isValidSignature

Plain

The Ethereum standard for checking a signature when the signer is a smart contract wallet rather than a key. The verifier calls `isValidSignature` on the wallet contract and expects the magic value `0x1626ba7e`. ERC-8004 uses it when a contract wallet becomes an `agentWallet`, and the x402 Sign-In-With-X extension uses it to verify smart wallet signatures. ^{Source [1, 81, 82]}

STE

ERC-1271 is the Ethereum standard for the check of a signature from a smart contract wallet. The wallet contract tells the verifier if the signature is valid.

Protocols:ERC-8004x402

ERC-3643 (T-REX)

Also: T-REX

Plain

A Final ERC for permissioned tokens. Transfers pass only between wallets whose identities carry the claims the token requires. ^{Source [83]}

STE

A standard for tokens that only verified holders can receive.

Protocols:ERC-8004

ERC-8226 Regulated Agent Mandate

Also: RAMS

Plain

A Draft ERC that lets a verified principal give an agent scoped, time-bounded and capped authority, using ERC-8004 for agent identity and ERC-3643 or ERC-7943 for token compliance. ^{Source [84]}

STE

A draft standard that gives an agent limited authority for regulated tokens.

Protocols:ERC-8004AP2

Escalation

Also: requires_escalation

Plain

The UCP checkout state `requires_escalation`, which means the business needs the buyer to act directly. The response must carry a `continue_url` and at least one message with severity `requires_buyer_input` or `requires_buyer_review`. ACP added the same status name in its 2026-01-30 schema without an RFC definition. ^{Source [53, 85]}

STE

Escalation is a checkout status that tells the agent that the buyer must do a step. The agent must open the continue URL for the buyer.

Protocols:OpenAI ACPUCP

Exact scheme

Also: exact

Plain

The default x402 scheme: the client pays one fixed amount that the server names in advance. On EVM networks the client usually signs an EIP-3009 `TransferWithAuthorization` message, and Permit2 and ERC-7710 delegations are alternative methods. The facilitator submits the transfer, so the client does not need gas. ^{Source [76, 86]}

STE

The exact scheme transfers one fixed amount for one request. The server sets the amount before the client signs the payment.

Protocols:x402

Extension

Also: extensions, ExtensionDeclaration

Plain

An optional add-on that changes or adds fields to a base capability or message. UCP extensions name their parent in `extends`, for example the discount, fulfillment and AP2 mandate extensions of checkout, and are dropped when their parent is not shared. ACP has an extensions framework that only the discount extension uses, and x402 carries extensions such as `bazaar` in an `extensions` map. ^{Source [14, 36, 87]}

STE

An extension adds optional fields or functions to a base capability or message. An extension does not operate when its parent capability is not available.

Protocols:x402OpenAI ACPUCP

Facilitator

Also: x402 facilitator, /verify, /settle

Plain

In x402, a facilitator is a server that checks a client's signed payment and then broadcasts it to the network on behalf of the resource server. It exposes `POST /verify`, `POST /settle` and `GET /supported`, and it usually pays the gas. The x402 docs say it does not hold funds or act as a custodian, and a resource server can also verify and settle on its own. ^{Source [36, 88]}

STE

In x402, a facilitator is a server that examines a signed payment and sends the payment to the network. The facilitator does not keep the funds of the client.

Protocols:x402

Fee payer

Also: feePayer, hostedFeePayer

Plain

The party that pays network fees for a transaction. In MPP Tempo methods the server can co-sign as fee payer; Stripe's hostedFeePayer makes Stripe pay. ^{Source [89, 90]}

STE

The party that pays the network fee for a transaction.

Protocols:Stripe MPP

Feed API

Also: product feed API

Plain

The ACP 2026-04-17 API, hosted by the agent, that merchants call to push product and variant data. ^{Source [91]}

STE

An API on the agent side. The merchant uses it to send product data.

Protocols:OpenAI ACP

Feedback file

Also: feedbackURI, feedbackHash, off-chain feedback file, proofOfPayment

Plain

An optional off-chain JSON document that adds detail to one ERC-8004 feedback entry. It repeats `agentRegistry`, `agentId`, `clientAddress`, `createdAt`, `value` and `valueDecimals`, and can add MCP, A2A or OASF context and a `proofOfPayment` object with a transaction hash. The on-chain `giveFeedback` call records its URI and, unless the URI is content addressed, a keccak256 `feedbackHash`. ^{Source [1]}

STE

A feedback file gives more data about one feedback entry. The file is off-chain, and a hash on the chain can protect its content.

Protocols:ERC-8004

feedbackAuth

Plain

A removed ERC-8004 mechanism: an agent-signed permission that a client needed before giving feedback. Removed from the contracts on 2025-11-12 and from the text on 2026-01-07. ^{Source [92, 93]}

STE

A permission that the agent signed for feedback. The standard does not use it now.

Protocols:ERC-8004

feedbackIndex

Plain

A counter that starts at 1 for the feedback one client gave one agent. Used to read, revoke or respond to a specific entry. ^{Source [1]}

STE

A number that identifies one feedback item from one client.

Protocols:ERC-8004

FIDO Alliance

Also: FIDO

Plain

The industry association behind the FIDO authentication standards and passkeys. Google donated AP2 to the FIDO Alliance on 2026-04-28, when FIDO also formed a new Agentic Authentication technical working group; its Payments working group already existed from 2025. Card networks use FIDO-based payment passkeys to authenticate cardholders. ^{Source [94, 95, 96]}

STE

The FIDO Alliance is the industry group for FIDO authentication standards and passkeys. AP2 is now a FIDO Alliance project.

Protocols:Visa TAPAP2Mastercard Agent Pay

Finality

Also: settlement finality, deterministic finality

Plain

The point after which a payment can no longer be reversed or reorganized out of the ledger. On Tempo, Simplex BFT consensus gives deterministic finality with blocks about every 600 ms, while on many other chains finality is probabilistic and grows with each block. x402 `lnbtc` lists unmet finality as a failure, and card payments stay reversible through chargebacks long after authorization. ^{Source [97, 98]}

STE

Finality is the point after which nobody can reverse a payment. Tempo has deterministic finality.

Protocols:x402Stripe MPP

Forced close

Also: requestClose, withdraw

Plain

Ending an MPP session channel without the server: the client calls requestClose, waits a grace period of at least 15 minutes, then withdraws what is left. ^{Source [63]}

STE

The client closes the channel without the server. The client waits 15 minutes or more, then takes back the money.

Protocols:Stripe MPP

GENIUS Act

Also: Public Law 119-27, S. 1582

Plain

The first US federal law for payment stablecoins, signed on 2025-07-18 as Public Law 119-27. It takes effect on the earlier of 2027-01-18 or 120 days after final implementing rules, and on 2026-10-11 the final rules were still pending. The Act does not address AI agents as payers. ^{Source [99, 100]}

STE

The GENIUS Act is the US law for payment stablecoins. The law does not refer to AI agents.

HTTP 402

Also: 402 Payment Required, Payment Required, 402

Plain

The HTTP status code 402 Payment Required. RFC 9110 still lists it as reserved for future use, so each protocol that uses it defines its own meaning. x402 answers with 402 and a `PAYMENT-REQUIRED` header, and MPP answers with 402 and a `WWW-Authenticate: Payment` challenge. ^{Source [10, 101, 102]}

STE

HTTP 402 is the status code for Payment Required. x402 and MPP use this code to tell a client that a resource needs a payment.

Protocols:x402Visa TAPStripe MPP

Human not present

Also: autonomous mode

Plain

AP2 mode in which the user signs open mandates with constraints and the agent later signs closed mandates with its own key. ^{Source [103]}

STE

The mode where the agent buys inside limits that the user set.

Protocols:AP2

Human present

Also: direct mode

Plain

AP2 mode in which the user approves the exact closed Checkout and Payment Mandates on a Trusted Surface. ^{Source [103]}

STE

The mode where the user approves the exact purchase.

Protocols:AP2

ID token

Also: idToken, mastercardIdToken, OpenID Connect ID Token

Plain

A signed JSON Web Token that states who a user is, in the format OpenID Connect defines (`iss`, `sub`, `aud`, `exp`, `iat`, with optional claims such as `auth_time` and `amr`). In Visa TAP, Visa signs the ID token inside the consumer recognition object and puts only obfuscated email and phone values in it. Mastercard's `mastercardIdToken` plays a similar role in Agent Pay. ^{Source [19, 104]}

STE

An ID token is a signed token that identifies a user. In Visa TAP, Visa signs the ID token.

Protocols:Visa TAPMastercard Agent Pay

Idempotency key

Also: Idempotency-Key, Idempotent-Replayed

Plain

A unique value the client sends in the `Idempotency-Key` header so that a retried request is not processed twice. Since ACP 2026-04-17 it is mandatory on every POST: the same key with a different body returns 422, a key still in flight returns 409, and a replay returns the original response with `Idempotent-Replayed: true`. UCP marks the header required in its OpenAPI, and MPP asks for it on non-idempotent methods. ^{Source [10, 28, 105]}

STE

An idempotency key is a unique value that the client sends with a request. If the client sends the request again, the server does not do the operation two times.

Protocols:OpenAI ACPUCPStripe MPP

Identity linking

Also: dev.ucp.common.identity_linking, account linking

Plain

The UCP capability that links a buyer's account at a business to the agent platform through OAuth 2.0. It uses the authorization code flow with PKCE `S256` and scopes derived from capabilities, such as `dev.ucp.shopping.order:read`. Since 2026-08-25 an accelerated flow lets a trusted identity provider issue a grant by token exchange. ^{Source [106]}

STE

Identity linking connects the account of a buyer at a business to the agent platform. UCP uses OAuth 2.0 for this connection.

Protocols:UCP

Identity Registry (ERC-8004)

Also: ERC-8004 Identity Registry

Plain

The ERC-721 contract that mints agent identities, stores agentURI and metadata, and holds the agentWallet. Not the same thing as the ERC-3643 Identity Registry. ^{Source [1, 83]}

STE

The contract that makes a token for each agent and keeps the address of its file.

Protocols:ERC-8004

Immediate mode (Verifiable Intent)

Also: two-layer mode

Plain

The Verifiable Intent mode in which the user signs final checkout and payment values in L2 and no L3 is created. ^{Source [31, 32]}

STE

The mode where the user signs the final values. The agent does not sign credentials.

Protocols:Mastercard Agent Pay

Instant Checkout

Also: ChatGPT Instant Checkout

Plain

ChatGPT's 2025 in-chat purchase feature that launched ACP; OpenAI scaled it back in March 2026 in favor of merchant checkout. ^{Source [107, 108]}

STE

The 2025 ChatGPT function that let a buyer pay in the chat. OpenAI made it smaller in 2026.

Protocols:OpenAI ACP

Intelligent Commerce Connect

Plain

A Visa on-ramp, in pilot since 2026-04-08, that lets merchants accept agent payments initiated through TAP, MPP, ACP and UCP. ^{Source [109]}

STE

A Visa service that lets merchants accept agent payments from different protocols.

Protocols:Visa TAP

Intent (MPP)

Also: payment intent type

Plain

In MPP, the kind of payment a challenge asks for, given in the `intent` parameter. The drafts define `charge` (one payment), `session` (metered payments over a channel, Tempo only) and `subscription` (recurring payments). It has nothing to do with a Stripe PaymentIntent object or with Mastercard's Verifiable Intent. ^{Source [10, 45]}

STE

In MPP, the intent tells the type of payment. The three intents are charge, session and subscription.

Protocols:Stripe MPP

Intent API (Mastercard)

Also: Mastercard Intent API

Plain

A Mastercard API that registers an agent-captured purchase intent and returns an intentId with tokenized credentials, which the merchant validates at checkout. Field names are published; the schema is not. ^{Source [16]}

STE

A Mastercard API that keeps the purchase intent of the consumer. It gives an intent identifier and a token.

Protocols:Mastercard Agent Pay

Intent Mandate (v0.1)

Also: IntentMandate

Plain

AP2 v0.1 object that described a purchase in natural language with merchants, SKUs and expiry. Removed in v0.2. ^{Source [43]}

STE

An old AP2 mandate that v0.2 removed.

Protocols:AP2

Intent trace

Also: intent_trace

Plain

An optional object on an ACP cancel request with a reason code, such as shipping_cost, that says why the buyer did not finish. ^{Source [110]}

STE

Data that tells the merchant why the buyer stopped the purchase.

Protocols:OpenAI ACP

JCS

Also: JSON Canonicalization Scheme, RFC 8785

Plain

A rule set (RFC 8785) that serializes JSON the same way everywhere. MPP encodes the request parameter with it so binding inputs match across implementations. ^{Source [10]}

STE

A standard that writes JSON data in one fixed form.

Protocols:Stripe MPP

JWKS

Also: JWK Set, JWK, /.well-known/jwks, jwks_uri

Plain

A JSON Web Key Set, the RFC 7517 format for publishing a list of public keys, each with a key type and a `kid`. Visa's TAP key store is a JWKS at `https://mcp.visa.com/.well-known/jwks`, and UCP profiles carry their signing keys as a JWK set in `keys`. The MPP `card` method can point to a server key with `jwksUri`. ^{Source [19, 39, 111]}

STE

A JWKS is a JSON document that contains a list of public keys. Verifiers get keys from a JWKS to verify signatures.

Protocols:Visa TAPUCPStripe MPP

Key binding

Also: KB-JWT, key binding JWT, kb-jwt

Plain

A proof, attached to an SD-JWT, that the party presenting it holds the private key named inside it. The holder signs a short key binding JWT over a nonce, an audience and a hash of the presentation, which stops a stolen token from being replayed by someone else. AP2 mandates and Verifiable Intent use key binding to tie each step to the user's or agent's key. ^{Source [32, 112]}

STE

Key binding proves that the presenter of an SD-JWT has the private key in the token. This proof stops a replay of a stolen token.

Protocols:AP2Mastercard Agent Pay

keyid

Also: keyId, kid, key identifier

Plain

The RFC 9421 signature parameter that tells the verifier which public key to use. In Visa TAP it is an opaque string that the merchant looks up in Visa's key store, and in Mastercard Agent Pay it names the agent's key in the network key directory. The Web Bot Auth draft requires it to be a JWK SHA-256 thumbprint. ^{Source [19, 64, 113]}

STE

The keyid parameter identifies the public key for a signature. The verifier uses the keyid to find the key in a key directory.

Protocols:Visa TAPMastercard Agent Pay

Know your agent

Also: KYA, Know Your Agent

Plain

A family of practices, by analogy with know your customer, for identifying and vetting the AI agent behind a transaction and the party responsible for it. Mastercard requires agents to register and pass certification before they transact, and on 2026-09-30 named Skyfire as a KYA provider for Agent Pay. EMVCo lists Know Your Agent as possible future work, and no network has published KYA rules as a standard. ^{Source [18, 79, 114]}

STE

Know your agent (KYA) is the identification and check of the AI agent in a transaction. Mastercard lets only registered agents make transactions.

Protocols:Visa TAPMastercard Agent Pay

L402

Also: LSAT, Lightning HTTP 402, bLIP-0026

Plain

A Lightning Labs protocol for paid HTTP APIs: the server answers 402 with a `WWW-Authenticate: L402` challenge carrying a token and a BOLT11 invoice, and the client pays and returns the token with the payment preimage. The original Lightning Labs spec fixes the token as a macaroon, while bLIP-0026, rewritten on 2026-02-25, is token agnostic and makes macaroons optional. No source states that x402 descends from L402. ^{Source [115, 116, 117]}

STE

L402 is an HTTP payment protocol that uses a Lightning invoice. The client pays the invoice and sends the preimage as proof.

Protocols:x402

Lightning invoice

Also: BOLT11, BOLT11 invoice, payment_hash

Plain

A BOLT11 payment request on the Bitcoin Lightning Network that names an amount and a payment hash, signed by the receiving node. Paying it reveals the preimage of that hash to the payer. The x402 `exact` scheme on Lightning (`lnbtc`), the MPP `lightning` method and L402 all use BOLT11 invoices. ^{Source [98, 115, 118]}

STE

A Lightning invoice is a signed payment request on the Lightning Network. When the payer pays the invoice, the payer gets the preimage.

Protocols:x402Stripe MPP

Line item

Also: line_items, LineItem

Plain

One product line in a cart, checkout or order, with its item, quantity and totals. In ACP and UCP the `line_items` array is required when a checkout session is created, and the merchant returns the authoritative version with prices and taxes filled in. The agent should show the merchant's totals rather than compute its own. ^{Source [62, 119]}

STE

A line item is one product line in a checkout, with the item, the quantity and the totals. The business calculates the totals for each line item.

Protocols:OpenAI ACPUCP

Macaroon

Also: macaroons

Plain

A bearer credential, described in a 2014 NDSS paper, whose holder can add caveats that narrow what it allows, such as expiry or allowed services, without contacting the issuer. The original L402 spec uses a macaroon as its token, and bLIP-0026 keeps macaroons as one optional token format. None of the eight protocols in this atlas uses macaroons. ^{Source [115, 116, 120]}

STE

A macaroon is a credential that its holder can restrict with caveats. The original L402 specification uses macaroons.

Mandate

Also: mandates, AP2 mandate, Mandate Content

Plain

In AP2, a signed, verifiable record of what a user authorized an agent to do, so that merchants, payment processors and networks can check it with deterministic code. AP2 v0.2 (2026-04-28) has two kinds, the Checkout Mandate and the Payment Mandate, each either closed or open, issued as SD-JWT credentials. v0.1 used Intent, Cart and Payment Mandates instead; v0.2 has no Intent or Cart Mandate. ^{Source [43, 55]}

STE

In AP2, a mandate is a signed record of the actions that a user lets an agent do. Merchants and payment processors verify the mandate with deterministic code.

Protocols:AP2

Mandate receipt

Also: Payment Receipt, Checkout Receipt

Plain

Verifier-signed JWT returned after a mandate is presented, with a status and a reference that is the hash of the closed mandate. ^{Source [56, 121]}

STE

A signed answer that tells if the mandate was accepted.

Protocols:AP2

Mastercard Virtual Card Token

Also: MVCT, virtual card token

Plain

A Mastercard token for web guest checkouts that comes with an expiry date and a one-time DTVC, so an agent can type all three into a normal card form. ^{Source [72, 122]}

STE

A Mastercard token that an agent can put in a usual card form. It comes with a code for one use.

Protocols:Mastercard Agent Pay

mastercardIdToken

Also: Agent User Identity

Plain

A Mastercard-issued JWT identifying the consumer, carried in the Level 2 Agent User Identity object; compatible with OpenID Connect ID Tokens. ^{Source [104]}

STE

A token from Mastercard that identifies the consumer. The agent sends it in the request body.

Protocols:Mastercard Agent Pay

MCP

Also: Model Context Protocol

Plain

The Model Context Protocol, an open protocol that connects AI applications to tools and data through JSON-RPC 2.0 messages between hosts, clients and servers. Several payment protocols ride on it: x402 and MPP define MCP transports, ACP and UCP publish OpenRPC bindings, and Visa and Mastercard ship MCP servers. Since December 2025 it is a project of the Agentic AI Foundation. ^{Source [9, 123, 124, 125, 126, 127, 128]}

STE

MCP is an open protocol that connects AI applications to tools and data. x402, MPP, ACP and UCP have MCP bindings.

Protocols:x402OpenAI ACPUCPStripe MPP

MDES

Also: Mastercard Digital Enablement Service

Plain

Mastercard Digital Enablement Service, Mastercard's tokenization platform for card numbers, used by wallets and other token requestors. The Agent Pay pages read for this atlas say only that Agentic Tokens build on Mastercard's existing tokenization and do not name MDES. Mastercard is retiring its MDES for Merchants product on 2026-12-31 in favor of Secure Card on File. ^{Source [21, 129, 130]}

STE

MDES is the Mastercard service that replaces card numbers with tokens. The Agent Pay pages do not use the name MDES.

Protocols:Mastercard Agent Pay

Merchant authorization

Also: ap2.merchant_authorization

Plain

The business's detached JWS signature over a JCS-canonical UCP checkout, sent in every checkout response when the AP2 extension is active. ^{Source [52, 131]}

STE

The signature of the business on the checkout. The platform must verify it before it shows the checkout.

Protocols:UCP

Merchant of record

Also: MoR, merchant of record agreement

Plain

The business that is legally the seller in a transaction: its name appears on the card statement and it carries refunds, chargebacks, taxes and compliance. In ACP and UCP the merchant stays merchant of record, and OpenAI's docs say neither OpenAI nor the payment providers take that role. In the `cloudflare:402` x402 variant, the network itself acts as merchant of record. ^{Source [34, 46, 132]}

STE

The merchant of record is the business that sells the product by law. This business is responsible for refunds, chargebacks and taxes.

Protocols:x402OpenAI ACPUCP

Merchant payment processor

Also: Merchant Payment Processor, MPP (AP2)

Plain

The AP2 role that processes the payment for the merchant, checks that the payment credential is scoped to this checkout, and signs the Payment Receipt. AP2 abbreviates it as MPP. That MPP has nothing to do with the Stripe and Tempo Machine Payments Protocol. ^{Source [55, 133]}

STE

The merchant payment processor is the AP2 role that processes the payment for the merchant. In AP2 documents, MPP means this role.

Protocols:AP2

Merchant-Signature

Also: Merchant-Signature header

Plain

The header on ACP order webhooks that carries a Unix timestamp and an HMAC-SHA256 signature of the raw body. ^{Source [134]}

STE

The header that has the time and the HMAC signature of an order message.

Protocols:OpenAI ACP

MiCA

Also: Markets in Crypto-Assets Regulation, Regulation (EU) 2023/1114

Plain

The EU Markets in Crypto-Assets Regulation, Regulation (EU) 2023/1114, which licenses crypto-asset service providers and sets rules for stablecoin issuers. Its transitional period for service providers ended on 2026-07-01, so firms without MiCA authorization had to stop serving EU clients. It matters to agent payments that settle in stablecoins, such as x402 and MPP on chain. ^{Source [135, 136]}

STE

MiCA is the EU regulation for crypto-assets and stablecoins. Service providers without a MiCA license must not serve EU clients after 2026-07-01.

Minor units

Also: minor unit

Plain

Money written as an integer count of the currency's smallest unit, as defined by ISO 4217: cents for USD, no subdivision for JPY. ACP and UCP send all amounts this way, so 1999 in USD means 19.99 dollars. x402 and MPP use a similar idea, called atomic units or base units, for token amounts. ^{Source [62, 65]}

STE

Minor units show an amount of money as a whole number of the smallest unit of the currency. For example, 1999 minor units in USD is 19.99 dollars.

Protocols:OpenAI ACPUCP

MPPscan

Also: MPP explorer

Plain

A public explorer by Merit Systems that indexes MPP servers, agents, transactions and volume, mostly on Tempo. ^{Source [137]}

STE

A public web site that shows MPP payments and servers.

Protocols:Stripe MPP

Namespace authority binding

Also: authority binding

Plain

The UCP rule that a capability's schema URL host must match its reverse-DNS name. It proves who published a schema, not that the publisher is trustworthy. ^{Source [14]}

STE

A rule. The host of the schema address must agree with the name of the capability.

Protocols:UCP

NANDA

Also: Networked AI Agents in Decentralized Architecture, Project NANDA

Plain

Networked AI Agents in Decentralized Architecture, an MIT Media Lab research project on an open internet of agents with registries, discovery and trust between agents. It is research infrastructure, not a payment protocol. ERC-8004 and NANDA both address how agents find and trust each other. ^{Source [138]}

STE

NANDA is a research project of the MIT Media Lab. The project studies the discovery of AI agents and trust between agents.

Network token

Also: payment token, EMV Payment Token, network_token

Plain

A substitute card number issued by a card network's token service in place of the real card number (PAN), usable only within limits such as one merchant, device or channel. Each payment with it usually carries a one-time cryptogram. ACP, UCP and the MPP `card` method all have fields for network tokens, and both Visa's and Mastercard's agent programs rely on them. ^{Source [26, 65, 139]}

STE

A network token is a number that replaces the real card number. A network token operates only for a specified merchant, device or channel.

Protocols:Visa TAPOpenAI ACPUCPStripe MPPMastercard Agent Pay

Nonce

Plain

A value used once, so that a captured message cannot be accepted a second time. Visa TAP and Mastercard Agent Pay require a `nonce` signature parameter and reuse it inside the signed body objects to bind them to the request. x402 EIP-3009 authorizations and many other signed payloads carry their own random nonce for the same reason. ^{Source [19, 22, 76]}

STE

A nonce is a value that a party uses one time only. A verifier rejects a message with a nonce that it saw before.

Protocols:x402Visa TAPMastercard Agent Pay

OASF

Also: Open Agentic Schema Framework

Plain

The Open Agentic Schema Framework from the AGNTCY project, a schema system for describing an agent's skills, domains and other attributes as structured records. ERC-8004 registration files show an OASF service entry with `skills` and `domains`, and its feedback files can carry OASF context. It describes agents; it does not move payments. ^{Source [1, 140]}

STE

OASF is a schema system that describes the skills and attributes of AI agents. ERC-8004 files can contain OASF data.

Protocols:ERC-8004

offer-receipt extension

Also: signed receipt, signed offer

Plain

An x402 extension for signed offers and receipts in EIP-712 or JWS format, useful as evidence. The SDK parity table lists it for TypeScript only. ^{Source [70, 141]}

STE

An extension that gives a signed offer before payment and a signed receipt after payment.

Protocols:x402

ONCHAINID

Plain

The identity contract used by ERC-3643 tokens. It holds keys by purpose and claims signed by trusted issuers, such as KYC results. ^{Source [142, 143]}

STE

A contract that keeps keys and signed claims for one identity.

Protocols:ERC-8004

Open mandate

Also: mandate.checkout.open.1, mandate.payment.open.1, human not present

Plain

An AP2 v0.2 mandate that a user signs in advance for a purchase the agent will make later without the user present. Instead of a fixed checkout, it lists `constraints` (for example allowed merchants, line items, an amount range or a budget) and binds the agent's key in `cnf`. The agent later creates a closed mandate that must satisfy every constraint. ^{Source [56, 59, 144]}

STE

An open mandate lets an agent buy later without the user. The mandate contains constraints and the public key of the agent.

Protocols:AP2

OpenID4VP

Also: OpenID for Verifiable Presentations, transaction_data

Plain

OpenID for Verifiable Presentations 1.0, the OpenID Foundation standard (final 2025-07-09) for asking a wallet to present a credential. AP2 v0.2 uses it to delegate: a `transaction_data` entry of type `delegate` carries the mandate content that the wallet signs. The AP2 example uses the browser Digital Credentials API as the channel. ^{Source [56, 145]}

STE

OpenID4VP is a standard that lets a verifier ask a wallet for a credential. AP2 uses OpenID4VP to get a signed mandate from the wallet of the user.

Protocols:AP2

Order adjustment

Also: adjustments

Plain

An ACP order entry for a change after purchase, such as a refund, return, exchange or dispute, with status pending, completed or failed. ^{Source [62]}

STE

A change to an order after the purchase, for example a refund.

Protocols:OpenAI ACP

Order webhook

Also: order_create, order_update

Plain

A signed message from the merchant to the agent about an ACP order, with event type order_create or order_update. ^{Source [134]}

STE

A message from the merchant to the agent about the status of an order.

Protocols:OpenAI ACP

PAN

Also: primary account number, FPAN, funding PAN

Plain

The primary account number, the long number printed on a payment card. Tokenization exists to keep it away from merchants and agents, because a stolen PAN can be reused. ACP distinguishes `fpan` from `network_token`, and UCP v2026-08-25 split PAN and network token into separate credential types. ^{Source [26, 65, 139]}

STE

The PAN is the primary account number of a payment card. Tokens replace the PAN to keep it safe from merchants and agents.

Protocols:OpenAI ACPUCP

Passkey

Also: passkeys, WebAuthn credential, FIDO credential

Plain

A phishing-resistant login credential based on public-key cryptography, created and used through the W3C WebAuthn standard and the FIDO Alliance specifications. The private key stays on the user's device or syncs between the user's devices, and the user unlocks it with a PIN or biometric. Card networks now use passkeys to authenticate cardholders for agent purchases. ^{Source [146, 147]}

STE

A passkey is a credential that uses a private key on the device of the user. The user unlocks the passkey with a PIN or a biometric.

Protocols:Visa TAPMastercard Agent Pay

Payment account reference

Also: PAR, paymentAccountReference

Plain

A reference to the funding account behind a card credential, carried in TAP's cardMetadata so merchants can link token and virtual card payments to one account. ^{Source [19]}

STE

A reference to the account behind a card. It links different tokens of one card.

Protocols:Visa TAP

Payment channel

Also: escrow channel, channelId

Plain

An on-chain deposit that lets two parties exchange many off-chain payments and settle only the net result. The payer locks funds, sends vouchers as it uses the service, and either side closes the channel; a forced close starts a grace period before the payer can withdraw. MPP Tempo sessions and the x402 `batch-settlement` scheme on EVM both use channels. ^{Source [33, 63]}

STE

A payment channel is a deposit on the chain for many small payments. The two parties settle only the final total on the chain.

Protocols:x402Stripe MPP

Payment container

Also: agenticPaymentContainer, Agentic Payment Container, browsingIOU, cardMetadata

Plain

The Visa TAP request body object `agenticPaymentContainer` that carries payment data from the agent to the merchant. Besides `nonce`, `kid`, `alg` and `signature`, it can hold a credential hash for key-entered cards, `cardMetadata`, an encrypted `payload` for API checkout, or a `browsingIOU` that answers an HTTP 402 request for paid content. The spec defines no canonical form for the signed body, and no test vector exists. ^{Source [19]}

STE

The payment container gives payment data from the agent to the merchant. The agent signs the container with the same key as the message signature.

Protocols:Visa TAP

Payment credential hash

Also: paymentCredentialsHash, credentialHash

Plain

A TAP field that hashes the card number, expiry month and year and security code so a merchant can check key-entered card data. The specification names no algorithm or salt. ^{Source [19]}

STE

A hash of the card data. The merchant compares it with a hash of the card data that the agent types.

Protocols:Visa TAP

Payment flow

Also: paymentFlow, extra.paymentFlow, authorization flow, upfront

Plain

The x402 V2 setting that fixes the order of verify, resource execution and settlement. `authorization` (the default) verifies, runs the resource, then settles. `upfront` settles before the resource runs, and `escrow` settles a deposit first and a final charge after. Servers declare a non-default flow in `extra.paymentFlow`. ^{Source [36]}

STE

The payment flow sets the order of verification, work and settlement. The default flow is authorization.

Protocols:x402

Payment handler

Also: payment_handlers, PaymentHandler, handler_id

Plain

A specification for how a buyer's payment credential is obtained and passed to the merchant, such as Google Pay (`com.google.pay`) or Shop Pay in UCP, or `dev.acp.tokenized.card` in ACP. The merchant advertises the handlers it accepts, the agent runs the chosen handler with the credential provider, and the result goes back as an instrument tied to a `handler_id`. UCP itself defines the structure but no concrete handler. ^{Source [14, 148]}

STE

A payment handler is a specification that tells how the agent gets a payment credential for the business. The business shows the handlers that it accepts.

Protocols:OpenAI ACPUCP

Payment Instruction

Also: purchase instruction

Plain

In Visa Intelligent Commerce, the user's instruction to an agent, authenticated with a passkey, against which VIC releases payment credentials. Visa's client creates it with POST /vacp/v1/instructions. ^{Source [147, 149]}

STE

An instruction from the consumer to the agent. The consumer approves it with a passkey.

Protocols:Visa TAP

Payment Mandate

Also: mandate.payment.1, payment_mandate, PaymentMandate

Plain

The AP2 v0.2 mandate that approves one payment. A closed Payment Mandate (`vct` `mandate.payment.1`) names the `transaction_id` (a hash of the checkout), the `payee`, the `payment_amount` in minor units and the `payment_instrument`. The credential provider checks it before it releases a payment credential, and the network can see it as evidence of user intent. ^{Source [150, 151]}

STE

A Payment Mandate is the AP2 mandate for one payment. It gives the payee, the amount and the payment instrument.

Protocols:AP2

Payment method (MPP)

Also: method id, MPP method

Plain

A rail-specific MPP specification, named by a lowercase id such as tempo, stripe or card, that defines the request and payload fields and how to verify and settle. ^{Source [10, 152]}

STE

A specification for one payment rail. It tells the client how to pay and the server how to verify.

Protocols:Stripe MPP

Payment passkey

Also: Visa Payment Passkey, Mastercard Payment Passkey

Plain

A passkey that a card network uses to authenticate the cardholder for a payment. In Visa Intelligent Commerce, the agent sets up a passkey during card enrollment and later uses it to authenticate the user's Payment Instructions, and Visa says every Agentic Ready transaction in Europe used Visa Payment Passkeys. Mastercard names Mastercard Payment Passkeys in its regional Agent Pay launches. ^{Source [147, 153, 154]}

STE

A payment passkey is a passkey that authenticates the cardholder for a payment. Visa and Mastercard use payment passkeys for purchases by agents.

Protocols:Visa TAPMastercard Agent Pay

Payment payload

Also: PaymentPayload, PAYMENT-SIGNATURE, X-PAYMENT

Plain

The signed payment a client sends back after it picks one of the offered payment requirements. A V2 `PaymentPayload` holds `x402Version`, the chosen requirements in `accepted`, and a scheme-specific `payload` with the signature. Over HTTP it travels base64 encoded in the `PAYMENT-SIGNATURE` header (V1 used `X-PAYMENT`). ^{Source [36, 102, 155]}

STE

The payment payload contains the signed payment of the client. The client sends the payload in the PAYMENT-SIGNATURE header with the second request.

Protocols:x402

Payment requirements

Also: PaymentRequirements, accepts, PAYMENT-REQUIRED, PaymentRequired

Plain

The terms a resource server will accept for one paid resource in x402. Each entry of the `accepts` array is a `PaymentRequirements` object with `scheme`, `network`, `amount`, `asset`, `payTo` and `maxTimeoutSeconds`, plus an optional `extra` object. In V2 the server sends the full `PaymentRequired` object, base64 encoded, in the `PAYMENT-REQUIRED` header of a 402 response. ^{Source [36, 102]}

STE

Payment requirements tell the client the price, the token, the network and the recipient of a payment. The server sends them in a 402 response.

Protocols:x402

Payment-Authorization

Also: Payment-Authorization header, header parameter

Plain

An HTTP request header that carries an MPP credential when the challenge asked for it, so the Authorization header can keep a bearer token. ^{Source [10, 156]}

STE

A header that holds the payment credential. The server asks for it when Authorization holds a different token.

Protocols:Stripe MPP

payment-identifier extension

Also: payment id

Plain

An x402 extension that gives a payment a client-chosen id so servers can deduplicate retries; a server answers 409 when the same id arrives with a different payload. ^{Source [157]}

STE

An extension that gives each payment an identifier, so that the server can find a repeated request.

Protocols:x402

Payment-Receipt

Also: Payment-Receipt header, MPP receipt

Plain

The MPP response header that proves a payment settled. It holds a base64url object with `status` (always `success`), `method`, `timestamp` and a method-specific `reference`, such as a Tempo transaction hash or a Stripe PaymentIntent id. Servers send it only with a 2xx response; x402 uses its own `PAYMENT-RESPONSE` header for the same job. ^{Source [10]}

STE

Payment-Receipt is the MPP header that tells the client about a successful payment. The server sends it only with a successful response.

Protocols:Stripe MPP

Permit2

Also: permitWitnessTransferFrom, x402ExactPermit2Proxy, x402UptoPermit2Proxy

Plain

A Uniswap contract that adds signature-based approvals and transfers to any ERC-20 token, including tokens without EIP-3009. The holder approves Permit2 once, then signs transfers that can carry a witness with extra data. x402 uses Permit2 as an alternative `exact` method and as the only method of `upto` on EVM, through proxies at fixed addresses. ^{Source [76, 158, 159]}

STE

Permit2 is a Uniswap contract that lets a token holder sign a transfer for any ERC-20 token. The holder must approve Permit2 one time first.

Protocols:x402

PISP

Also: Payment Initiation Service Provider

Plain

A European open-banking provider that starts payments from a bank account. AP2 can name or restrict PISPs in Payment Mandates. ^{Source [160]}

STE

A provider that starts a payment from a bank account.

Protocols:AP2

Platform profile

Also: agent profile

Plain

The profile a UCP platform publishes at a URL of its choice and names in the UCP-Agent header; it lists the platform's capabilities, keys and settings such as an order webhook URL. ^{Source [14]}

STE

The JSON document of the platform. The platform sends its address in the UCP-Agent header.

Protocols:UCP

Preimage

Also: payment preimage

Plain

The secret value whose SHA-256 hash is the payment hash in a Lightning invoice. It is released to the payer only when the payment completes, so presenting it proves that the invoice was paid. In x402 `lnbtc`, the facilitator checks that the hash of the preimage equals the invoice's payment hash and records the hash so it cannot be replayed. ^{Source [98, 118]}

STE

A preimage is the secret value that gives the payment hash of a Lightning invoice. The preimage proves that the payer paid the invoice.

Protocols:x402Stripe MPP

Problem details (RFC 9457)

Also: RFC 9457, application/problem+json, problem type

Plain

An IETF format for machine-readable HTTP error bodies, served as `application/problem+json` with fields such as `type`, `title`, `status` and `detail`. MPP uses it for its error types under `https://paymentauth.org/problems/`, for example `payment-expired`, `invalid-challenge` and `verification-failed`. RFC 9457 replaced RFC 7807 in 2023. ^{Source [10, 161]}

STE

Problem details is an IETF format for HTTP error messages in JSON. MPP uses this format to tell the client why a payment failed.

Protocols:Stripe MPP

Prompt injection

Also: indirect prompt injection, LLM01

Plain

An attack in which text the model reads, such as a product page or a tool result, contains instructions that change what the agent does. In commerce it can push an agent to pick a different merchant or pay a different amount. A 2026 red-team study of AP2 used it, and AP2 answers with deterministic verification of signed mandates outside the model. ^{Source [55, 162, 163]}

STE

Prompt injection is an attack that puts instructions into the text that an AI model reads. The instructions can make an agent do an unsafe payment.

Protocols:AP2

proofOfPayment

Also: proof of payment

Plain

An optional object in an ERC-8004 feedback file with fromAddress, toAddress, chainId and txHash. It points to a payment such as an x402 settlement; the registry never stores or checks it. ^{Source [1]}

STE

An object in the feedback file that identifies a payment transaction.

Protocols:ERC-8004

PSD3

Also: Third Payment Services Directive

Plain

The proposed third EU Payment Services Directive, which would replace PSD2 for the licensing and supervision of payment institutions. The Parliament and Council reached a provisional agreement on 2025-11-27, but no Official Journal publication was found by 2026-10-11. The texts contain no provisions specific to AI agents. ^{Source [164, 165, 166]}

STE

PSD3 is the proposed EU directive for payment services. It will replace PSD2, but the EU did not publish the final text before 2026-10-11.

PSR

Also: Payment Services Regulation, EU Payment Services Regulation

Plain

The proposed EU Payment Services Regulation, agreed together with PSD3, which would put conduct rules such as strong customer authentication, fraud liability and payer protection into a directly applicable regulation. It was not in the Official Journal on 2026-10-11 and is expected to apply some time after publication. In the UK, the similar abbreviation PSRs refers to the Payment Services Regulations 2017, a separate law. ^{Source [164, 165, 167]}

STE

The PSR is the proposed EU regulation for the rules of payment services. The PSR and PSD3 are parts of the same EU package.

Registration file

Also: agent registration file, agent-registration.json, registration-v1

Plain

The JSON document an ERC-8004 `agentURI` resolves to. It carries `type`, `name`, `description`, `image`, a `services` list of endpoints (for example A2A, MCP, web or DID), `x402Support`, `active`, a `registrations` list that binds the file to on-chain identities, and optional `supportedTrust` values. The spec publishes an example structure but no JSON Schema. ^{Source [1, 168]}

STE

The registration file describes an agent and its service endpoints. The file also contains the on-chain identities of the agent.

Protocols:ERC-8004

Regulation E

Also: Reg E, 12 CFR 1005, Electronic Fund Transfer Act

Plain

The US rule (12 CFR Part 1005) that implements the Electronic Fund Transfer Act and limits consumer liability for unauthorized debit and other electronic transfers. Under 1005.2(m), a transfer made by someone to whom the consumer gave the access device is not unauthorized until the consumer tells the bank that person may no longer use it. That clause is the central open question for credentials delegated to agents. ^{Source [169]}

STE

Regulation E is the US rule for electronic fund transfers from consumer accounts. It tells when a transfer is unauthorized and who pays for the loss.

Regulation Z

Also: Reg Z, 12 CFR 1026, Truth in Lending

Plain

The US rule (12 CFR Part 1026) that implements the Truth in Lending Act, including credit card protections. Section 1026.12(b) caps a cardholder's liability for unauthorized use at 50 dollars and treats use by someone with actual, implied or apparent authority as authorized. How that authority test applies to an AI agent is not settled. ^{Source [170]}

STE

Regulation Z is the US rule for consumer credit and credit cards. It sets a maximum liability of 50 dollars for unauthorized use of a credit card.

Replay attack

Also: replay protection

Plain

An attack in which a valid signed message or payment proof is captured and sent again to get the same effect twice. Protocols defend with single-use nonces, short validity windows and idempotency keys: TAP limits signatures to 8 minutes and requires a nonce, MPP challenges are single use, and x402 Lightning payments record each payment hash. RFC 9421 itself leaves replay protection to the application. ^{Source [10, 19, 64, 98]}

STE

In a replay attack, an attacker sends a valid signed message again. Nonces, short time limits and single-use challenges stop replay attacks.

Protocols:x402Visa TAPStripe MPP

Reputation Registry

Also: ReputationRegistry, giveFeedback, getSummary

Plain

The ERC-8004 contract where any address except the agent's owner and operators can record feedback about an agent. Each entry stores a signed `value` with `valueDecimals` and two optional tags, and it can be revoked by its author or answered with `appendResponse`. `getSummary` averages entries only for a list of client addresses that the caller supplies, which is the spec's defense against fake reviewers. ^{Source [1, 171]}

STE

The Reputation Registry keeps feedback about agents. The owner of an agent cannot give feedback to that agent.

Protocols:ERC-8004

Reputation system

Plain

A system that collects ratings or outcomes about a party and turns them into a signal others can use to decide whether to trust it. ERC-8004 provides only the raw on-chain feedback records and a plain average over chosen reviewers, and leaves scoring to off-chain aggregators. Feedback values in ERC-8004 depend on their tags, so they are not directly comparable. ^{Source [1, 171, 172]}

STE

A reputation system collects feedback about a party and gives a signal of trust. ERC-8004 keeps the feedback, and other services calculate the scores.

Protocols:ERC-8004

Resource server

Also: seller server

Plain

The HTTP server that sells a resource in x402. It answers unpaid requests with 402 and the price, asks a facilitator to verify and settle, and serves the response. ^{Source [36, 173]}

STE

The HTTP server that sells a resource. It sends the price, asks the facilitator to verify the payment, and sends the resource.

Protocols:x402

RFC 9421

Also: HTTP Message Signatures, Signature-Input

Plain

The IETF standard (February 2024) for signing parts of an HTTP message. The signer lists what it covers and its parameters in `Signature-Input` and puts the result in `Signature`, both as structured-field dictionaries. Visa TAP, Mastercard Agent Pay, Web Bot Auth and the `cloudflare:402` x402 variant all build agent identity on it. ^{Source [19, 22, 64]}

STE

RFC 9421 is the IETF standard for signatures on HTTP messages. Visa TAP and Mastercard Agent Pay use it to identify agents.

Protocols:x402Visa TAPMastercard Agent Pay

Scheme

Also: x402 scheme

Plain

In x402, a scheme is a named rule set for how money moves, such as `exact`, `upto`, `batch-settlement` or `auth-capture`. The `scheme` field in each payment requirement picks one, and a separate per-network document says how that scheme works on EVM, Solana, Lightning or another network. Schemes keep the core protocol independent of any single chain. ^{Source [36, 86]}

STE

In x402, a scheme is a set of rules for the transfer of money. Each scheme has one specification for each supported network.

Protocols:x402

sd_hash

Plain

Hash in a key-binding JWT over the SD-JWT it extends. In AP2 it binds an agent-signed closed mandate to its user-signed open parent. ^{Source [56, 112]}

STE

A hash that links the closed mandate to the open mandate.

Protocols:AP2

SD-JWT

Also: Selective Disclosure JWT, SD-JWT VC, dc+sd-jwt, RFC 9901

Plain

Selective Disclosure for JSON Web Tokens, published as RFC 9901: a signed token in which the holder can reveal only some claims and keep the rest hidden. AP2 v0.2 mandates and Mastercard's Verifiable Intent credentials are SD-JWTs, chained with the Delegate SD-JWT draft. A key binding JWT can prove that the presenter holds the key named in the token. ^{Source [32, 66, 112]}

STE

SD-JWT is a signed token that lets the holder show only some of its claims. AP2 and Verifiable Intent use SD-JWT for their credentials.

Protocols:UCPAP2Mastercard Agent Pay

Security-locked session

Also: security lock

Plain

A UCP checkout session in which the AP2 extension was negotiated, so the business must sign every checkout and neither side may fall back to an unprotected checkout. ^{Source [52]}

STE

A session that uses AP2 mandates. The session cannot change back to a checkout without mandates.

Protocols:UCP

Seller-backed payment handler

Also: seller-backed handler

Plain

An ACP payment handler for value the merchant holds, such as a saved card, gift card, points or store credit, so no card moves to the agent. ^{Source [174]}

STE

A payment method that the merchant keeps, for example a gift card or points.

Protocols:OpenAI ACP

Server Enabler

Also: acquirer (card method)

Plain

In the MPP card method, the PSP or acquirer that decrypts the token for the merchant server and requests authorization from the card network. ^{Source [54]}

STE

The payment provider that decrypts the card token and asks the card network for approval.

Protocols:Stripe MPP

Session

Also: session intent, Tempo session

Plain

The MPP intent for metered use, such as paying per model token. The client deposits into an on-chain escrow channel, then sends signed vouchers with a rising `cumulativeAmount` as it consumes the service, and the server settles on-chain when it chooses. The session draft is experimental and defined for the Tempo method in `mpp-specs`. ^{Source [63]}

STE

Session is the MPP intent for a payment that increases with use. The client sends signed vouchers while it uses the service.

Protocols:Stripe MPP

settlement_pending

Also: pending settlement

Plain

A non-terminal x402 settle result: the transaction was broadcast but its confirmation could not be established. It carries the transaction hash so the server can check the chain before it retries. ^{Source [36, 88]}

STE

A settle result. The transaction went to the network, but the facilitator did not get the receipt.

Protocols:x402

Shared Payment Token

Also: SPT, spt_, shared_payment_granted_token

Plain

A Stripe payment primitive that lets an agent share a buyer's saved payment method with one seller without exposing card details. The agent issues an SPT with `usage_limits` (`currency`, `max_amount`, `expires_at`), and the seller confirms a PaymentIntent with it. It is Stripe's implementation of ACP delegated payment and also the credential of the `stripe` method in MPP, but it is not part of either spec. ^{Source [23, 38]}

STE

A Shared Payment Token (SPT) is a Stripe token that gives one seller limited use of a payment method. The seller does not see the card details.

Protocols:OpenAI ACPStripe MPP

Shopping Agent

Also: SA

Plain

The AP2 role that finds products, builds the checkout and presents mandates. The specification expects it to be agentic and treats it as a potential attacker. ^{Source [55]}

STE

The agent that buys for the user and presents mandates.

Protocols:AP2

Sign-In-With-X

Also: SIWX, CAIP-122, sign-in-with-x, SIGN-IN-WITH-X

Plain

A chain-agnostic way for a wallet to prove it controls an account by signing a structured message, defined in CAIP-122. x402 has a `sign-in-with-x` extension: the server sends `domain`, `uri`, `nonce`, `issuedAt` and related fields, and the client returns a signed `SIGN-IN-WITH-X` header. It proves who the payer is, which lets a server recognize a returning client. ^{Source [82, 175]}

STE

Sign-In-With-X lets a wallet prove control of an account with a signed message. x402 uses it in an optional extension.

Protocols:x402

Signature base

Also: @signature-params

Plain

The exact text that RFC 9421 signs: one line per covered component, written as the quoted component name, a colon and its value, followed by a final `@signature-params` line. Signer and verifier must build it byte for byte the same, or the check fails. The Visa TAP spec's own code sample formats some lines differently from RFC 9421. ^{Source [19, 64]}

STE

In RFC 9421, the signature base is the exact text that the signer signs. The verifier must make the same text to verify the signature.

Protocols:Visa TAPMastercard Agent Pay

Signature-Agent

Also: Signature-Agent header, signature-agent

Plain

An HTTP request header that points to the signer's key directory, so a verifier can fetch the public key. The Web Bot Auth draft requires it and requires the signature to cover it, and the `cloudflare:402` x402 variant does the same. Visa TAP does not require it, and Mastercard shows it in an example request. ^{Source [22, 34, 113]}

STE

The Signature-Agent header gives the address of the key directory of the signer. The verifier gets the public key from this directory.

Protocols:x402Visa TAPMastercard Agent Pay

Site Protection Provider

Plain

In TAP, the layer in front of a merchant site, such as a CDN, trust management system or proxy, that can verify agent signatures for the merchant. ^{Source [19]}

STE

A CDN or proxy in front of the merchant site. It can verify the signatures for the merchant.

Protocols:Visa TAP

Specification Enhancement Proposal

Also: SEP

Plain

The ACP change process for major changes: a TSC sponsor, a 7-business-day public review and a simple majority vote. ^{Source [176]}

STE

A formal request to change the ACP specification.

Protocols:OpenAI ACP

spendControls

Also: spend controls, spending cap

Plain

Client-side limits in the x402 TypeScript SDK: by default only known assets and at most $1 per payment. Passing false disables them. They are an SDK feature, not part of the protocol. ^{Source [177, 178]}

STE

Limits in the client software. They stop a payment above a set amount or in an unknown asset.

Protocols:x402

Split-agent attack

Plain

An attack in which the checkout and payment mandates of one Verifiable Intent pair bind different agent keys; prevented by requiring an identical cnf.jwk in both. ^{Source [67]}

STE

An attack where two mandates in one pair have different agent keys.

Protocols:Mastercard Agent Pay

srcDpaId

Also: DPA identifier

Plain

A Mastercard-generated merchant identifier used in Intent API orders; merchants reject a checkout when it does not match their own. ^{Source [16]}

STE

An identifier that Mastercard gives to a merchant. The merchant compares it with the identifier in the intent.

Protocols:Mastercard Agent Pay

Stablecoin

Also: payment stablecoin, stablecoins

Plain

A blockchain token designed to keep a fixed value against a currency, usually the US dollar, backed by reserves. x402 most often settles in USDC, Tempo charges its fees in USD stablecoins, and Mastercard's Agent Pay for Machines names stablecoins among its settlement rails. In the US the GENIUS Act regulates payment stablecoins, and in the EU MiCA covers them. ^{Source [17, 99, 179, 180, 181]}

STE

A stablecoin is a token that keeps a fixed value against a currency, for example the US dollar. x402 and MPP can settle payments in stablecoins.

Protocols:x402Stripe MPPMastercard Agent Pay

Strong customer authentication

Also: SCA, dynamic linking

Plain

The EU requirement, from PSD2 and its technical standard Delegated Regulation 2018/389, that most electronic payments authenticate the payer with two of three factors: knowledge, possession and inherence. For remote payments the authentication code must also be dynamically linked to the amount and payee. Visa says its European agent transactions used payment passkeys to support SCA, which sits in VIC rather than in TAP. ^{Source [153, 166, 182]}

STE

Strong customer authentication (SCA) is an EU rule for payments. The payer must show two of three factors: knowledge, possession and inherence.

Protocols:Visa TAPMastercard Agent Pay

Subscription

Also: subscription intent, subscriptionId

Plain

The MPP intent for a recurring payment of a fixed `amount` every `periodCount` `periodUnit` (day, week or month). The server collects the first period on activation, returns a `subscriptionId` in the receipt and may collect one renewal per period. Missed periods never add up to extra charges. ^{Source [183]}

STE

Subscription is the MPP intent for a payment that occurs one time in each period. The server can collect only one payment in each period.

Protocols:Stripe MPP

supportedTrust

Plain

An optional list in the registration file naming the trust models an agent supports, such as reputation, crypto-economic or tee-attestation. Empty means discovery only. ^{Source [1]}

STE

A list of trust models that an agent supports.

Protocols:ERC-8004

Sybil attack

Also: Sybil, fake reviewers

Plain

An attack in which one party creates many fake identities to gain influence, named in Douceur's 2002 paper. The ERC-8004 spec says Sybil feedback is possible and expects readers to filter by trusted reviewers, which is why `getSummary` requires a list of client addresses. A 2026 empirical study found coordinated Sybil behavior among most ERC-8004 reviewers on the chains it measured. ^{Source [1, 184, 185]}

STE

In a Sybil attack, one party makes many false identities. In ERC-8004, false identities can give false feedback to agents.

Protocols:ERC-8004

Tag

Also: agent-browser-auth, agent-payer-auth, web-bot-auth

Plain

The RFC 9421 signature parameter that states what the signature is for. Visa TAP uses `agent-browser-auth` for browsing and `agent-payer-auth` for checkout and payment, Mastercard Agent Pay documents `Agent-pay-auth`, and the Web Bot Auth draft requires `web-bot-auth`. A verifier rejects a signature with a tag it does not expect. ^{Source [19, 22, 113]}

STE

The tag parameter tells the purpose of a signature. Visa TAP has one tag for visits to product pages and one tag for payment.

Protocols:Visa TAPMastercard Agent Pay

TEE attestation

Also: trusted execution environment, tee-attestation

Plain

A signed statement from a trusted execution environment (secure hardware) that a specific piece of code ran inside it. ERC-8004 lists `tee-attestation` as a `supportedTrust` value and names TEE attestation as a validator method, and its contracts README says validation is still under discussion with the TEE community. No TEE attestation format is specified in the ERC. ^{Source [1, 186]}

STE

A TEE attestation is a signed statement that specified code ran in secure hardware. ERC-8004 names TEE attestation as one method of trust.

Protocols:ERC-8004

Tempo

Also: Tempo blockchain, Tempo mainnet

Plain

A payments blockchain from Tempo Labs, whose team wrote MPP together with Stripe. It has no native gas token: fees are paid in USD TIP-20 stablecoins. Its mainnet chain id is 4217, blocks arrive about every 600 ms, and Simplex BFT consensus gives deterministic finality. ^{Source [97, 152, 181, 187]}

STE

Tempo is a blockchain for payments. On Tempo, the fees are in stablecoins, and the chain has deterministic finality.

Protocols:Stripe MPP

TIP-20

Also: TIP-20 token

Plain

The token standard of the Tempo blockchain, built for stablecoins. TIP-20 tokens use 6 decimals, can carry a transfer memo, and can point to a TIP-403 policy registry for allow and block lists. MPP's `tempo` method names the token by its TIP-20 address in `currency`. ^{Source [89, 188]}

STE

TIP-20 is the token standard of the Tempo blockchain. TIP-20 tokens have 6 decimals and can have a memo with each transfer.

Protocols:Stripe MPP

TIP-20 channel reserve

Also: session v2, TIP-1034

Plain

The Tempo precompile that holds session deposits in MPP session protocol v2, replacing the v1 escrow contract. ^{Source [63, 189]}

STE

The built-in Tempo function that holds the deposit for a session, version 2.

Protocols:Stripe MPP

transaction_id (AP2)

Plain

Field of the closed Payment Mandate holding the hash of checkout_jwt, the same value as checkout_hash, so the payment binds to one checkout. ^{Source [150]}

STE

The hash of the signed checkout in the Payment Mandate.

Protocols:AP2

Transport binding

Also: UCP service binding

Plain

A UCP service entry that pairs a transport (rest, mcp, a2a or embedded) with an endpoint and a machine-readable description such as OpenAPI or OpenRPC. ^{Source [14, 39]}

STE

An entry in the profile. It connects a transport to an endpoint.

Protocols:UCP

Trusted agent list

Also: trusted agent lists

Plain

The network-maintained list of agents that passed Mastercard's security review and certification; merchants rely on it through signature verification. ^{Source [114]}

STE

The list of agents that passed the Mastercard examination.

Protocols:Mastercard Agent Pay

Trusted Agent Protocol

Also: Visa TAP, TAP

Plain

Visa's specification for AI agents to sign their web requests to merchants with RFC 9421, tagged for browsing or paying, with optional signed consumer and payment objects. It identifies agents and moves no money. ^{Source [19, 190]}

STE

A Visa specification. An AI agent uses it to sign requests to a merchant. It does not move money.

Protocols:Visa TAP

Trusted Agent Provider

Plain

AP2 delegation model in which the agent provider signs mandates with a key the agent cannot use without the Trusted Surface. Not Visa TAP. ^{Source [56]}

STE

A model where the provider of the agent signs the mandates.

Protocols:AP2

Trusted reviewer list

Also: clientAddresses filter

Plain

The list of client addresses a reader passes to getSummary. ERC-8004 requires it because unfiltered feedback is open to Sybil attacks. ^{Source [1, 171]}

STE

The list of reviewers that a reader trusts.

Protocols:ERC-8004

Trusted Surface

Plain

In AP2 v0.2, the user interface that shows the user what they approve and collects consent before a user-signed mandate is created. It must be non-agentic: deterministic code such as part of the agent app, a wallet or issuer app, or a browser or mobile platform. It can also collect risk signals that go into `risk_data`. ^{Source [55, 191]}

STE

A Trusted Surface is the user interface that gets the consent of the user for a mandate. A Trusted Surface must not be an agent.

Protocols:AP2

UCP-Agent header

Also: UCP-Agent, ucp-agent

Plain

The HTTP request header in which a UCP platform names the URL of its own profile, written as `UCP-Agent: profile="..."` in structured-field dictionary syntax. The business fetches that profile, checks the version and computes the shared set of capabilities. Over MCP the same value goes in `meta["ucp-agent"].profile`. ^{Source [14, 105]}

STE

The UCP-Agent header tells the business the address of the profile of the platform. The business reads that profile and finds the shared capabilities.

Protocols:UCP

unresolved_constraint

Plain

AP2 error returned when a mandate holds an unknown constraint or conformance cannot be confirmed; it may signal a fallback to user approval. ^{Source [56]}

STE

An error that tells the agent to get the approval of the user.

Protocols:AP2

Upto scheme

Also: upto

Plain

An x402 scheme for metered work where the final price is not known in advance. The client signs a Permit2 authorization for a ceiling amount, and at settlement the server charges the actual amount, which must not exceed that ceiling. A zero charge needs no on-chain transaction. ^{Source [159]}

STE

The upto scheme lets the server charge an amount up to a maximum. The client signs the maximum, and the server charges the actual cost after the work.

Protocols:x402

USDC

Also: USD Coin

Plain

A US dollar stablecoin issued by Circle, which Circle describes as fully reserved and redeemable 1:1 for dollars. Its EVM contracts implement EIP-3009 `transferWithAuthorization`, which is why it is the default token of the x402 `exact` scheme, for example on Base. MPP has a separate `usdc` payment method drafted by Circle. ^{Source [179, 180, 192]}

STE

USDC is a US dollar stablecoin from Circle. USDC supports EIP-3009, so x402 uses USDC by default on EVM networks.

Protocols:x402Stripe MPP

User Credential model

Plain

AP2 delegation model in which a credential issued to the user signs mandates, typically through OpenID4VP, and verifiers trust the issuer. ^{Source [56]}

STE

A model where a credential of the user signs the mandates.

Protocols:AP2

UUPS proxy

Also: UUPS, ERC-1822, upgradeable proxy, _authorizeUpgrade

Plain

A Universal Upgradeable Proxy Standard contract keeps its state at a fixed address while the logic contract behind it can be replaced. In UUPS the upgrade function lives in the logic contract, so whoever passes `_authorizeUpgrade` can change the code. The deployed ERC-8004 registries are UUPS proxies with upgrade rights restricted to one owner address. ^{Source [25, 193]}

STE

A UUPS proxy is a contract that keeps its address and data when its code changes. The owner of the proxy can replace the code.

Protocols:ERC-8004

Validation Registry

Plain

The third ERC-8004 registry, where a named validator records a 0 to 100 check of an agent's work. Specified in the Draft text, not officially deployed. ^{Source [1, 186]}

STE

A registry where a validator writes the result of a check. It is not officially on a chain.

Protocols:ERC-8004

Validation request

Also: validationRequest, validationResponse, requestHash, Validation Registry

Plain

A call to the ERC-8004 Validation Registry in which an agent's owner asks a named validator to check a piece of work. The request carries a `requestURI` and a `requestHash`, and only that validator can answer with `validationResponse` and a score from 0 to 100. The Validation Registry is specified, but the contracts README lists no official deployment. ^{Source [1, 186]}

STE

A validation request asks one validator to check the work of an agent. The validator gives a score from 0 to 100.

Protocols:ERC-8004

valueDecimals

Plain

The number of decimal places (0 to 18) that applies to an ERC-8004 feedback value. An uptime of 99.77% is value 9977 with valueDecimals 2. ^{Source [1]}

STE

The number of decimal places of a feedback value.

Protocols:ERC-8004

Vault token

Also: vt_, DelegatePaymentResponse

Plain

The token returned by an ACP Delegate Payment call, shown with a `vt_` prefix in the spec examples. It stands for the stored card and can be used only by the named merchant, for the named checkout session, within the allowance. The agent passes it to the merchant in `payment_data.instrument.credential.token` when it completes checkout. ^{Source [26, 68]}

STE

A vault token is the token that the payment provider returns after delegated payment. The merchant can use the token only within the allowance.

Protocols:OpenAI ACP

vct

Also: Verifiable Credential Type

Plain

SD-JWT VC claim naming the credential type. AP2 uses it for the mandate type and schema version, for example mandate.payment.1. ^{Source [150]}

STE

The claim that gives the mandate type and version.

Protocols:AP2

Verifiable credential

Also: verifiable digital credential, VDC

Plain

A tamper-evident digital claim that an issuer makes about a subject, which anyone can check with the issuer's public key. The W3C Verifiable Credentials Data Model 2.0 is one format, and SD-JWT VC is another; AP2 mandates are issued as SD-JWT credentials. Do not confuse it with an MPP credential, which is a payment proof in an HTTP header. ^{Source [55, 194]}

STE

A verifiable credential is a signed claim that an issuer makes about a subject. A verifier can check the claim with the public key of the issuer.

Protocols:AP2Mastercard Agent Pay

Verifiable Intent

Also: VI, verifiable-intent

Plain

An open specification from Mastercard (version 0.1-draft, 2026-02-18) for proving what a user authorized an agent to buy, as a chain of SD-JWT credentials. An issuer signs layer 1 about the user's card and key, the user signs layer 2 with a mandate, and in autonomous mode the agent signs layer 3 payment and checkout credentials for the network and the merchant. Its mandate names mirror AP2 v0.2, and Mastercard says it will embed VI in Agent Pay's intent APIs. ^{Source [31, 32, 195]}

STE

Verifiable Intent is a Mastercard specification that proves the purchases that a user lets an agent make. It uses a chain of SD-JWT credentials.

Protocols:AP2Mastercard Agent Pay

Visa Intelligent Commerce

Also: VIC

Plain

Visa's program and API set for agent commerce, announced on 2025-04-30. It covers agent-specific tokens, cardholder step-up verification and passkey setup, Payment Instructions that bind credential requests to what the user approved, and commerce signals sent back to Visa. Visa presents Trusted Agent Protocol as an enhancement to VIC. ^{Source [147, 196, 197]}

STE

Visa Intelligent Commerce (VIC) is the Visa program for payments by AI agents. VIC gives tokens, passkeys and payment instructions to agents.

Protocols:Visa TAP

Visa Token Service

Also: VTS

Plain

Visa's network tokenization service, which replaces a card number with a token for wallets, merchants and other token requestors. The VIC overview lists VTS APIs among the services that Visa's MCP server reaches. Visa sources for TAP talk about VTS and VIC tokens, not MDES, which is Mastercard's equivalent. ^{Source [147, 198]}

STE

Visa Token Service (VTS) is the Visa service that replaces a card number with a token. The Visa MCP server gives access to VTS APIs.

Protocols:Visa TAP

Voucher

Also: cumulative voucher, cumulativeAmount, maxClaimableAmount

Plain

A signed off-chain message that raises the total a payee may claim from a payment channel. MPP Tempo sessions send vouchers with a rising `cumulativeAmount`, and the x402 `batch-settlement` scheme uses vouchers with `maxClaimableAmount`. Vouchers cost no fees, and only the latest one matters when the channel settles. ^{Source [33, 63]}

STE

A voucher is a signed message that increases the total amount that the payee can claim. The client sends vouchers off the chain, so they cost no fee.

Protocols:x402Stripe MPP

Web Bot Auth

Also: webbotauth, draft-ietf-webbotauth-httpsig-protocol

Plain

An IETF working group and its draft (`draft-ietf-webbotauth-httpsig-protocol-00`, posted 2026-09-01) for automated clients that sign their requests with RFC 9421 and publish keys in a directory. It requires the `web-bot-auth` tag and a covered `Signature-Agent` header. Visa TAP predates the draft and does not conform to it, though Cloudflare describes both card networks' schemes as built on Web Bot Auth. ^{Source [113, 199]}

STE

Web Bot Auth is an IETF draft for bots that sign HTTP requests with RFC 9421. The bot publishes its public keys in a directory.

Protocols:Visa TAPMastercard Agent Pay

WWW-Authenticate

Also: WWW-Authenticate: Payment, Payment scheme

Plain

The standard HTTP response header that tells a client how to authenticate. MPP defines a new authentication scheme called `Payment`, so a 402 response carries one or more `WWW-Authenticate: Payment` challenges with `id`, `realm`, `method`, `intent` and `request` parameters. On 2026-10-11 the `Payment` scheme was requested in an Internet-Draft but not yet in the IANA registry. ^{Source [10, 200]}

STE

WWW-Authenticate is the HTTP header that tells the client how to authenticate. In MPP, this header contains the payment challenge.

Protocols:Stripe MPP

x402Version

Also: protocol version field

Plain

The field in every x402 message that names the protocol version: 1 for the legacy wire format, 2 for the current one. ^{Source [36, 201]}

STE

A field that gives the protocol version. The value 2 is the current version.

Protocols:x402

zkML

Also: zero-knowledge machine learning

Plain

Zero-knowledge machine learning: a proof that a given model produced a given output, which can be checked without rerunning the model. The ERC-8004 spec names zkML proofs as one possible method for validators in its Validation Registry. The spec does not define a zkML format, and the registry has no official deployment. ^{Source [1]}

STE

zkML is a proof that a model gave a specified output. ERC-8004 names zkML as one possible method for validators.

Protocols:ERC-8004