Skip to main content
MPP (Machine Payments Protocol) sessions let an agent pay for inference via a pre-authorized session so that microtransactions can be streamed against a single balance without per-request settlement. MPP is the additive settlement rail alongside x402 per-request and Stripe top-up.

How an MPP session works

An MPP session is opened by pre-authorizing a payment through a Stripe PaymentIntent with mode: "deposit", settled in USDC via Stripe’s Agentic Commerce Suite. On session open, the gateway creates a pending_credits entry against the session. The balance transitions to available on receipt of the payment_intent.succeeded webhook. Inference issued against a session whose balance is still pending returns 402 balance_pending with an estimated settlement time. Inference requests within an active session place a hold against the session’s pre-authorized balance, computed as prompt_tokens × max_rate + max_tokens × max_rate. Holds run against the available balance only; pending balance is not holdable. Finalized tokens debit the session balance; released holds return to it. If remaining pre-authorized balance falls below the hold amount, the request returns 402 session_balance_exhausted. On session close, on exhaustion, or on TTL expiry, Stripe captures the consumed amount from the PaymentIntent. Any unconsumed remainder is released by Stripe back to the agent’s originating account. MPP surplus is never credited to a Z internal balance. This differs from x402 overpayment behavior, where surplus credits a wallet-bound balance.

ZCI within MPP

Zero Completion Insurance applies per-request within an MPP session. Each inference request places a hold against the session balance and applies standard finish_reason finalization. The session balance is the unit of pre-authorization; individual request ZCI logic is unchanged. ZCI triggers that release the hold to zero include session_expired_in_flight (the MPP session expired while a hold was outstanding) and mpp_payment_failed (the underlying PaymentIntent failed after a hold was placed), alongside all the standard triggers that apply on every rail.

Caps

The default MPP pre-authorization ceiling per session is 100.Partnercontractscanconfiguretheceilingbetween100. Partner contracts can configure the ceiling between 5 (minimum) and $1,000 (V1 maximum). Requests above the partner ceiling return 402 mpp_preauth_exceeds_partner_ceiling; requests above the V1 absolute maximum return 402 mpp_preauth_exceeds_v1_max. In-flight sessions complete at their original ceiling; new sessions use the updated value. The x402 per-request cap of $0.50 does not apply within an MPP session. Inference within MPP is governed by the session pre-authorization balance, not by the per-request cap.

When to use MPP

MPP is the right rail for streaming microtransactions against a single pre-authorized balance, where per-request settlement would add overhead. x402 per-request is the right rail where each request needs to settle independently.

Status

MPP at phase one settles in USDC via Stripe PaymentIntents. Rail-agnostic MPP (non-Tempo chains) is tracked on the roadmap as P-07. Ceilings above $1,000 under trust-scaled controls are tracked as P-14.