Customers prepay for usage and Polar deducts from the balance as events arrive. When the balance reaches zero, the meter falls back to your metered price or stops, depending on how you configure it.
Pure usage billing is honest with the customer, but it's also unpredictable. Opening an invoice that's four times larger than last month's makes any product feel volatile, even when the underlying behavior is correct.
Credits rebuild that predictability without giving up usage-based pricing. The customer prepays for a defined amount of usage, draws it down over time, and only pays again when they top up.
Underneath, credits ride on the meters you already have. Incoming events deduct from the credit balance first; only when the balance hits zero does the metered price kick in, and even that step is optional.
That choice is yours: charge the metered rate beyond the prepaid amount, or block usage entirely so the customer can never owe more than they paid up front.
Attach credits to any product. Recurring grants on subscriptions, one-time grants on purchases.
Each meter carries its own balance, so different units stay isolated.
Read every active meter and remaining balance in a single call.
Sell credit packs as one-time products. Customers stack them on top of an existing balance.
The Credits benefit attaches to any product and refills based on the product type. Add multiple Credits benefits to one product to grant credits across more than one meter.
Credits are granted at the start of every billing cycle. A monthly plan can include 1,000 prompt-token credits and 100 image-generation credits, tracked independently.
Credits are granted once at checkout. Sell top-ups as standalone products and let customers stack them on an existing balance.
Read balances through the API, surface them in your product, or let customers manage them directly in the portal.
A single endpoint that returns every active subscription, every active meter, and the remaining balance for each meter. Built for the “credits remaining” widget.
Drill into a specific meter, inspect consumed and credited amounts, and read the events that moved the balance.
Set up a meter with no metered price. The customer can never be billed beyond what they prepaid, and the API surfaces an empty balance for your application to handle.
Every customer sees their meters and remaining credits in the hosted portal. They can top up or check balance without contacting support.
Polar deliberately stops short of blocking usage on its own. When a balance hits zero, the API surfaces the empty state and your application decides what happens next.
That separation matters because the right response is context-dependent. Some flows should keep serving and bill the overage; others should prompt for an upgrade or throttle until the customer tops up. Those are product decisions, not billing ones.
Polar's job is to keep the balance accurate and the API current, so the rule you write in your code can rely on the number it reads.
Attach credits to a product and Polar handles the bookkeeping.