# Agent payment protocols compared, October 2026

Four standards matter in late 2026. x402 settles per-request micropayments on-chain, MPP does similar work through Stripe's rails, ACP structures agent checkout with merchants on card rails, and AP2 proves a user authorised a purchase without moving money. Price point and buyer type decide between them, and none provides spending limits.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/agent-payment-protocols-compared-2026

---

## The four, side by side

| | x402 | MPP | ACP | AP2 |
| --- | --- | --- | --- | --- |
| From | x402 Foundation, Linux Foundation hosted | Stripe and Paradigm | OpenAI and Stripe | Google |
| Moves money | Yes, on-chain | Yes, via Stripe | Yes, via processors | No |
| Unit | One HTTP request | One request or a session | One order | One authorisation |
| Price band | Fractions of a cent up | Fractions of a cent up | Retail | Any |
| Buyer needs | A stablecoin balance | A Stripe-reachable method | A payment method | A key and a user |
| Seller needs | A wallet address | A Stripe relationship | A merchant account | Nothing to settle |
| Public record | Every settlement | No | No | No |
| Refunds | None, final | Processor's process | Merchant's process | Not applicable |

The table makes them look like four options. Two questions collapse it.

## Question one: what is being bought?

**Infrastructure.** An API call, a data point, an inference, a proof. Priced below a cent, bought thousands of times, sold by an endpoint rather than a merchant. x402 or MPP.

**Goods.** A product, a subscription, a booking. Priced in dollars, bought occasionally, sold by a business with a processor and a returns policy. ACP, or ordinary checkout.

The dividing line is economic rather than philosophical. Card interchange has a fixed component that makes sub-cent payments impossible; on-chain settlement has no chargeback, which makes retail uncomfortable. Each rail is unusable in the other's band, so the protocols sorted themselves accordingly.

## Question two: who is accountable?

**Nobody, and that is fine.** Machine-to-machine infrastructure spend from a budget the operator set. x402 is built for this: the wallet key is the authority and no further proof is wanted.

**A person, and it has to be provable.** An agent spending a user's money on something the user would recognise as their purchase. This needs [AP2](https://roundhouseai.io/resources/x402-vs-ap2) or an equivalent signed mandate, layered over whatever settles the money.

> [!IMPORTANT]
> AP2 is not an alternative to the other three. It produces evidence of authority and moves nothing. Treating it as a payment protocol is the most common mistake in this comparison, and it leads to stacks that can prove intent and cannot settle.

## What none of them gives you

A budget.

x402 settles whatever is signed. MPP settles whatever is authorised. ACP completes whatever checkout the agent initiated. AP2 proves a mandate existed, and a mandate is not a cap on cumulative spend.

So an agent's spending limit lives in its wallet, not in its payment protocol, and the distinction between the two enforcement models is worth understanding before you rely on either:

- **Policy-engine wallets** enforce caps in the provider's infrastructure. Flexible, adjustable in real time, and dependent on that infrastructure behaving correctly.
- **On-chain permission grants**, using account abstraction and permission standards, enforce caps in the contract. Less flexible and not dependent on any server.

Published work in 2026 on agent-payment security converges on the same controls regardless of protocol: per-transaction caps, rolling budgets, counterparty allowlists, short expiries and a kill switch. The expiry point is the sharpest of them. A permission that lapses in a day limits the damage from a leaked key to a day.

## Can they be combined?

Yes, and realistic systems do.

A plausible consumer stack: the user authorises the agent, captured as a mandate. The agent operates inside a wallet-enforced budget. Retail purchases go through ACP on card rails. The data and inference the agent consumes along the way is paid over x402, per call, with no mandate attached because no human would recognise those as purchases.

A plausible infrastructure stack: one wallet, one budget, x402 everywhere, no mandates at all. Most agent systems are this one, and it is simpler than the discourse suggests.

## Which is most deployed?

x402 has by far the most live settlement, and by a margin that reflects its age and its unit size rather than any judgement about quality. It has been in production since May 2025 and its unit of use is a single request, so it accumulates transactions fast.

That said, **x402's headline figures are the least trustworthy of the four**, precisely because they are public. Through 2026 multiple independent analyses found that most of the counted volume was self-dealing or circular rather than commerce. The other three have no equivalent public scrutiny, which is not the same as having cleaner numbers. [How much x402 volume is real](https://roundhouseai.io/resources/how-much-x402-volume-is-real) is the longer treatment.

## Frequently asked questions

### Will one of these win?

Unlikely, because they occupy different price bands and different trust models. Expect the interesting work to be in bridges between them rather than in displacement.

### Which has the best developer experience?

x402 for a seller, because the integration is a 402 response and a facilitator call. MPP for a seller already on Stripe, because the surrounding machinery already exists. ACP is a commerce integration and is correspondingly larger.

### Can I take payment without picking one?

Yes: API keys and invoices still work. [Keys against x402](https://roundhouseai.io/resources/x402-vs-api-keys-and-metered-billing) covers when the old way is still the right way, which is more often than protocol discourse implies.

### Which should I build against first in 2026?

Whichever matches your buyer. If your buyers are agents with wallets and no accounts, x402, because that is where the clients, facilitators and catalogues are.

### Do these protocols handle disputes?

Only the card-rail ones, through the processor. On-chain settlement is final and a refund is a new payment you choose to send. If disputes are routine in your business, that constrains the choice more than anything technical.

## Where to check this yourself

One of the four can be audited from outside, which is a fact about the comparison rather than a footnote to it. [/transactions](https://roundhouseai.io/transactions), [/facilitators](https://roundhouseai.io/facilitators) and [/stats](https://roundhouseai.io/stats) let you check x402 claims against the chain. For the other three you are reading what the parties publish, and no third party can confirm it.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api