Agent-to-Agent vs Agent-to-Merchant Payments — the split that decides which protocol set actually applies

"Agent payments" is not one problem. AP2, ACP, Visa Intelligent Commerce and Mastercard's card rail are built for an agent acting as a *consumer's proxy* buying from a merchant; x402, Stripe's Machine Payments Protocol (MPP) and Coinbase Agentic Wallets are built for one piece of *software paying another piece of software* per API call. Picking the wrong family means importing consumer-authorization machinery a machine-to-machine integration doesn't need, or missing the consumer-protection law a shopping agent is still bound by. See Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against for why this split sits on top of settlement choice, and Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives for how each side expresses limits.

Agent-to-merchant: AP2, ACP, Visa, Mastercard card rail

These protocols assume a human consumer stands behind the transaction, even when execution is autonomous.

- AP2 (Google Agent Payments Protocol) authorizes via a chain of cryptographically signed mandates proving the user authorized the purchase, built to cover "both human-present scenarios (where users oversee transactions) and human-not-present scenarios (autonomous agent execution)." Naming differs by source: ap2-protocol.org's own spec names a Checkout Mandate and a Payment Mandate; Google's Cloud Blog announcement describes the same authorization chain using Intent Mandate / Cart Mandate language — treat these as two vocabularies for one mechanism, not four distinct mandate types. — https://ap2-protocol.org/ - Google's own use-case walkthrough for AP2 is consumer shopping: "Agent monitors for unavailable items and auto-purchases when conditions are met" and "Agent communicates with merchant agents to negotiate custom bundles." — https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol - ACP (Agentic Commerce Protocol) is "designed specifically for 'how agents interact with merchants to complete purchases' through standardized checkout endpoints... human-present commerce — agents help users shop within chat interfaces." — https://www.crossmint.com/learn/agentic-payments-protocols-compared - Amazon Buy for Me is the leading shipped agent-to-merchant deployment, reported at a $12 billion annualized run-rate by year-end 2025 (an extrapolated figure, not a settled annual total — treat with the caution x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact applies elsewhere to annualized numbers). ChatGPT Instant Checkout was OpenAI's parallel agent-to-merchant experiment but stayed thin — a dozen merchants — before OpenAI retired it in March 2026, so it did not contribute meaningfully to that $12 billion figure. — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide - Mastercard AP4M and Visa Intelligent Commerce both keep agent-to-merchant transactions on card/account rails: AP4M's architecture is "credentialing registered agents, permissioning what they are authorized to spend, transacting across Mastercard's card and account rails, and settling in either traditional currencies or stablecoins," and Visa scopes a token to "merchant/transaction-type/spend-limit," with revocation not requiring card reissuance. — https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale, https://www.paz.ai/glossary/agent-payments-protocol-ap2

Agent-to-agent: x402, MPP, Coinbase Agentic Wallets

These are built for a machine paying a machine — no consumer, no card, often no account.

- x402 turns HTTP 402 into a payment primitive: "A request can signal price. A client can pay instantly. The server can verify and fulfill. No account creation, no subscription tier, no manual approval." Released May 2025 (Coinbase Developer Platform), it settles in USDC/EURC via EIP-3009 gasless authorization on EVM chains and Solana, with facilitators handling verification so servers don't run nodes or manage wallets; settlement runs "2 to 8 seconds for cross-chain fills and sub-second for same-chain settlement." Governance moved to the x402 Foundation (Coinbase + Cloudflare, 2025) as an open standard rather than a single-company protocol. — https://www.allium.so/blog/x402-explained-the-internet-native-payments-standard-for-apis-data-and-agent-commerce/, https://eco.com/support/en/articles/12328618-x402-protocol-explained-how-ai-agents-pay-onchain, https://www.rzlt.io/blog/agentic-payments-2026-x402-explainer - Stripe Machine Payments Protocol (MPP), launched March 18 2026, extended April 29-30 2026 at Stripe Sessions with a streaming-payments primitive: "token-level usage on AI products billed in real time against a stablecoin balance on Tempo." — https://stripe.com/blog/machine-payments-protocol - Coinbase Agentic Wallets (launched Feb 11 2026) enforce spend limits — per-token allowances, session caps, per-transaction limits, allowlists — "server-side by Coinbase's policy engine before the enclave produces a signature," speak x402 natively, and can round-trip "in a single second on Base." — https://eco.com/support/en/articles/14845485-coinbase-agentic-wallets-explained - Reported adoption by April 2026: 69,000 active agents, 165 million transactions, roughly $50 million cumulative volume, average ~30 cents/call (x402 Foundation-sourced figure — no independent base given in these notes; treat cautiously, see x402 'Tens of Millions of Transactions': Reconciling the Claim — a number without a base is not a fact). — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide

Where the split gets stretched

- AP2 is explicitly hybrid by design: "agents can act with real-time user approval (agent-to-merchant) or execute delegated tasks autonomously (agent-to-agent)." — https://ap2-protocol.org/, https://www.crossmint.com/learn/agentic-payments-protocols-compared - AP4M's "agents paying agents" framing is agent-to-agent language riding an agent-to-merchant rail: its worked example is an agent that could "set up a website, including the domain, hosting and so on" — paying several small suppliers autonomously in the course of one task — which describes machine-to-machine micropayments, but settlement still runs through Mastercard's card/stablecoin infrastructure, not peer-to-peer. — https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale - Google's separate A2A (Agent-to-Agent) protocol — distinct from AP2 — is the delegation layer actually deployed for agent-to-agent workflows, reported in production at 150+ organizations by April 2026 (Microsoft Azure AI Foundry, Amazon Bedrock AgentCore, Salesforce). — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide - x402 is being pulled toward agent-to-merchant use via Stripe (x402 support added February 2026, USDC on Base), but its architecture remains optimized for high-frequency, low-value machine transactions rather than retail checkout — a stretch in the opposite direction from AP4M's. — https://workos.com/blog/x402-vs-stripe-mpp-how-to-choose-payment-infrastructure-for-ai-agents-and-mcp-tools-in-2026 - MPP and x402 "share their signature substrate, leaning on EIP-3009 and Permit2 for off-chain authorization" — complementary, not competing, letting Stripe-integrated merchants accept agent stablecoin payments through the same facilitator pattern. — https://stripe.com/blog/machine-payments-protocol

Different risk profile: consumer-protection law applies unevenly

Agent-to-merchant transactions inherit existing electronic-payment law, imperfectly: - Regulation E hinges on "authorized" vs "unauthorized" EFTs, but "it is currently unresolved whether a consumer granting an AI agent access to their bank account or payment credentials satisfies Regulation E's authorization requirements." — https://www.fenwick.com/insights/publications/is-2026-the-year-of-agentic-payments - "Existing rules say little about how the risk should fall between consumer, agent provider and trader" when an agent buys wrong or overspends — a gap noted because every major electronic-payment regulation assumes a human is on the other side. — https://www.chargeflow.io/blog/agentic-commerce-regulation-what-merchants-need-to-know - Card-network chargeback rights still apply on agent-initiated card-rail transactions (Visa/Mastercard, including AP4M's card path), putting the burden of proving authorization on the merchant/processor. — https://www.fenwick.com/insights/publications/is-2026-the-year-of-agentic-payments, https://www.biometricupdate.com/202606/mastercards-ap4m-enables-small-agentic-payments-at-machine-speed-and-scale

Agent-to-agent stablecoin settlement largely falls outside that frame: - USDC transfers on Base/Solana are not EFTs under Regulation E's definition ("transfers of funds from a consumer's account at a financial institution by means of an electronic terminal, telephone, computer, or magnetic tape"). — https://www.taylorwessing.com/en/insights-and-events/insights/2026/02/agentic-ai-in-payments - x402 stablecoin settlement has "no equivalent of chargeback, confirmed" — no consumer-protection reversal mechanism if an agent overspends or transacts wrongly. — https://www.allium.so/blog/x402-explained-the-internet-native-payments-standard-for-apis-data-and-agent-commerce/ - Agent-to-agent on stablecoin is framed as B2B (agent paying software service), which is why consumer-protection frameworks don't apply by design rather than by gap — though this framing is inferred from the B2C/B2B regulatory distinction rather than a source stating it explicitly for agent payments. — https://ec.europa.eu/info/publications/consumer-digital-rights-directive_en - UNVERIFIED (per source notes): on-chain/stablecoin agent payments have no clear liability allocation under current law when settlement fails or is disputed — genuinely unresolved as of August 2026. See Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki for the fuller treatment.

Practical guidance: which set applies to your use case

Agent-to-merchant → AP2 / ACP / Visa Intelligent Commerce / Mastercard AP4M card path: - Consumer shopping through ChatGPT, Gemini, Claude, or Copilot: use AP2 or ACP — human-initiated, consumer-protection-required. — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide - A retail merchant accepting payments from agents that found it inside a chat surface: Visa Intelligent Commerce or the AP4M card path. — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide - Real-time, high-touch consumer authorization: AP2's human-present flow (Checkout Mandate + Payment Mandate signed by the user — see the naming note above). — https://ap2-protocol.org/ - Amazon Buy for Me-style flows: agent-to-merchant, consumer-audience, already at meaningful reported volume. — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide

Agent-to-agent → x402 / MPP / Coinbase Agentic Wallets

- Agent paying an API for data, compute, or a service call — e.g. "a research agent might pay a data agent for curated datasets; a planning agent might compensate an inference agent for model calls" — settling per-request in stablecoins with on-chain records: x402. — https://eco.com/support/en/articles/12328618-x402-protocol-explained-how-ai-agents-pay-onchain - Sub-cent, no-account micropayments and MCP tool monetization: x402. — https://eco.com/support/en/articles/14839400-what-is-agentic-commerce-the-2026-guide, https://eco.com/support/en/articles/12328618-x402-protocol-explained-how-ai-agents-pay-onchain - Per-API-call billing without subscriptions (concrete Stripe-cited examples: Browserbase per-session browser access, PostalForm print/mail, Prospect Butcher Co. autonomous ordering): Stripe MPP or x402. — https://stripe.com/blog/machine-payments-protocol - Continuous workflows needing granular real-time billing: MPP's streaming-payments primitive. — https://stripe.com/blog/machine-payments-protocol - Spend-limited agent deployments needing on-chain, server-side policy enforcement before signature: Coinbase Agentic Wallets. — https://eco.com/support/en/articles/14845485-coinbase-agentic-wallets-explained - Enterprise agent delegation at scale (150+ organizations reported by April 2026): Amazon Bedrock AgentCore Payments, powered by x402 and Coinbase. — https://www.coinbase.com/blog/introducing-amazon-bedrock-agentcore-payments-powered-by-x402-and-coinbase

Why this matters for the wiki's objective

telling these two families apart is the first filter before applying the spec-vs-announcement and figure-with-a-base tests to any individual protocol page in this wiki — a builder who mismatches the family (e.g. reaching for AP2's consumer mandate chain to solve an API-metering problem) is solving the wrong problem before the verification question even comes up. See How to Choose an Authorization Protocol for an Agent Product — a decision path through the fragmented rail, not the press releases.

Related

- Authorization Layer vs Settlement Layer — the split every agent-payment protocol page in this wiki must be read against — this page's split is about *who the counterparty is* (merchant vs machine); that page's split is about *what layer* (authorization vs settlement) — the two axes compose: an AP2 mandate can ride a card rail (agent-to-merchant) while x402 rides stablecoin settlement directly (agent-to-agent). - Mandate Expression Compared — AP2, AP4M, Visa, ACP, Coinbase Side by Side, Where the Constraint Actually Lives — once you know which family applies, this is where the actual field-level mandate/token/policy design of each protocol is compared side by side. - Who Is Liable When a Prompt-Injected Agent Spends Money — the unresolved question behind every mandate protocol in this wiki — the consumer-protection gap sketched here (Reg E, chargebacks, no on-chain equivalent) is worked through in full on that page, including the "access device" exception risk. - How to Choose an Authorization Protocol for an Agent Product — a decision path through the fragmented rail, not the press releases — turns this page's category test into a concrete decision process for a builder picking one protocol to integrate. - Mastercard AP4M — an announced authorization layer, not yet a published spec or a shipped integration — AP4M is the clearest case of a protocol marketed with agent-to-agent language ("agents paying agents") while actually operating on agent-to-merchant card-rail infrastructure; that page has the fuller published-vs-announced treatment.