Navigating agentic stablecoin micropayments: Machine Payment Protocol, x402, and Turnkey

Two open standards now let AI agents pay for APIs, compute, and data using stablecoins over HTTP:  x402, launched by Coinbase in May 2025, and the Machine Payments Protocol (MPP), co-authored by Stripe and Tempo in March 2026. Both operationalize the HTTP 402 "Payment Required" status code for machine-to-machine stablecoin payments.

This article breaks down how each agentic payment protocol works, where they overlap, where they diverge, and what wallet infrastructure is required for both.

The agentic payments infrastructure is ahead of the demand

The onchain agentic economy is small today. One analysis pegs it at roughly $50 million in volume with about 40,000 agents. Artemis analysts estimate that much of x402's reported transaction volume reflects infrastructure testing rather than genuine commerce.

But the capital being deployed tells a different story. Tempo, incubated by Stripe and venture firm Paradigm, raised $500 million at a $5 billion valuation.  These are forward bets on where AI agent commerce goes over the next two to three years.

According to Mckinsey, by 2030, agentic commerce could represent $3 to $5 trillion of global consumer commerce. Understanding how x402 and MPP work before the wave of agent adoption hits is the difference between being ready and being late.

What is HTTP 402, and why does it matter for agentic payments?

HTTP 402 "Payment Required" is a status code that has existed in the HTTP specification since 1997. Both x402 and MPP use HTTP 402 to execute, and prove payment.

The core mechanic is the same. A server returns HTTP 402 along with machine-readable payment terms (price, token, recipient address, chain). The client reads the terms, executes the payment, and retries the request with proof of payment in an HTTP header. The server verifies the proof, settles the payment, and delivers the resource.

There are three roles that make this work. 

• The client is the AI agent, application, or human making the request.
• The resource server is the API or service charging for access. 
• The settlement layer verifies and finalizes the payment, either onchain through a facilitator (x402) or through a payment processor (MPP with Stripe). 

Where the two protocols differ is in their settlement architecture, supported payment methods, and approach to high-frequency billing.

What is x402? Coinbase's crypto-native payment protocol

x402 is an open, neutral standard for internet-native stablecoin payments created by Coinbase and governed by the x402 Foundation, which Cloudflare co-founded in September 2025. 

x402's design philosophy is minimalist: it defines the HTTP 402 handshake, the payment proof header format, and the facilitator verification step, then gets out of the way. It does not dictate which blockchain to settle on, which token to use, or how to manage keys.

How x402 settlement works

Settlement happens on existing public blockchains. The Coinbase Developer Platform (CDP) facilitator supports Base and Solana out of the box, with a free tier of 1,000 transactions per month and $0.001 per transaction after that. 

The x402 EVM SDK supports any EVM-compatible chain where the payment token implements EIP-3009 (Transfer With Authorization), which includes USDC and EURC. 

x402 fees and costs

The x402 protocol charges zero protocol fees. The only cost is onchain gas, which on Base or Solana amounts to fractions of a cent per transaction.

x402 payment model

The payment model is simple: one fixed-price stablecoin payment per HTTP request, settled onchain immediately. 

x402 adoption and volume

The x402 homepage reports 75.41 million transactions and $24.24 million in volume over the last 30 days. Adopters include Nansen, AWS, Alchemy, Vercel, and World. 

What is MPP? Stripe and Tempo's multi-rail Machine Payment Protocol

The Machine Payments Protocol (MPP) launched on March 18, 2026, co-authored by Stripe and Tempo. Tempo's purpose-built payments blockchain went live the same day. Where x402 is a crypto-native protocol that adds a thin payment layer to HTTP, MPP is a broader payment abstraction that is payment-method agnostic by design.

How MPP settlement works

MPP supports multiple settlement rails through the same HTTP 402 challenge-response flow: stablecoins on Tempo, Bitcoin over Lightning via Lightspark, and tokens on Solana, with an extensible framework for adding custom payment rails.

For card-based payments, Stripe provides Shared Payment Tokens (SPTs), scoped, time-limited credentials that keep raw card numbers out of the agent's context. Payments appear in the Stripe Dashboard like any other transaction, with the same tax calculation, fraud protection, and refund capabilities.

MPP fees and costs

Stripe's standard processing fees apply for card-based SPT payments. For stablecoin payments on Tempo, costs follow the same pattern as other L2s: fractions of a cent per transaction.

MPP payment model

The way MPP structures its payments is a  key technical differentiator. Beyond one-shot payments, MPP also supports sessions. You can think of sessions like a bar tab: the agent opens a session with a spending limit, runs up charges across many requests, and settles once at the end. For use cases like per-token LLM billing or streaming data feeds, this eliminates the per-request settlement cost that x402 carries.

MPP ecosystem and adoption

MPP launched with a payments directory of 100+ integrated services including Anthropic, OpenAI, Shopify, Dune Analytics, and Alchemy.

MPP backwards compatibility with x402

Cloudflare's MPP documentation confirms that MPP is backwards-compatible with x402. x402's exact payment flows map directly onto MPP's charge intent, so MPP clients can consume existing x402 services without modification.

Both protocols use HTTP 402 as the trigger. Both support stablecoin settlement. The primary architectural difference: x402 is permissionless and crypto-only, while MPP supports multiple payment rails and includes a session model for high-frequency billing. 

Why stablecoin rails are required for agent micropayments

The stablecoin vs. fiat question determines which payments require wallet infrastructure and which do not. Some considerations: 

• Card network fee economics. Card networks carry a fixed fee floor of roughly 30 cents plus a percentage on every transaction. a16z crypto's analysis states that a one-cent API call through Visa would cost more in processing fees than the value of the transaction itself. Sub-dollar payments are economically impossible on card rails.
• Stablecoin transaction costs. Stablecoin transfers on Layer 2 blockchains like Base cost fractions of a cent. A USDC transfer on Solana costs approximately $0.0001. That is a four-orders-of-magnitude cost difference compared to card processing for the same payment.
• The two-layer payment stack for AI agents. This cost structure creates a natural split in how agents pay for things.
• Fiat rails can handle agent-to-merchant purchases where a human is the principal buyer and the transaction resembles traditional e-commerce: ordering physical goods, booking services, paying for SaaS subscriptions. Transaction sizes are typically $5 and up. 
• Stablecoin rails can handle agent-to-API and agent-to-agent payments where the transaction is purely programmatic: API calls, compute metering, data feeds, model inference, MCP tool payments. Transaction sizes are typically $0.001 to $1.00. x402 and MPP sessions on Tempo serve this layer. No card rail can profitably process transactions at this scale. 

The a16z analysis makes a stickiness argument: developers building agents today will reach for payment tools that work today. Stablecoins are programmable, global, and trivial to integrate into APIs. Payments are sticky. Relationships built on stablecoin rails now will remain on stablecoin rails later.

What both protocols need but don't specify: the wallet layer

Both x402 and MPP define how payments are negotiated and settled over HTTP. Neither protocol specifies where the agent's private key lives, how it is encrypted, what prevents the agent from overspending, or how to revoke signing access if something goes wrong.

This is intentional. A payment protocol should not dictate wallet implementation, just as HTTP does not dictate how you store TLS certificates. But for AI agents operating autonomously with real funds, the wallet layer is where the security model actually lives.

What agents need to sign

An AI agent making stablecoin payments must produce cryptographic signatures. For USDC on EVM chains, this means an EIP-3009 transferWithAuthorization signature. For Solana, it means an equivalent SPL token transfer signature. Both require access to a private key.

What production wallet infrastructure provides

 A production-grade wallet layer for agentic payments provides five capabilities:

• Hardware-isolated key storage so the agent never accesses the raw key
• Scoped credentials so the agent can only sign authorized transaction types
• A policy engine that evaluates every signing request before a signature is produced
• Multi-chain support from a single integration
• Instant revocation if anomalous behavior is detected

This is the layer that makes x402's autonomous payment model and MPP's session-based spending safe at scale: the payment protocol defines the mechanism of payment, the programmable key management layer defines the authority to pay.

How Turnkey fits into the agentic payments stack

Turnkey is non-custodial wallet and signing infrastructure that provides the secure key management layer agents need to produce the cryptographic signatures required by x402 and MPP.

Our agentic Wallets documentation shows how to get started using x402 as a compatible agentic payment protocol. This architecture maps directly to the payment flow both x402 and MPP use. We also support legacy transaction formats for Tempo’s mainnet, along with native gas sponsorship built directly into the execution flow.

Key capabilities include:

• TEE-based key storage for agent wallets. Private keys are generated and stored inside AWS Nitro Enclaves, a type of Trusted Execution Environment (TEE) that isolates code and data from the host system. Keys are never decrypted outside the enclave. When an agent needs to sign a stablecoin payment authorization, the enclave produces the signature internally. The agent receives the signature, not the key.
• Delegated access for AI agents. Agents authenticate with API credentials that have no permissions by default. Access is explicitly defined through policies, so each agent operates within scoped authority.
• Policy enforcement at signing. Turnkey's policy engine evaluates every signing request inside the secure enclave before producing a signature. Policies can scope agent signing authority by recipient address, contract address, function selector, chain ID, and transaction value. 
• Low latency signing for real-time payment flows. Turnkey signs transactions in sub-100ms, keeping the wallet layer from becoming a bottleneck in x402 and MPP payment flows..
• Multi-chain agent wallet support. One integration supports EVM chains, Solana, Bitcoin, and Tron. Turnkey produces the required signatures for stablecoin payments across supported chains without additional infrastructure.

How to choose between x402 and MPP for your agents

This is not a winner-take-all market. The backwards compatibility between these protocols means early adopters are not locked in. Depending on the scenario, one may offer advantages over another, but both are evolving toward the same core payment model.

Choose x402 if you want fully permissionless, crypto-native stablecoin settlement with zero buyer setup. Any agent holding a funded wallet can pay immediately. No accounts, no API keys, no onboarding. Best for: open APIs where you want to accept payment from any agent on the internet.

Choose MPP if you want session-based micropayment billing, Stripe Dashboard integration, and support for fiat payment methods alongside stablecoins. Better for: high-frequency callers who benefit from pre-authorized spending limits, and teams already running on Stripe.

Choose both if you serve diverse agent populations. The backwards compatibility makes this straightforward. Early adopters like RobotDomainSearch are already issuing challenges for both protocols in a single 402 response, giving agents protocol-level fallback if one settlement chain is congested.

Regardless of which agentic payment protocol you choose, the wallet infrastructure question is the same. AI agents need secure key management, policy enforcement before signing, and scoped access that can be revoked instantly. The payment protocol defines how value moves. The wallet layer defines who is allowed to move it.

Getting started with agentic wallet infrastructure

Turnkey’s Agentic Wallets provide a clear path to production-ready agent payments, covering wallet creation, delegated access for agents, policy definition, and transaction signing across chains.

x402 and MPP both turn HTTP 402 into a machine-to-machine payment primitive, enabling agents to pay for APIs, compute, and data using stablecoins. This shift is driven by economics. Card networks cannot support sub-dollar transactions, while stablecoin rails make high-frequency, low-value payments viable.

Neither protocol defines how keys are managed or how signing authority is controlled. That responsibility falls to the wallet layer, where security, policy enforcement, and delegation determine whether agents can operate safely at scale.

Turnkey provides that foundation, giving developers a secure, programmable way to manage keys and enforce controls across both x402 and MPP payment flows.

Get started with Turnkey today.

‍