How AI Agents Pay for Services: MPP, x402, and the Agentic Payments Stack
In 2026, AI agents are conducting real commerce. Visa processed hundreds of agentic transactions. Coinbase launched Agentic Wallets in February. Over 1 million Shopify merchants opted into OpenAI's Instant Checkout. The total volume? $9.14 billion flowing through agentic commerce this year.
But there's a fundamental problem: AI agents can't use credit cards. They can't call 1-800 numbers to dispute charges. They can't sign their names on receipts. They need something entirely different—programmable, machine-native payment rails designed for autonomous systems.
The HTTP 402 Moment
When Tim Berners-Lee and the HTTP Working Group defined HTTP/1.0 in 1996, they included a status code for the future: 402 Payment Required. The idea was simple—servers could request payment before delivering resources. But it was never implemented. Credit cards worked fine for humans browsing the web.
Fast forward to 2026. Agents are browsing the web. They're calling APIs, downloading data, running inference, booking flights, ordering inventory. They need to pay for these services, and they need to do it programmatically. HTTP 402's moment has finally arrived.
The Agentic Commerce Stack
Identity layer (who is the agent, who controls it) → Wallet layer (how does it hold value) → Payment protocol (how does it spend) → Settlement layer (where does the money actually move)
MPP: Machine Payments Protocol
On March 18, 2026, Stripe and Tempo launched MPP (Machine Payments Protocol)—a session-based payment standard co-authored by two companies approaching the problem from opposite ends. Stripe brings the fiat rails. Tempo brings the crypto infrastructure. Together, they created a protocol that works with both.
MPP is session-oriented. An agent pre-authorizes a spending limit, then streams micropayments as it consumes resources. Think of it like opening a tab at a bar, except the tab is managed by cryptographic credentials instead of a credit card imprint.
The protocol supports two payment modes. On-chain mode uses stablecoins and blockchain settlement. Card mode uses Visa's specification for agent-initiated card payments—yes, Visa contributed directly to MPP. A single agent can maintain parallel sessions in both modes.
MPP defines four primitives: challenges (the server requests payment), credentials (the agent proves ability to pay), vouchers (promises of future payment), and receipts (proof of completed payment). These primitives compose into session workflows that span minutes, hours, or days.
x402: Coinbase's Instant Payment Layer
While Stripe and Tempo were building MPP, Coinbase took a different approach. x402 is radically simple: three HTTP headers, on-chain stablecoin payments, sub-2-second settlement, and transaction costs around $0.0001.
When a server requires payment, it returns HTTP 402 with a PAYMENT-REQUIRED header containing payment details—amount, recipient address, chain. The agent pays on-chain (USDC on Base, Ethereum, or Solana), then retries the request with a PAYMENT-SIGNATURE header proving payment. The server validates and returns a PAYMENT-RESPONSE header with the receipt.
x402 is stateless. Every request is independent. There are no sessions, no pre-authorization, no vouchers. You pay, you get the resource, you're done. It's the vending machine model—insert coins, receive product.
The protocol launched with native support in Coinbase's Agentic Wallet SDK. Any agent using Coinbase's wallet infrastructure can make x402 payments with a single function call. The wallet handles chain selection, gas estimation, signature generation, and retry logic.
How They Work Together
MPP and x402 aren't competing standards. They're complementary layers in the agentic payments stack. x402 is the execution layer—instant, stateless, per-request payments. MPP is the coordination layer—sessions, streaming, multi-payment workflows.
In fact, MPP is backwards-compatible with x402. An MPP session can use x402 as its underlying payment mechanism. The agent opens an MPP session, receives challenges, and responds with x402 payments as credentials. The session tracks total spending across multiple x402 transactions.
Think of x402 as TCP and MPP as HTTP. One handles individual packets, the other builds stateful protocols on top. You can use x402 directly for simple use cases. You use MPP when you need session semantics, spending limits, or complex multi-step workflows.
Protocol Comparison
x402: Stateless, per-request, vending machine model. Best for: API calls, data downloads, one-time purchases.
MPP: Session-based, streaming, tab model. Best for: AI inference, long-running services, subscription-style access.
The Per-Token Billing Problem
AI inference has a unique payment challenge: per-token billing. When you call GPT-4, you're not paying for the API request—you're paying for each token generated. The final cost isn't known until generation completes. This could be 100 tokens or 10,000 tokens.
Neither MPP sessions nor x402 requests are ideal for this. Sessions have overhead—you don't want to open a new session for every inference. x402 requires knowing the amount upfront. On-chain settlement costs more than a single token's value.
The solution: micropayment channels. Two parties lock funds in an on-chain escrow, then exchange signed off-chain updates. Each token generated triggers a signed receipt incrementing the total. Only the final state gets settled on-chain. Thousands of token-level payments collapse into one blockchain transaction.
Micropayment channels turn per-token billing from a blockchain scalability nightmare into a practical reality. The agent pays $0.0001 per token with zero on-chain overhead until the channel closes. The model provider has cryptographic proof of payment at every step.
Identity-Bound Payments: The Missing Layer
MPP and x402 solve how agents pay. But they don't solve who is paying. In both protocols, payments are associated with wallet addresses—anonymous hexadecimal strings with no inherent identity or access control.
This is where Tenzro's approach differs. Every payment is cryptographically bound to a TDIP (Tenzro Decentralized Identity Protocol) identity. When an agent makes a payment, the recipient doesn't just get a wallet signature—they get a verifiable credential chain linking the payment to a specific agent, linking that agent to a controller, linking that controller to a human guardian.
TDIP identities carry delegation scopes. A human can provision an agent with a wallet and authorize it to spend up to $1,000 per day, but only on AI inference and data services, and only on specific chains. The delegation is enforced cryptographically. Even if the agent's keys are compromised, the attacker can't exceed the delegated permissions.
This is critical for enterprise adoption. Companies need audit trails. They need to know which agent spent $50,000 on inference last month and who authorized it. They need to enforce spending limits without relying on centralized API gateways. Identity-bound payments make this possible.
The Complete Stack on Tenzro
Tenzro implements the full agentic payments stack with native protocol support at every layer.
At the identity layer, TDIP provides unified human and machine identity with W3C DID compatibility. Every agent gets a DID (did:tenzro:machine:controller:uuid). Every human guardian gets a DID (did:tenzro:human:uuid). Delegation relationships are on-chain and verifiable.
At the wallet layer, every identity gets an auto-provisioned MPC (multi-party computation) wallet. No seed phrases. The wallet is threshold-signed by network validators and bound to the identity. It holds TNZO, stablecoins, ETH, SOL, and BTC. It works with both MPP and x402.
At the payment protocol layer, Tenzro implements both MPP and x402 natively. The tenzro-payments crate provides session managers, challenge stores, credential verification, and receipt generation. HTTP middleware automatically handles 402 challenges. Agents using Tenzro SDKs get payment capabilities out of the box.
At the settlement layer, payments settle on Tenzro Ledger in TNZO or via cross-chain bridges in stablecoins. Micropayment channels live in on-chain escrow with off-chain state updates. Batch settlement processors handle atomic multi-payment operations. Everything is cryptographically verified and audit-ready.
Why This Matters
Agentic commerce isn't a future scenario—it's happening now at $9B scale. But without identity-bound payments and cryptographic delegation, we're building a system where agents can spend but no one can prove who authorized it. Tenzro combines the payment protocols (MPP/x402) with the identity layer (TDIP) to create accountable, auditable, delegatable agentic commerce.
Building on Agentic Payments
If you're building AI agents that need to pay for services, you have options. Use x402 for simple per-request payments. Use MPP for streaming sessions. Use micropayment channels for per-token billing. Use TDIP to bind payments to verifiable identities.
The agentic payments stack is live, standardized, and interoperable. The protocols are open. The infrastructure is deployed. The $9.14B flowing through agentic commerce in 2026 is just the beginning.
The real question isn't whether AI agents will conduct commerce—they already are. The question is whether that commerce will be accountable, auditable, and bound to real-world identities, or whether it will operate in an anonymous shadow economy of wallet addresses.
Tenzro is building the former. Identity-first, protocol-native, cryptographically delegatable agentic payments. Because when machines spend money, humans need to know why.
Build with Agentic Payments
Explore Tenzro's payment protocol documentation, learn how to implement MPP and x402 in your agents, and see code examples for identity-bound micropayment channels.