Skip to main content
ZeroClick accepts two agent payment protocols: x402 and MPP, the Machine Payments Protocol. 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, 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. Inside the 402 body, each offered rail appears as a block under protocols, alongside ZeroClick’s own payment block with the exact USD amount:
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, 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 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, check the allowance, serve, and settle usage. When ZeroClick adds a new payment protocol, sellers ship nothing. For the protocols themselves, see x402.org and mpp.dev.