A&A INSIGHTS
How to explain credits in an AI SaaS plan: show the usable amount and the extra spend
The first decision in a credit system is not the unit price. Using Stripe primary sources, this article sets out what to publish about which operations consume credits, how they are granted and expire, and which balance to display.
日本語で読む
THE STARTING POINT
Written for the founder of a small team selling an AI tool whose per-use cost no longer fits a flat monthly price. Reading Stripe's published Lovable account alongside Stripe's billing-credits reference, it treats credits as a promise that lets the buyer forecast spend, not a unit for hiding price. Granting, consuming and expiring are separate settings, the specification excludes some charges from credits, and six lines are proposed for the plan page. Source statements, A&A interpretation and hypothetical examples stay distinct; no price or adoption result is claimed.
The first decision in a credit system is not the unit price
A&A perspective
When you are still deciding whether to move to credits, the first question is not what one credit should cost. It is whether a buyer who reads your plan page can apply it to their own usage and answer two questions unaided: how many more runs do I get this month, and where do extra charges begin. When a small team cannot absorb per-use inference cost inside a flat monthly price, it is tempting to treat a finer unit as a way to soften the impression of the price. Design in that direction and the buyer loses the ability to forecast their own spend, which returns later as support volume. A&A recommends designing credits not as a unit for hiding price but as a promise that spend stays predictable. That is an editorial position, not a recommendation of any particular price or ratio.
From the sources
Stripe's published customer story about Lovable says the company used Stripe Billing at launch to stand up a range of subscription plans quickly, including a free tier for individuals and paid tiers that offer graduated levels of monthly usage credits and specialised features. This is a vendor account published by Stripe on its own site, not an independent third-party audit.
The plan shape visible in Lovable: a free tier and graduated monthly credits
From the sources
The same page says that to support the 2025 launches of Lovable Cloud and Lovable AI, the team used Stripe's usage-based billing features and was able, in just two weeks, to define meters and rate cards, ingest real-time usage, and bill customers automatically for actual consumption.
From the sources
The page further states that Lovable now has millions of usage-based billing subscriptions on Stripe, translating to 4.6 million credits granted each month. That figure describes Lovable's scale as reported on Stripe's page; it is not a forecast for another company and not an achievable benchmark.
A&A perspective
What a small team can carry away from this account is neither the amount nor the scale, but the shape of the plan as the buyer sees it. The free tier expresses that the product can be tried; the graduated credits express how much can be used. To a buyer, in other words, a credit is not the name of a feature but a promise about quantity. And once it is a promise about quantity, the plan table is unreadable unless you can explain when that quantity increases, what actions reduce it, and when it disappears. The rest of this article reads Stripe's own billing-credits reference to confirm that those three are separate settings.
| Line to publish on the plan page | What the buyer can check | What happens if it stays undecided |
|---|---|---|
| Which operations consume credits | They can estimate how many runs a month their own usage buys | Repeated questions about why the heavy operation drew down so much |
| How much is granted each month, and whether it rolls over | They know what happens to an unused balance | Refunds and rollovers get negotiated case by case |
| The top-up unit, and the behaviour if they do not top up | They can read the spend of a month that exceeds the allowance | Work stops without warning, or an unexpected invoice arrives |
| Where the balance is shown and when it refreshes | They can check spend in the middle of the month | The balance on screen disagrees with the invoice |
| Which items cannot be paid with credits | They know which costs are billed separately | A dispute over being invoiced after prepaying |
| Promotional credits kept distinct from purchased ones | They do not misread the expiry of the free portion | An expiry is received as a price increase |
Granting, consuming and expiring are not one switch
From the sources
Stripe's billing-credits reference splits credit grants into two uses. One is prepayment, where the customer buys credits that pay for usage-based products or services. The other is a promotional offering granted for free, and the document notes that businesses often offer a limited amount of promotional credits, and typically with an expiration date.
From the sources
The same reference lists the states a credit grant can hold — pending, granted, depleted, expired and voided — and states that credits will not expire unless you set the expiry field. It also says that credits apply to invoices only at the time of finalization, so credits shown on a preview or draft invoice may change if a finalized invoice consumes them first.
A&A perspective
Read that way, granting, consuming and expiring are not a single linked switch but three independent settings. In A&A's reading the one most often published while still ambiguous is expiry. Ship without stating whether an unused balance rolls over and the handling of leftover credits becomes a monthly support thread, with refunds decided case by case. Two suggestions follow. First, decide the expiry default before the plan page goes live. Second, do not use the same word on the plan page for promotional credits and for credits the customer paid for. The specification already treats them as different uses; merging them into a single on-screen balance means the expiry of the free portion will be received as a price increase.
The specification itself excludes some charges from being paid with credits
From the sources
The same reference limits what credit grants can be applied to. You can only apply credit grants to subscription items that use metered prices and report usage through Meters. They cannot be applied to one-off invoices that were not created by a subscription, to one-time invoice items such as an initial setup fee, or to line items that use licensed prices.
From the sources
It also lists prohibited uses: you cannot issue billing credits as gift cards or gift certificates, cannot allow customers to use them for payments to third parties, cannot link them to digital wallets, and cannot offer billing credits as stored value to your customers. A further operational ceiling is stated as well: customers can have up to 100 unused credit grants at a time.
A&A perspective
This next step is A&A's reading. Describing credits as a prepaid wallet that pays for anything agrees with neither the specification nor its terms. If you bill separately for setup assistance, data migration, human review work or individual consulting hours, those charges sit on the side that credits cannot pay. In small AI services that separately billed portion often carries the margin, so leaving it vague on the plan page produces exactly the dispute where a customer who prepaid receives another invoice. Publishing two short lists side by side — what credits pay for, and what is billed separately — settles this faster than a discount negotiation does.
Two numbers a balance display must not merge
From the sources
On balances, the same reference separates the ledger balance from the available balance. The ledger balance reflects the credit balance after recording all relevant account ledger transactions, while the available balance is described as equal to the ledger balance less any expired credits or unrecorded transactions. Because of that, a grant can hold a zero available balance while its ledger balance remains positive.
A&A perspective
Unless you decide which of the two the product shows, the balance the customer sees and the invoice they receive will disagree. A&A's suggestion is to show only the available balance on customer-facing screens and to use the ledger balance for internal reconciliation. Alongside the number, publish one line saying when it refreshes and whether it can sit still during month-end processing. Customers want to check their spend just before launching an expensive run, not when the invoice arrives at the end of the month.
Hypothetical example
A hypothetical example makes this concrete. Imagine a proofreading AI service that grants 1,000 credits at the start of each month, charges 50 credits for one bulk run over a long document and 1 credit for checking a short passage. Suppose the customer has consumed 800 credits by month end while the billing cycle is still closing; some of those credits may already sit on a draft invoice. A screen showing the ledger balance would read 200, while a screen showing the available balance could temporarily read zero. At that exact moment the customer has to decide whether to top up. This is an invented situation used to test the reading of the specification; it is not a real customer record and not a measurement by A&A.
Six lines to publish on the plan page
A&A perspective
The argument above collapses into six lines to fill in before you publish. Which operations consume credits. How much is granted at the start of the month, and whether it rolls over. The top-up unit, and what happens if the customer does not top up. Where the balance is displayed and when it refreshes. Which items cannot be paid with credits. And how promotional credits are kept distinct from purchased ones. The same six lines appear as a table later in this article. If all six are filled, a buyer can estimate their own monthly bill without talking to sales. Any line left blank is where a future support thread and a future discount negotiation will start. This is a format A&A proposes, not a statement of legal contract terms or of any particular price.
Hypothetical example
Here is a hypothetical filled-in version. The consuming operations are limited to two, bulk proofreading of long documents and checking short passages, while image generation is left outside credits for now and placed on a separate plan. The grant is 1,000 credits at the start of the month with no rollover. Top-ups are sold in units of 100 credits, and if the customer does not top up, processing stops rather than shifting to metered overage. The balance appears at the top of the admin screen and refreshes as each run completes. Setup assistance and the work of a human reviewer are outside credits and quoted separately. Promotional credits carry an expiry date and are displayed on their own line, separate from purchased credits. With those decisions made, the plan-page copy itself takes half a day to write. This is an invented service configuration, not an A&A or customer result.
What this article does not guarantee
A&A perspective
Three limits are worth stating. First, the Stripe behaviour quoted here is the documentation as read at access time and its conditions can change; reread the current reference immediately before you implement. Second, what Stripe published about Lovable is a vendor account rather than an independent audit, so the scale figures it contains are neither a forecast for another company nor evidence that credit pricing causes growth. Third, this article does not tell you what one credit should cost. That price comes from your own inference cost, the hours your team spends reviewing output and your expected usage frequency; copying another company's unit will not make your margin work.
A&A perspective
The next step is to count how many of the six lines are still blank. If all six are filled, the remaining work is writing the copy. If two or more are blank, go back to the product decision about which operations are billable before rewriting the price table. If you first want the whole picture from acquisition through continued use, read AI-native GTM: a practical guide for solo founders and small teams, which places this pricing decision in its wider context. When you cannot settle internally which operations should be the billable unit, an advisory conversation fits. When the operations are already decided and the open problem is metering and billing implementation, scoping it as a development engagement moves faster.
Designing a credit system does not begin with the unit price. Decide which operations consume credits, when credits are granted and when they expire, which of the two balances the product displays, and which items credits cannot pay for. Publish those four on the plan page and a buyer can forecast their own spend without asking sales. Whatever you leave undecided comes back later as a discount negotiation and a support thread.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Riding the AI boom: How Lovable grew into a vibe-coding juggernaut with Stripe
Stripe · n.d.
Accessed 2026-09-24 - Billing credits | Stripe Documentation
Stripe · n.d.
Accessed 2026-09-24
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-09-24