Prepaid credits on your meters

Customers prepay. Credits draw down per event.

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.

Why prepaid

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.

Credits Benefit

Attach credits to any product. Recurring grants on subscriptions, one-time grants on purchases.

Per-meter balances

Each meter carries its own balance, so different units stay isolated.

Customer State API

Read every active meter and remaining balance in a single call.

Top-up products

Sell credit packs as one-time products. Customers stack them on top of an existing balance.

Granting credits

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.

On a subscriptionCredits 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.
On a one-time purchaseCredits are granted once at checkout. Sell top-ups as standalone products and let customers stack them on an existing balance.

Balances and visibility

Read balances through the API, surface them in your product, or let customers manage them directly in the portal.

Customer State APIA single endpoint that returns every active subscription, every active meter, and the remaining balance for each meter. Built for the “credits remaining” widget.
Customer Meters APIDrill into a specific meter, inspect consumed and credited amounts, and read the events that moved the balance.
Credits-only spendingSet 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.
Customer PortalEvery customer sees their meters and remaining credits in the hosted portal. They can top up or check balance without contacting support.

Enforcement is yours

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.

Add a Credits benefit

Attach credits to a product and Polar handles the bookkeeping.