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

# Payment protocols

> How ZeroClick uses x402 and MPP: challenge and proof headers, minted deposit addresses, reserve rails for ceiling charges, and settlement.

ZeroClick accepts two agent payment protocols: [x402](https://www.x402.org) and MPP, the [Machine Payments Protocol](https://mpp.dev). Both settle USDC. This page explains how ZeroClick uses them, not how they work internally; as a seller you never implement either. Your API sees only signed, already-paid requests, and the billing guard is identical whichever rail the buyer chose.

## The two rails

Both protocols follow the same loop: ZeroClick answers an unpaid request with the [single priced 402](/concepts/how-zeroclick-works), the agent signs the challenge with its wallet, and the retry carries the proof in a standard header. An anonymous challenge offers both protocols and lets the buyer pick by paying; a buyer that already authenticated on one rail is challenged on that rail.

|                                  | x402                                                                                | MPP                                                 |
| -------------------------------- | ----------------------------------------------------------------------------------- | --------------------------------------------------- |
| Challenge rides in               | `payment-required` response header (and the standard x402 document in the 402 body) | `www-authenticate` response header                  |
| Proof rides in                   | `x-payment` request header (signed payment payload)                                 | `authorization: Bearer <credential>` request header |
| Settles                          | USDC on Base (`eip155:8453`)                                                        | USDC on Tempo                                       |
| Fixed-quantity charges           | `exact` scheme                                                                      | one-shot charge                                     |
| Ceiling charges                  | `upto` scheme (reserve, settle at actual)                                           | session escrow channel                              |
| Receipt header on paid responses | `payment-response`                                                                  | `payment-receipt`                                   |

Inside the 402 body, each offered rail appears as a block under `protocols`, alongside ZeroClick's own `payment` block with the exact USD amount:

```json theme={null}
{
  "error": "payment_required",
  "zcRequestId": "zcreq_8h2m4x0q9k1f",
  "payment": { "id": "apay_…", "amountUsd": "0.010000" },
  "protocols": {
    "x402": { "x402Version": 2, "network": "eip155:8453", "scheme": "exact", "amount": "10000", "asset": "0x…" },
    "mpp": { "challengeId": "…", "method": "tempo", "intent": "charge" }
  }
}
```

The challenge an agent signs embeds ZeroClick's payment metadata (the `payment.id` and `zcRequestId` above), so the signed proof is all a retry needs. Identity-only challenges use the same machinery at amount zero: proving wallet control is always free, and nothing settles on-chain for them.

## ZeroClick mints the deposit address

Every priced challenge pays into a deposit (`payTo`) address that ZeroClick minted for that specific payment. Buyers pay exactly the address the challenge specifies. Sellers never publish, rotate, or even see these addresses.

## Ceiling charges need a reserve rail

A [ceiling-priced request](/integrate/charge-up-to-a-maximum), one whose usage item declares a `maxQuantity`, authorizes the most the call could cost, but must charge only actual usage. That is possible only on the reserve-and-pay-actual rails, so a ceiling challenge offers exactly these:

* **x402 `upto`**: the wallet reserves the ceiling; ZeroClick settles the actual amount after delivery, and the reserved remainder never leaves the buyer's wallet.
* **MPP session escrow**: the buyer funds a channel to the ceiling and signs one voucher; ZeroClick closes the channel at actual usage, and the escrow refunds the rest. If the close ever fails, the buyer can force-close after the on-chain grace period, so escrowed funds are never stranded.

ZeroClick never offers one-shot prepay (`exact`, or the MPP charge) for a ceiling: that is what guarantees an unspent ceiling cannot get stuck as seller credit. If neither reserve rail is available for a capped price, ZeroClick refuses to mint an unpayable challenge and returns `503 capped_pricing_unavailable` instead. A failed delivery debits nothing on either rail, and every per-call paid response reconciles authorized versus charged in the `zc-billing` header.

## Amounts and settlement

Two money rules shape what the rails carry:

* Amounts that settle on-chain as a single charge are **whole cents**: plan purchases, top-ups, subscription base prices, and pay-as-you-go rates. Catalog prices on credit and subscription plans keep 6-decimal precision, because they only burn prepaid balance. [Plans and pricing](/concepts/plans-and-pricing) covers both rules.
* Buyers pay USDC, but your revenue settles to your connected Stripe account (in fiat or USDC, your choice). You never operate a wallet to sell through ZeroClick.

## Sellers stay protocol-agnostic

Nothing protocol-specific ever reaches your API. ZeroClick strips payment headers before forwarding, and your integration is the same four steps on every rail: verify the [signature](/integrate/verify-requests), [check the allowance](/integrate/check-allowances), serve, and [settle usage](/integrate/settle-usage). When ZeroClick adds a new payment protocol, sellers ship nothing.

For the protocols themselves, see [x402.org](https://www.x402.org) and [mpp.dev](https://mpp.dev).