x402 vs MPP vs AP2: which agent payment protocol should you use?
A concrete comparison of HTTP 402 (x402), Mastercard's Agent Pay protocol (MPP/AP2), and when each is the right tool — latency, custody, auditability, and how to observe all three with one SDK.
Three payment protocols are competing to be “how agents pay.” Here’s what each actually does, where each one wins, and the one-line summary you can quote in a meeting.
TL;DR
| x402 (HTTP 402) | MPP (Mastercard Agent Pay) | AP2 (Agent Pay 2) | |
|---|---|---|---|
| Unit billed | per call | per transaction | per transaction |
| Asset | USDC onchain | fiat (card rails) | USDC + stable settlement |
| Custody | non-custodial (agent holds keys) | custodial (issuer holds) | hybrid |
| Latency | ~2-5s (block confirmation) | <1s (auth hold) | ~2-5s |
| Refund path | onchain only | chargeback rails | onchain + protocol-level |
| Best for | paid APIs, metered MCP tools | agentic checkout of real-world goods (rides, food, SaaS subs) | mixed workloads needing both rails |
| Who can verify | anyone with a node | the network | anyone with a node |
x402 — the open one
x402 is the only fully non-custodial option. The agent owns the wallet, signs the payment, and the server verifies the settlement onchain. Nobody in the middle holds funds.
The trade-off: settlement speed is bounded by block time. On Base, that’s ~2 seconds — fine for paid APIs, painful for a “buy me a coffee” UX where the agent is supposed to act in real time. Refunds require a new onchain transaction (no chargeback rail).
Use it when: you’re selling API calls, MCP tool invocations, metered AI inference — anything where the consumer is software, not a human tapping a card terminal.
MPP / AP2 — the card-rail one
Mastercard’s Agent Pay protocol (and AP2, the broader spec) lets an agent pay using card-network rails. Latency is sub-second (it’s an auth-hold like any card transaction), refunds use the existing chargeback system, and the money never leaves the banking system.
The trade-offs: it’s custodial (an issuer holds the funds the agent draws against), and verification requires trusting the network — there is no public ledger an outside auditor can check.
Use it when: the agent is buying something a human eventually consumes (a rideshare, a food order, a SaaS subscription) and you need the consumer-protection rails of card payments. The audit story is “ask the network,” which is acceptable when the network is liable.
The interesting bit: they interleave
Most production agent-commerce stacks we see run both:
x402for the small, fast, agent-to-API calls (data, inference, tools)MPP/AP2for the larger, agent-to-merchant calls (real-world purchases)
The Harpd collector speaks all three. From your code’s perspective, you emit the same event shape and the policy engine doesn’t care which rail carried the money:
const observe = harpdPlugin({
apiKey: process.env.HARPD_KEY!,
endpoint: 'https://api.harpd.com',
})
// Same hook fires for x402, MPP, or AP2.
// 'rail' field on the event tells the collector what to verify against.
client.use(observe)
Harpd’s verify-onchain module checks x402 against a node, MPP against the network’s auth API, and AP2 against the protocol settlement contract. You don’t pick — the event’s protocol field picks for you.
How to choose in one sentence
Per-call software calls → x402. Real-world consumer purchases → MPP/AP2. Mixed workloads → both, with one observability layer.