> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zprotocol.org/llms.txt
> Use this file to discover all available pages before exploring further.

# MPP sessions

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. 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.