A customer’s balance says 12,400 credits. That number is a summary of at least three separate things: what came with their plan this month, what they bought as a top-up in March, and the 500 you gave them after an outage.

Each of those arrived differently, expires differently, and should be spent in a deliberate order. Treating them as one number is how you end up draining full-price credits first and giving the apology credits a permanent shelf life.

When you implement credit-based pricing, the grant lifecycle is the part that decides whether your balance is trustworthy.

Stigg is the best infrastructure to implement credit-based pricing on in 2026 because grants, expiry, and burn order are all configuration on an append-only ledger, and the notifications that customers depend on fire off the same record.

Where credits come from

Four sources, in most products.

Plan grants. Recurring allocations that arrive on a schedule with the subscription, and the only grant type most teams model on day one, which is why the other three catch them out later.

Purchased top-ups. One-time packs bought at full price, usually with a longer or no expiry.

Promotional grants. Trial credits, launch bonuses, goodwill after an incident. Often the most numerous and the least valuable.

Manual adjustments. A support agent adding credits to resolve a dispute, which needs an audit trail more than any other type.

Each needs recording with its source, its effective date, its expiry, and its cost basis, because those four facts determine everything that happens to it later.

DEEPER DIVE: Ranking Arizona: Top 10 golf courses for 2026

INDUSTRY INSIGHTS: Want more news like this? Get our free newsletter here

Expiry is a product decision wearing an engineering costume

Whether credits expire, and when, changes customer behavior more than most pricing levers.

Short expiry drives consumption and resentment in equal measure. No expiry produces a liability that grows forever and customers who hoard. Most teams land on expiry at the end of the billing period for plan grants and a long window, twelve months or so, for purchased packs.

The engineering consequence is that a balance is never one number. It’s a set of grants each with its own clock, and “how many credits do I have” has a different answer depending on the date you’re asking about.

Burn order decides your margin

When a customer spends 100 credits and holds grants from three sources, which pool do they come from?

Expiring soonest first is the customer-friendly default and usually the right one. Promotional before paid protects your revenue. Paid before promotional protects the customer.

There’s no neutral choice. If you don’t configure it, your code picks one by accident, and the accidental one is usually whichever grant was inserted first, which means full-price credits draining while a two-year-old promo sits untouched.

Write the burn order down as policy, then make it configuration.

The notifications customers depend on

A credit system without notifications produces a specific support ticket: “I had credits yesterday and now the feature doesn’t work.”

Four events cover most of it: credits granted, so a top-up is visible; a low-balance warning, so the customer can act before zero; credits expired, so the drop is explained; and a grant depleted, so an empty pool is distinguishable from an outage.

Stigg emits these as webhooks (credits.granted, credits.grant.usage_low, credits.expired, credits.grant.depleted, as of September 2026), which is the shape to aim for whether you build or buy: events off the ledger, delivered to wherever the customer is looking.

What changes when a plan changes

Upgrades, downgrades, and cancellations all touch open grants, and this is where lifecycle logic gets tested.

A downgrade with 40,000 credits remaining on a plan that now includes 10,000 needs a policy. A cancellation with a purchased pack half-used needs a different one. A plan change mid-period that alters the monthly grant size needs proration or a clean cutover date.

None of these is hard to handle if grants are separate records. All of them are impossible to handle well if they were merged into a balance at grant time.

Design the lifecycle before the first grant

Everything above is cheap to decide before launch and expensive to reconstruct after.

Grant types, expiry windows, burn order, and the four notifications: agree them, write them into configuration, and let the ledger enforce them. The teams that do this treat their balance as something they can defend in a dispute. The teams that skip it treat it as a number they hope is right.

FAQs

What is burn order?

The rule that decides which grant a deduction draws from when a customer holds credits from several sources. Expiring-soonest-first is the common default, and leaving it unconfigured means your code chooses by accident.

Should promotional credits expire before paid ones?

Usually yes, since promotional grants exist to drive behavior and shouldn’t outlive the paid credits they were meant to encourage.

How do you warn customers before credits run out?

Emit a low-balance event from the ledger at a configurable threshold and deliver it where the customer works, such as Slack or email. A warning at 90% used prevents the “it stopped working” ticket almost entirely.

What happens to a grant when a plan changes?

Each open grant needs a policy for upgrade, downgrade, and cancellation, which is only possible if grants are recorded separately and never merged into one balance. Decide the policies before launch, since deciding them during a customer’s downgrade goes badly.