Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against

"Agent payments" is not one problem: it is proving an agent was allowed to spend (authorization) plus actually moving the money (settlement). Every protocol page in this wiki sits at one layer, the other, or both — knowing which is the first filter for reading any claim about it.

Why "Agent Payments" Splits Into Two Distinct Problems

Authorization is the verification and approval of a transaction request, typically completed within seconds; it returns an approval or denial code to the merchant without moving funds. Settlement is the actual transfer of funds — from issuing bank through payment processors to merchant accounts — typically spanning one to three business days depending on payment method and jurisdiction (https://www.spreedly.com/blog/payment-authorization-vs-settlement). For card networks, authorization reserves funds through a temporary hold and prevents fraud, while settlement finalizes the transaction by moving actual funds through clearing (https://www.circle.com/blog/settlement-vs-clearing-the-hidden-plumbing-of-payments).

For agentic payments specifically, this maps onto a three-layer framework from the IMF: an Intent/Orchestration layer, an Authorization layer proving decisions are validated and approved, and a Settlement layer for transaction finality (https://www.imf.org/en/publications/imf-notes/issues/2026/04/22/how-agentic-ai-will-reshape-payments-575560). In agent terms: authorization proves the agent was allowed to spend (mandate verification); settlement moves the actual money through an underlying rail (card network, stablecoin network, or bank transfer). This wiki's companion, the agent-economy wiki, already covers the settlement rail side (x402/HTTP-402); this wiki fills the authorization/mandate layer above it.

Liability follows the layer

authorization risk centers on the merchant's payment system; settlement risk transfers to banks and payment processors handling chargebacks and disputes (https://www.spreedly.com/blog/payment-authorization-vs-settlement). This split matters directly for Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki: which layer failed determines who is plausibly on the hook.

The Generic Anatomy of a Mandate

A mandate is a cryptographically signed authorization object. Across the protocols surveyed for this wiki it has six recurring parts:

- Identity of the principal — binds authorization to the human/user approving the agent, not to the agent itself. AP2 mandates are signed by the user's wallet or identity provider, carrying proof that a specific human approved the agent's action (https://eco.com/support/en/articles/14845479-ap2-agent-payments-protocol-explained). - Scope — the merchant or merchant category, whitelist/blacklist rules, allowed product types, and acceptable transaction characteristics. AP2's Intent Mandate encodes this as hard constraints: max price, item specifications, allowed merchants (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). - Constraints — spending limits: per-transaction caps, daily limits, monthly limits, product-specific restrictions (https://eco.com/support/en/articles/14845479-ap2-agent-payments-protocol-explained). - Expiry — the time window during which the mandate is valid; after expiry the agent cannot authorize new transactions under it (AP2 Intent Mandate includes an expiry/TTL field — https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). - Signature — cryptographic proof the principal actually issued the mandate. AP2 uses Verifiable Credentials (W3C VC) as the encoding; Mastercard uses MDES tokenization, the same technology as Apple Pay (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol; https://eco.com/support/en/articles/15192001-what-is-mastercard-agent-pay-ai-agent-commerce-protocol-in-2026). - Revocation — the ability to cancel a mandate after issuance, preventing new transactions under it. AP2's spec addresses revocation, but Eco reports the actual gap is structural, not a testing shortfall: the protocol lacks an in-protocol mechanism to propagate a revocation to the settlement rail once a mandate has been issued (https://eco.com/support/en/articles/14845479-ap2-agent-payments-protocol-explained).

Field-level schema detail for a real mandate payload belongs in How to Read an AP2 Mandate or Visa/Mastercard Agent Token Schema — telling a populated security field from a permissive one; a side-by-side of how each protocol fills these six slots belongs in Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives.

Map of Which Protocol Sits at Which Layer, and How They Compose

- AP2 (Google Agent Payments Protocol) sits purely at the authorization layer: it specifies mandates and trust mechanisms but does not itself move money. It is payment-method-agnostic by design, meant to ride on top of card rails, x402 stablecoin rails, or other settlement infrastructure (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). Stripe, Adyen, and Checkout.com are named as pilot partners for translating an AP2 Mandate into Mastercard Verifiable Intent for clearing on Mastercard rails, though the source only documents these as 2025 pilot partnerships and does not confirm the integrations had shipped into production by April 2026 (https://eco.com/support/en/articles/15192003-mastercard-agent-pay-vs-visa-trusted-agent-2026-compared). AP2 is also designed to accommodate x402 as a settlement rail directly: the A2A x402 extension combines AP2 authorization with x402 stablecoin settlement, built with Coinbase, Ethereum Foundation, and MetaMask (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). See Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release.

- Mastercard AP4M (Agent Pay for Machines), launched June 10, 2026, spans both layers. Its four-step model is credential (register agent on-chain) → permission (set spending limits programmatically) → transact (execute payment) → settle (finalize through card/stablecoin rail), using a Verifiable Intent framework (https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale). Agent credentials are recorded as MDES tokens extended with agent identity and consent-policy metadata as part of the permissioning step; Eco mentions Polygon, Solana, and Base only in the context of stablecoin settlement costs, not as on-chain locations where AP4M credentials are recorded (https://eco.com/support/en/articles/15192001-what-is-mastercard-agent-pay-ai-agent-commerce-protocol-in-2026). See Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration.

- Visa Intelligent Commerce also spans both layers: the authorization side provisions agent-specific payment tokens with instruction-alignment controls enforced at network level when credentials are retrieved; the settlement side routes through Visa card networks or stablecoin rails (https://developer.visa.com/capabilities/visa-intelligent-commerce). Its tokens are scoped to the agent and transaction context, not just the underlying card, so a compromised agent token does not compromise the card (https://eco.com/support/en/articles/14845484-visa-intelligent-commerce-explained). See Visa Intelligent Commerce: Tokenized Agent Credentials — the spec-vs-announcement test applied to Visa's own numbers.

- Stripe Agentic Commerce Protocol (ACP) operates primarily at the authorization layer: secure payment credential tokenization that is programmatically controlled, permissioned, and logged, with the merchant retaining authority to accept or decline based on fraud signals (https://stripe.com/blog/developing-an-open-standard-for-agentic-commerce). See Agentic Commerce Protocol (ACP) — the checkout-layer spec Stripe and OpenAI ship, and the deployment it already killed.

- x402 (HTTP 402 Protocol) operates primarily at the settlement layer: instant stablecoin payments over HTTP, with a minimal authorization component — the PAYMENT-SIGNATURE header proves the client authorized payment via a Base64-encoded PaymentPayload (https://docs.x402.org/core-concepts/http-402). Its own flow explicitly separates authorization/verification (steps 5-6: the resource server confirms payment validity via the facilitator's /verify endpoint, before fulfillment) from settlement (steps 8-11: after resource delivery, fund movement via the facilitator's /settle endpoint or direct blockchain interaction) (https://github.com/x402-foundation/x402).

- Coinbase Agentic Wallets (launched February 11, 2026) provide the authorization layer — session caps, per-transaction limits, MPC wallet security, Know-Your-Transaction compliance screening, configured by the human operator at wallet-creation time and tightenable on the fly, with agents able to view but not change them — plus native x402 support for settlement. Agents can pay for x402 services and transact on Base, Polygon, and Solana but cannot transfer funds to arbitrary addresses (https://eco.com/support/en/articles/14845485-coinbase-agentic-wallets-explained). See Coinbase Agentic Wallets — spend limits enforced server-side, native x402, and how thin the outside-usage evidence still is.

Takeaway

the same authorization event (an AP2 mandate) can legitimately clear through more than one settlement rail (card network or x402/stablecoin), and the same settlement rail (x402) can be reached with more than one authorization scheme (its own minimal signature, or an AP2 mandate on top). Reading a protocol announcement without first asking "which layer is this claim actually about" is how the two get conflated. See Interoperability or Walled Gardens? Cross-Protocol Compatibility — what a builder actually integrates when an AP2, ACP, x402 and UCP agent all show up for how much of this composition is spec-backed versus marketing.

The Test for Every Other Page in This Wiki

Three distinctions recur across every protocol page and must be applied before citing any claim:

Spec vs press release. A published specification is a stable, versioned document at a public URL with clear version/date tags — e.g. a spec repo like github.com/agentic-commerce-protocol, not an announcement blog post (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol). The ap2-protocol.org/specification page returned HTTP 404 at fetch time, but the Google Cloud Blog announcement itself states the full technical specification is published publicly on GitHub (https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol) — so AP2 plausibly clears this bar even though this page could not fetch the spec document directly. UNVERIFIED similarly for Mastercard AP4M: the searches and fetches used for this page returned press releases and overviews, not a link to a versioned specification document.

Outside implementation vs none. An outside implementation is a working integration built and operated by an entity other than the issuing company, with evidence in production code, a shipped product, or a public transaction — a launch partner named in a press release is not sufficient evidence. None of the three protocols surveyed here cleanly clears this bar in the sources used for this page: Stripe, Adyen, and Checkout.com are named as 2025 pilot partners for AP2→Mastercard-Verifiable-Intent translation, but shipped production status by April 2026 is not confirmed (https://eco.com/support/en/articles/15192003-mastercard-agent-pay-vs-visa-trusted-agent-2026-compared); for Visa Intelligent Commerce the reported "100+ partners enrolled, 30+ actively in sandbox testing, 20+ integrating in production" (as of April 2026) does not distinguish whether all 20 have shipped production integrations or remain in testing (https://eco.com/support/en/articles/14845484-visa-intelligent-commerce-explained); Mastercard AP4M's "more than 30 industry partners" at its June 10, 2026 launch is a supporter list, not a disclosed count of shipped integrations (https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale). Full protocol-by-protocol scoring belongs in Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols.

Figure with a base vs figure without one. A figure carries a base when it states the number of observations (n), the time window measured, and who measured it. The oft-cited "$7B annualized stablecoin settlement run-rate across nine blockchains by April 2026" for Visa Intelligent Commerce lacks all three (n=?, which nine blockchains, measured by whom) and annualizes a short window — that is a caveat to state alongside the figure, not a fact to repeat unqualified (https://eco.com/support/en/articles/14845484-visa-intelligent-commerce-explained). The step-by-step procedure for applying this test is How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page; two claims that specifically need this treatment are tracked in The '$7.84 Billion AI Agents Market' Claim, Traced to Source — Forecast vs Measured Fact and x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact.

What This Page Does Not Cover

It does not adjudicate any individual protocol's spec status, partner count, or fee schedule — those verdicts live on the per-protocol reference pages linked above, each re-applying the three-part test from this page. It does not cover the settlement-rail economics themselves (interchange fees, stablecoin gas costs); see Card Network Fees vs Micropayments — the interchange arithmetic, re-anchored to the primary schedules and Stablecoin Settlement Cost, Measured — why sub-cent agent payments are only viable on-chain.

Related

- Google AP2 — the one agent-payment authorization spec that shipped code, not just a press release — the fullest example of an authorization-only protocol designed to compose with multiple settlement rails; apply the spec-vs-press-release test to its version history first. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration and Visa Intelligent Commerce: Tokenized Agent Credentials — the spec-vs-announcement test applied to Visa's own numbers — the two protocols that span both layers in this wiki's survey; use the layer map above to see which of their claims are about authorization and which about settlement. - Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives — takes the six-field mandate anatomy from this page and compares how each protocol actually fills it. - Outside Implementations Tracker — separating shipped code from launch-partner press releases across the five agent-payment protocols and How to Verify an Agent-Payment Protocol Claim Before Citing It — the four checks this wiki runs on every page — operationalize the "test for every other page" section above into a repeatable checklist. - Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki — depends on this page's authorization/settlement split to locate where liability plausibly sits when something goes wrong.