AI Payments

    x402 vs AMP vs MPP: Choosing the Right Payment Protocol for AI Agents

    •
    8 min read
    •
    Aggelos Kappos(Founder @ QBT Labs)
    x402AMPMPPAI AgentsMachine PaymentsPayment ProtocolsCrypto
    x402 vs AMP vs MPP: Choosing the Right Payment Protocol for AI Agents
    Share:

    The agentic economy is no longer a thought experiment. In Q1 2026 alone, Coinbase's x402 protocol processed over 115 million machine-to-machine transactions. Stripe and Paradigm launched Tempo mainnet with the Machine Payment Protocol (MPP) on March 18th. Valeo published the AMP spec for persistent payment channels on Solana. And QBT Labs is building the first multi-chain implementation across all three.

    If you're building an AI agent, an MCP server, or any service that needs to charge other software for access — you need to pick a payment protocol. This article breaks down x402, AMP, and MPP so you can make that choice clearly.

    The Problem They All Solve

    Traditional payment infrastructure was built for humans. Credit cards require identity verification. Bank transfers take days. Subscription billing assumes a fixed monthly fee. None of these work for an AI agent making 10,000 API calls per day, paying fractions of a cent per call, with no human in the loop.

    What agents need is different: programmatic, instant, crypto-native, and low-friction. The three protocols emerging in 2026 each solve this problem — but with different trade-offs.

    x402 — Pay Per Request

    x402 is the simplest model. When an agent hits a protected endpoint without payment, the server returns HTTP 402 with pricing details. The agent signs a payment authorization, retries the request with that signature in the header, and the server settles via a facilitator.

    How it works:

    Agent → GET /api/data
Server → 402 + { price: $0.001, token: USDC, network: base }
Agent → GET /api/data + X-PAYMENT: <signed EIP-3009 payload>
Facilitator → verify + settle on-chain
Server → 200 + data

    Best for: Simple, stateless API access. One request, one payment. Works perfectly when you need maximum simplicity and broad compatibility.

    The limitation: Every request triggers an on-chain transaction. For an agent making 1,000 calls, that's 1,000 on-chain transactions — O(N) cost scaling. At $0.001 per call, the on-chain gas overhead becomes significant at volume.

    Supported chains (QBT Labs): Base, Base Sepolia, Solana, Cardano

    AMP — Persistent Payment Channels

    AMP (Autonomous Machine Payments Protocol) takes a fundamentally different approach. Instead of paying per request, a client opens a payment channel once by depositing funds on-chain. From that point, every request is free — just signed headers with a sequence number. The server meters usage off-chain and settles periodically with a single on-chain transaction covering all usage in that period.

    How it works:

    Agent → Open channel (1 on-chain tx, deposit 10 USDC)
Agent → GET /api/data + AMP-Channel: <id> + AMP-Seq: 1 + AMP-Sig: <sig>
Agent → GET /api/data + AMP-Channel: <id> + AMP-Seq: 2 + AMP-Sig: <sig>
... (N more requests, zero on-chain txns) ...
Server → Settle (1 on-chain tx, nets all usage)
Agent → Close channel (1 on-chain tx, refund remainder)

    The math:

    Protocol1,000 callsOn-chain txns
    x4021,000 calls1,000 txns
    AMP1,000 calls~3 txns (open + settle + close)

    Best for: High-frequency agent workflows. Any use case where the same agent hits the same service repeatedly — LLM inference, streaming data feeds, oracle queries, market data. The more calls per session, the more AMP wins on cost and latency.

    Advanced features: Delegation (agent A can delegate budget to agent B), channel chaining (service A can pay service B from the same upstream budget), on-chain reputation scoring.

    Supported chains (QBT Labs): Base, Solana, Cardano (L1 + Hydra L2)

    MPP — Session Payments

    MPP (Machine Payments Protocol), developed by Stripe and Tempo, sits between x402 and AMP in terms of complexity. It has two modes:

    Charge mode — essentially x402 with a different wire format. Per-request payment, compatible with Tempo's infrastructure.

    Session mode — a client opens a session with a deposit, then sends cumulative off-chain vouchers per request. The server settles at session close using the final voucher. Fewer on-chain transactions than x402, but settlement happens at session end rather than periodically.

    Client → Open session (on-chain deposit)
Client → Request + X-MPP-Session: <id> + X-MPP-Voucher: <cumulative sig>
...
Client → Close session (final voucher → on-chain settlement)

    Key differentiator: MPP supports fiat payment methods (Stripe, credit cards) alongside crypto — making it the only protocol accessible to non-crypto-native agents. It's also backed by Stripe's distribution, which matters.

    Best for: Mixed human/agent workflows, B2C use cases where fiat is needed alongside crypto, services that want Stripe integration.

    Supported chains (QBT Labs): Base, Solana, Cardano

    Decision Framework

    Use this to pick:

    Use x402 if:

    • Simple one-off API access
    • Low call volume (<100 calls/session)
    • Broad compatibility matters most
    • Building quickly and don't need sessions

    Use AMP if:

    • High-frequency agent workflows (100+ calls/session)
    • Streaming or continuous data access
    • Agent-to-agent delegation needed
    • Cost per transaction is critical
    • Long-running agent relationships with services

    Use MPP if:

    • Mixed human/agent payment flows
    • Fiat support required (credit cards, Stripe)
    • Session-based access with defined start/end
    • Building on Tempo's ecosystem

    The QBT Labs Approach

    At QBT Labs, we're building all three as open-source, multi-chain packages:

    • @qbtlabs/x402 — Production-ready. Base + Solana + Cardano. Ships now.
    • @qbtlabs/amp — In development. First production AMP implementation anywhere. Base + Solana + Cardano including Hydra L2.
    • @qbtlabs/mpp — Planned. Tempo + Stripe compatible. Same three chains.

    All three share the same security core: encrypted vault, process-isolated signer, policy engine, AWS KMS JWT issuance. Your agent doesn't need to think about which protocol is in use — it just pays, and the infrastructure handles the rest.

    The QBT Facilitator (facilitator.qbtlabs.io) settles across all three protocols and all three chains, so any service built on QBT Labs infrastructure can accept payments in any format without maintaining their own blockchain nodes.

    What's Next

    The agent payment space is moving fast. By mid-2026 we expect:

    • AMP production implementations to emerge on multiple chains
    • MPP to standardize around Tempo + Stripe as anchor implementations
    • x402 to remain the default for simple integrations due to its simplicity

    The winner won't be a single protocol — it'll be infrastructure that supports all three and lets developers choose based on their use case without locking in.

    That's what we're building.

    Related Reading

    Resources

    Questions? Reach out at [email protected] or find us on X @QBTLabs.

    Related Articles

    AI Payments

    After the Signature: Receipts, Settlement, and Audit for AI Agent Payments

    The companion piece to Beyond the Wallet. That post covered the policy layer in front of the signature; this one covers the operations layer behind it — receipts, settlement, audit logs, and failure handling.

    AI Payments

    How API Providers Can Monetize AI Agents

    Subscriptions and API keys were built for humans, not agents. A practical guide to x402, AMP, and MPP — plus a concrete provider checklist for shipping agent-native pricing in under a week.

    AI Payments

    Beyond the Wallet: A Builder's Guide to Policy-Controlled Agent Payments with x402

    Giving an agent a wallet is the easy part. Production agent payments need budgets, allowlists, signer isolation, receipts, and policy before any signature is produced.