Two open standards dominate the emerging infrastructure for machine-to-machine payments: x402, created by Coinbase and now governed under the Linux Foundation; and MPP (Machine Payments Protocol), co-developed by Stripe and Tempo. Both solve the same core problem — enabling AI agents to pay for services autonomously, without human checkout flows or API key management. They take different approaches, and understanding the difference matters when you're building or integrating a walleted agent.

DocketLayer uses x402. Both protocols are supported.

Quick comparison

Dimension x402 MPP
Launched by Coinbase Stripe + Tempo
Governed by Linux Foundation Open standard, Stripe-led
Payment model Per-request, on-chain Session-based, streaming
Settlement On-chain USDC (Solana, Base) Stablecoin or fiat via Stripe
Per-transaction overhead One on-chain tx per request Pre-authorized session, micropayments streamed
Fiat support No — stablecoin only Yes — via Stripe card infrastructure
Backwards compatible N/A — original standard Yes — MPP clients can consume x402 services
DocketLayer support Native Compatible via MPP→x402 bridging

How x402 works

x402 revives the HTTP 402 "Payment Required" status code — defined in the original HTTP specification in 1996 but never implemented, because machine-native payment infrastructure did not yet exist. The protocol follows a simple challenge-response flow:

01 Agent requests a resource from a service. No payment header included.
02 Service responds with HTTP 402 and machine-readable payment details — price, accepted currency, recipient wallet address.
03 Agent's x402 client constructs a USDC transaction on Solana for the specified amount, signs it with the agent's wallet private key.
04 Agent retries the request with cryptographic payment proof in the Authorization header.
05 Service verifies the payment on-chain and delivers the resource. The entire flow completes within a single function call.

From the developer's perspective, the x402 client library handles steps 2–4 automatically. Your agent calls a URL, the library detects the 402 response, pays, and returns the result — as if it were a normal HTTP request.

# x402 handles the payment automatically
const response = await paymentClient.fetch(
  "https://api.docketlayer.com/v1/case",
  { method: "GET", body: JSON.stringify(params) }
);

# No manual payment construction needed
# The 402 challenge-response is transparent to your code

How MPP works

MPP takes a different approach suited to high-frequency agent workflows where per-request on-chain transactions add latency and cost. Rather than settling each request individually on-chain, MPP uses a session model:

01 Agent initiates an MPP session, pre-authorizing a spending limit — for example, $10 for the session.
02 The session is established with the service, cryptographically authorized up to the spending limit.
03 Individual requests within the session are streamed with micropayments, without a separate on-chain transaction per request.
04 Settlement occurs at session close or at defined intervals, netting the micropayments into fewer on-chain transactions.

MPP also supports fiat payment methods through Stripe's card infrastructure — an important practical advantage for agents operating in contexts where stablecoin funding is inconvenient or not yet available.

Which to use

Use x402 when:

  • You are building a new agent from scratch and want the simplest possible integration
  • Your query frequency is moderate — the per-request on-chain overhead is acceptable
  • You are already working with USDC on Solana or Base
  • You want native DocketLayer support without any bridging layer

Use MPP when:

  • Your agent makes very high-frequency queries where per-request on-chain transactions add meaningful latency or cost
  • You want fiat payment support alongside stablecoins
  • You are already integrated with Stripe's infrastructure
  • Your workflow benefits from session-based spending limits with pre-authorization

MPP is backwards-compatible with x402. An MPP client can consume DocketLayer without modification — the MPP client handles the x402 challenge-response automatically when it encounters a 402 response. You do not need to implement x402 separately if you are already using MPP.

Why stablecoins, not cards

Both protocols rely primarily on stablecoins for a straightforward economic reason: credit card interchange fees of 1.5 to 3.5 percent plus a fixed per-transaction fee make micropayments economically unviable. A $0.99 query incurs $0.02–0.04 in card fees — a 2–4% tax on every transaction. At scale and at sub-dollar price points, this compounds into a structural cost problem.

Stablecoin settlement on Solana costs a fraction of a cent per transaction. This is what makes per-request pricing at $0.99 — or lower — economically sustainable. USDC, issued by Circle and pegged to the US dollar, carries no price volatility risk and is widely supported by exchanges and wallets.

Further reading