Skip to main content
A plan defines how agents pay a seller. Each plan has a billing mode, a few plan-level money fields, and a set of plan meter prices that put a price on each meter. Together they determine what a 402 challenge costs and what an allowance check draws against.

​
The five billing modes

Plans carry an interval (none, month, or year) that sets the access period a purchase grants, and three money fields:
  • basePriceUsd: what a subscription purchase charges; a whole-cent amount.
  • includedCreditUsd: the usage credit a subscription_usage or free_trial purchase grants; up to 6 decimals.
  • minimumPurchaseUsd: the smallest credit purchase a buyer may make; whole cents, default $0.01.
A purchase creates the buyer’s access grant, which later checks evaluate. Sellers that hand out accounts and API keys build on the same purchase and the same billing modes — see sell accounts and API keys.

​
The verified email policy

Every plan carries a verifiedEmailPolicy — off, requested, or required — controlling whether the buyer’s verified email is shared with you and whether it gates the sale:
  • off: nothing is ever disclosed. Purchases stay anonymous.
  • requested: never blocks a purchase. You receive the buyer’s verified email whenever one exists — immediately when the buying agent is already claimed, or later, the moment their human claims: stateful storefronts get a fresh account write carrying buyerEmail, and proxied calls simply start carrying the zc-buyer-email header on the next request. Recommended whenever you keep user accounts: fully autonomous agents can still buy, and when the human registers or signs in with that same email they find the entitlements their agents bought and can manage them like any other purchase.
  • required: purchases and top-ups are refused with a terminal 403 verified_email_required until the buying agent is claimed by a human whose email is verified — the same claim that unlocks free included usage. On a payg plan the gate applies to the calls themselves: every pay-as-you-go request needs the claimed credential before any 402 is offered, which adds real friction. Use required only when you cannot deliver without an email; requested shares it without blocking anyone.
Left unset the policy defaults by mode: required for free_trial (which is what keeps one person from farming unlimited free accounts), off for everything else. The catalog advertises verifiedEmailPolicy on each plan (with requiresVerifiedEmail: true echoed in the purchase block when the policy is required), so agents know to complete the claim before buying rather than discovering a refusal at purchase time — and know when a purchase will share their human’s email.

​
Plan meter prices

A plan meter price attaches a price to one meter on one plan, with one price per meter per plan:
  • priceUsd: the price, up to 6 decimal places.
  • unitSize: how many units priceUsd buys (default 1). priceUsd: "0.002" with unitSize: 1000 reads “$0.002 per 1,000 units”.
  • includedUnits: free units per billing period before priceUsd applies (default 0).
  • defaultMaxQuantity: an optional per-request ceiling, applied when a request declares neither a quantity nor a maxQuantity for the meter. Without a default, such an item is denied meter_not_priced.
Cost is quantity × priceUsd ÷ unitSize, rounded to six decimal places.

​
A worked example

Acme prices the output_tokens meter of its product-watch service on a credit plan at $0.002 per 1,000 tokens:
A request that settles 4,523 output tokens costs 4,523 × 0.002÷1,000=∗∗0.002 ÷ 1,000 = **0.009046**, deducted from the buyer’s remainingCreditUsd. A request that declares no token count up front is gated and authorized at the 8,192-token default ceiling (at most $0.016384). It settles at the actual count, and the remainder returns to the buyer. Charge up to a maximum covers ceiling billing from the seller’s side. If the price also carried includedUnits: 100000, the buyer’s first 100,000 tokens each period would be free, and priceUsd would apply only beyond them.

​
Two precision rules

  1. Money that settles on-chain is whole cents. Buyer-chosen amounts (credit purchases and top-ups) must be whole-cent values of at least minimumPurchaseUsd, and basePriceUsd is whole cents. Because ZeroClick charges a pay-as-you-go rate call by call, a payg plan’s priceUsd must itself be a whole-cent amount. The API rejects anything else with 422 payg_price_not_whole_cents (see errors).
  2. Catalog prices carry 6 decimals. Prices on credit and subscription plans only burn prepaid allowance, so they keep full 6-decimal precision: sub-cent rates like 0.000250 are normal there.
unitSize is how pay-as-you-go expresses sub-cent rates within the whole-cent rule: the credit-plan rate above becomes priceUsd: "2.00" with unitSize: 1000000 on payg. That is the same $0.002 per 1,000 tokens, stated as a whole-cent price per million.

​
Managing plans

ZeroClick sets up plans and prices with you during onboarding; you manage them afterward in the dashboard or with the REST API. Agents always read live prices from the storefront’s manifest.json, so a price change takes effect on their next call.