Credit-Based Pricing
Credit-based pricing is usage-based pricing paid up front. The customer buys a balance of credits, the credits sit in their account, and each action in the product spends some of them, whether that is an audiobook, an API call or a data enrichment run.
Credits have taken off because they fix the weak spot in each older model:
| Model | Cash for the vendor | Risk for the customer |
|---|---|---|
| License | High, paid up front | High, use it or lose it |
| Usage-based | Poor, paid after usage | Low |
| Credits | High, paid up front | Lower, unused credits roll over |
Potio’s take: Credits are the hybrid that works for both sides. The vendor gets cash up front, and the customer takes less risk because unused credits carry over for a while instead of vanishing. Credits also change how customers behave, and most of the benefit sits in that behaviour.
How this plays out
Four behavioural effects kick in once customers hold credits:
- They spend more freely. Credits feel like money already spent, so customers use the product with less hesitation than under pay-as-you-go.
- They churn less. A customer with credits left at year end stays to avoid burning cash they already paid. A license customer in the same spot thinks “I overpaid last year” and downgrades or leaves.
- Contracts stay flexible. The customer buys credits, not specific features, so the exchange rate can change, for example from 10 credits per action to 15, without renegotiating the contract.
- Upgrades surface on their own. A customer six months into a 100-credit annual commitment with 10 credits left has not hit a wall. They adopted faster than planned, and that is the moment for a self-serve upgrade or a sales call.
Credit systems come in two shapes. Single-use credits buy one thing at a fixed rate: one Audible credit is one audiobook. Multi-use credits work as a currency across the product, as at OpenAI, Lovable or Clay. That replaces separate prices per API call, per gigabyte and per user with one unit, and it can even carry a subscription inside it, such as 10 credits a month to unlock a feature alongside 1 credit per API call.
Execution comes down to four things:
- Simple maths. Keep the exchange rate on a log scale: $1 = 1 credit, $1 = 100 credits or $10 = 1 credit.
- Real-time visibility. A dashboard showing exactly where credits go.
- Predictability. A forecast such as “you’ve used 50% of your credits in six months, you’re on track.”
- Controls. Admins and finance can cap who spends credits and how much.
On terms, keep the entry point easy and let customers buy the volume they want. Never refund unused credits as cash, because a vendor that hands money back starts to look like a bank. Burn the oldest credits first, and base each renewal on what the customer actually spent last period.
Are credits the same as usage-based pricing?
They are usage-based pricing paid in advance. Pure usage pricing bills after consumption, while credits are bought first and drawn down, which gives the vendor cash up front and the buyer a fixed budget.
Should AI credits expire?
Yes, but not quickly. Potio’s default is a 24-month lifespan: credits bought in year one roll into year two and expire if still unused at the end of year two. Expiry has to exist, because credits that never lapse become an open liability, and refunds are off the table.
More on this: Consumption Based Pricing: The Hard Truth for SaaS
Related terms
Pricing consulting for
SaaS and AI companies.
I'm a 3x founder and former CEO of Toggl. I work hands-on with SaaS & AI teams to fix pricing, packaging and monetization.
Book a call