> ## 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. # Plans and pricing > The five billing modes, the per-plan verified-email gate, plan meter prices with unitSize and includedUnits, and the whole-cent and six-decimal precision rules. 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](/concepts/stores-services-meters). Together they determine what a 402 challenge costs and what an [allowance check](/concepts/usage-and-allowances) draws against. ## The five billing modes | Mode | For the buyer | For allowance checks | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `payg` | No purchase. Each call returns one priced 402 with the exact cost; pay and retry. | Covered by the verified per-call payment, by included units in free mode (claimed agents with a verified email only), or by a prepaid balance the buyer still holds. | | `credit` | Prepay a balance of at least `minimumPurchaseUsd`, call until it runs out, top up any time. | Passes while `remainingCreditUsd` covers the declared usage at the plan's prices; otherwise denied `usage_exhausted`. | | `subscription` | Purchase once at `basePriceUsd` for the period (day, month, or year). Calls are allowed while the period runs. The plan's meter prices are its inclusion list: price a meter at `0` to include it, and leave it unpriced to exclude it. The storefront shows each meter as Included or Not included per plan, and a call on an excluded meter is refused; when another plan includes it, the `plan_required` refusal names that plan. | Passes while the access period is current; a lapsed period is denied `plan_expired`. No usage balance is burned. | | `subscription_usage` | A subscription whose purchase also grants `includedCreditUsd` of usage; usage beyond it is metered and charged per call. Its meter prices are also its coverage list: a meter with no price row is refused; when another plan covers it, the `plan_required` refusal names that plan. | Passes while the period is current and the included credit covers the declared usage; beyond it, per-call charges take over. | | `free_trial` | A one-time free grant: claimed with the agent's bearer and no payment, one per human, optionally granting `includedCreditUsd` of trial credit — as proxy-burnable usage credit on an ordinary storefront, or a free standing account on a [stateful one](/integrate/stateful-sellers). `basePriceUsd` must be 0, `interval` must be `none`, and a storefront can hold one active free trial plan. | Like `subscription_usage`: passes while the trial credit covers the declared usage. | Plans carry an `interval` (`none`, `day`, `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 daily period lasts 24 hours. A daily renewal starts a fresh 24 hours when applied, including after a payment failure; missed days are not charged. A purchase creates the buyer's [access grant](/concepts/agents-and-access), 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](/integrate/stateful-sellers). ## 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](/integrate/stateful-sellers#tying-the-account-to-a-user-account) carrying `buyerEmail`, and proxied calls simply start carrying the [`zc-buyer-email` header](/resources/headers) 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: ```json theme={null} { "priceUsd": "0.002", "unitSize": 1000, "includedUnits": 0, "defaultMaxQuantity": 8192 } ``` A request that settles 4,523 output tokens costs 4,523 × $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](/integrate/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](/resources/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](https://dashboard.zeroclick.io) or with the [REST API](/api-reference/introduction). Agents always read live prices from the storefront's `manifest.json`, so a price change takes effect on their next call.