Usage-based products break when the only answer to "I need more" is "contact support."
That is not a billing edge case. That is revenue friction.
If your customer runs out of credits in the middle of a workflow, or their prepaid balance gets low right before an important job runs, the next step has to be obvious and immediate.
That is why Commet handles top-ups inside the Customer Portal.
Customers should not need a sales conversation to keep using the product they already chose.
Two ways customers need more capacity
Not every top-up is the same.
Commet supports two distinct self-serve patterns:
- Buy more credits
- Add more balance
They solve different problems.
Credit Packs
For Credits plans, the top-up model is Credit Packs.
The customer has a recurring plan that includes a credit allowance. When they need more, they can purchase additional packs directly from the portal.
That works well when the product experience is built around a shared internal currency:
- generate an image
- transcribe audio
- run an agent
- process a batch
Each action consumes credits. The customer does not need to think about raw infrastructure cost. They just need to know how much usable capacity they have left.
In Commet, purchased credits are separate from recurring plan credits. Plan credits reset each billing cycle. Purchased credits persist.
That distinction matters because it keeps the experience intuitive:
- the plan gives recurring allowance
- the pack solves short-term extra demand
- the customer does not feel punished for buying ahead
Balance top-ups
For Balance plans, the top-up model is direct money balance.
The customer sees remaining balance, usage deducts from it, and when needed they can add funds from the portal.
This is the right model when customers think in dollars, not credits.
It is especially useful for products where balance visibility is part of the product itself:
- infrastructure platforms
- compute-heavy tools
- platforms with multiple paid actions under one account
In Commet's portal, the customer can open the top-up flow, enter the amount they want to add, and charge the saved payment method already attached to the subscription.
Why this belongs in the portal, not in a custom back office flow
A lot of teams implement top-ups late.
At first, someone on the team handles it manually. Then demand grows and the workaround becomes part of operations:
- support creates payment links
- finance tracks ad hoc charges
- product has no clear remaining-capacity UX
- customers do not know whether to wait, upgrade, or ask for help
That is avoidable.
The portal is already where the customer expects to manage billing:
- subscription status
- invoices
- payment method
- plan changes
- current usage
- extra capacity purchases
Putting top-ups there keeps the lifecycle coherent.

What happens when a customer adds funds
For balance-based subscriptions, Commet's top-up flow is explicit:
- the customer chooses the amount in the portal
- Commet charges the saved payment method
- Commet creates a balance top-up invoice
- the usable balance increases by the top-up amount
Taxes are still handled as part of the payment flow, but the added usable balance reflects the top-up amount itself rather than tax-inclusive totals.
That matters because it keeps the commercial logic clean:
- payment records stay correct
- invoices stay auditable
- customer balance stays predictable
It also means top-ups are not a fake UX layer on top of invoices. They are part of the actual billing system.
Top-ups reduce support load, but more importantly they protect momentum
The biggest cost of missing top-up flows is not operational overhead.
It is broken momentum.
A user is trying to finish something:
- ship a campaign
- process a batch
- run another generation
- keep production traffic flowing
If they hit a limit and cannot resolve it immediately, you are not just creating inconvenience. You are creating a chance for churn.
Self-serve top-ups are a retention feature disguised as a billing feature.
Credits and balance should not feel the same
This is where many billing systems get awkward.
They treat all "extras" as one generic purchase path.
Commet does not.
Credits and balance have different buyer expectations:
- Credits feel like packaged product capacity
- Balance feels like spendable monetary value
The portal should reflect that difference. That is what makes the product feel coherent instead of improvised.
The operational payoff
When top-ups are part of the portal lifecycle, your team gets:
- less manual intervention
- fewer billing exceptions
- cleaner invoice history
- a clearer usage experience for customers
More importantly, your customers get a path forward without waiting for you.
That is the standard modern usage-based products should hit by default.
Read the Customer Portal documentation, configure Credit Packs, review Consumption Models, or try Commet in sandbox.