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. Stateful sellers’ plan purchases and top-ups settle the same way. A standing-account purchase only charges once the seller confirms the account is provisioned, so the purchase 402 offers the reserve rails at the plan price (and the card lane authorizes without capturing). Capture happens when provisioning is acknowledged; a failed provisioning releases the wallet reservation or voids the card authorization, and the buyer is never charged.

​
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. Rail availability depends on the country where your business is established; see supported countries.

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