Concepts and protocols

ACP vs AP2 vs x402 vs MPP: agent payment protocols compared

What each agent payment protocol is for: checkout with merchants (ACP), verifiable user mandates (AP2), and pay-per-request machine payments (x402, MPP).

They solve different problems. ACP standardises checkout between agents and merchants, AP2 records what a user authorised as verifiable mandates, and x402 and MPP let a server request payment for an individual request, which an agent pays programmatically.

Why is this harder than it sounds?

The names arrived close together and are often listed as if they compete. Mostly they don't. A shopping agent buying shoes, an agent proving to a bank that the user really approved a purchase, and an agent paying a cent for an API call are three different transactions, with different parties and different risks. Picking the wrong one means building checkout flows for an API or signing payloads for a merchant that wants a card token.

How do you do it?

  1. ACP: agent-to-merchant checkout. The Agentic Commerce Protocol, developed by Stripe and OpenAI and open source under Apache 2.0, covers checkout and sharing payment credentials as secure tokens. The business stays merchant of record. OpenAI implements it in ChatGPT and Stripe's Shared Payment Token is the first compatible processor.
  2. AP2: proof of what the user authorised. The Agent Payments Protocol, published by Google, uses verifiable digital credentials called mandates, a checkout mandate and a payment mandate, each open (constraints) or closed (a specific authorisation). It is offered as an extension for A2A and the Universal Commerce Protocol.
  3. x402: pay for an HTTP request. A server answers 402 Payment Required with terms; the client retries with a signed payment; a facilitator verifies and settles. Stablecoin-based, with schemes for several networks.
  4. MPP: Stripe's machine payments. Stripe describes the Machine Payments Protocol as working with card payments through Shared Payment Tokens and stablecoin payments, for charging per tool call or HTTP request.
  5. Policy sits beside all of them. None of the four decides how much a particular agent may spend or on whom. That is the job of whatever holds the agent's credential.

What it does not mean

  • Supporting one doesn't rule out the others. A merchant could accept ACP checkouts and an API could accept x402.
  • None of these is a wallet. They describe messages between parties; something still has to hold funds and sign.
  • Launch status changes quickly. Check each protocol's own site for what is live where.

Common questions

Where does MCP fit?

MCP is how an agent calls tools, payment tools included. AP2 describes itself as an open extension for A2A and MCP; the others are payment protocols an MCP tool might use underneath.

Is this financial advice?

No. It compares how the protocols work. It doesn't recommend any of them, or any asset.

Where does Veyra fit?

Veyra implements none of these four today. It is a policy layer for an agent paying from your own wallet: an MCP endpoint whose create_payment sends USDC on Base to an address, within per-payment, daily, auto-approve and ask limits and an optional recipient allowlist, with a verifiable transaction reference once confirmed. Think of it as the 'policy sits beside them' step, for payees that accept a direct USDC transfer.

Sources

Terms on this page

This page explains how agent payments and the related technology work. It is not financial, investment, legal or tax advice. Protocols and provider features change; check the linked official sources before relying on a detail.