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

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