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

# Payment overview

Z accepts payment through three rails: Stripe (fiat top-ups and subscriptions), x402 (per-request on-chain payment), and MPP (machine payment protocol). All three feed a single unified credit pool. Inference debits the pool. The rail of origin is preserved for reporting but not for entitlement: a credit is a credit.

This page describes the three rails, how they compose into the credit pool, and how to choose among them.

## Three rails, one ledger

**Stripe.** Standard card or bank payments processed through Stripe. Subscription tiers bill on a monthly or annual cycle. Pay-as-you-go top-ups land as credit in the unified pool. Stripe is the right rail for organizations that prefer invoice-based accounting and for individual developers who do not want to manage on-chain payment infrastructure.

**x402.** Per-request settlement on-chain. The HTTP request includes a payment proof; the gateway verifies the proof against the relevant chain, debits the request from the proof's value, and serves the response. X402 is supported on Base and Solana, with USDC as the primary asset. The per-request cap is a gateway-policy invariant.

**MPP.** Machine Payments Protocol sessions. The client pre-authorizes a session balance through a Stripe PaymentIntent in deposit mode, settled in USDC; the balance is then drawn down per request within the session. At session close, surplus is released by Stripe to the agent's originating account. It is never credited to a Z internal balance. MPP is the additive rail alongside x402 per-request and Stripe top-up, for streaming microtransactions where per-request settlement would add overhead.

## The unified credit pool

Regardless of which rail funds an account, the credits land in a single pool. Inference requests place a hold against the pool at request initiation and finalize the hold at completion. The debit order is Virtual Credits first, then Hard Credits FIFO by grant date. Promotional credits drain before paid balance.

Zero Completion Insurance applies on every rail: if a request fails to produce a valid completion, the hold is released to zero. The credit pool reflects the zero charge.

The implication for integrators: an account can be funded from multiple rails simultaneously, and the gateway does not require the integrator to specify which rail to debit. The debit comes from the pool. A subscription user can top up with an x402 payment for a one-off heavy workload without creating a separate billing relationship; an agent paid in USDC via x402 can be granted additional credits by a human operator via Stripe.

## Choosing a rail

The right rail depends on the principal model.

* **Developer or organization with invoice accounting:** Stripe. Subscription plans for predictable usage; top-ups for surge capacity.
* **Agent operating with its own wallet:** x402. Per-request settlement matches the agent's transactional model.
* **Streaming or high-frequency workload from a wallet-native principal:** MPP. Avoids per-request settlement overhead while preserving wallet-native control.
* **Cross-organizational integration where the funding party and the consuming party are different:** mixed rails. The funder can use any rail; the consumer debits from the pool.

## Zero Completion Insurance

Every rail supports Zero Completion Insurance as a first-class billing primitive. ZCI is not a refund policy and is not contingent on a support request. It is implemented at the billing-state-machine level: a request that does not produce a valid completion for any reason inside Z's control (routing failure, predispatch error, content filter rejection, attestation failure, byte envelope violation, upstream timeout) finalizes the hold at zero.

For Tier 4, settlement uses only the silicon-signed `z_metadata` SSE trailer. An unverified trailer is never written to the billing ledger. This means an attempt to inflate token counts from a compromised TEE cannot bypass the gate; either the trailer's silicon signature verifies, or the request is treated as a non-completion.

## Credit reconciliation

All x402 surplus and ZCI overage credits pass through a write-ahead reconciliation ledger before final database application. The intent is to prevent the failure mode where a crash between on-chain settlement and credit write results in unrecoverable silent credit loss. The reconciliation ledger is replayable; in any failure scenario, the ledger is the source of truth for what was settled and what should be credited.

## What this section covers

The remaining pages in this section describe each rail in detail:

* [Wallet-native settlement](/docs/payments/wallet-native): SIWE/SIWS authentication and x402 per-request payment.
* [MPP sessions](/docs/payments/mpp-sessions): machine payments protocols.
* [Subscription tiers](/docs/payments/subscription-tiers): Stripe-billed plans and rate limits.