Different Types of Billing: 8 Models and How to Choose

You pick a billing model in a pricing meeting. Six months later, engineering is debugging duplicate usage, finance is asking why an invoice changed mid-cycle, and one customer has burned through a credit balance faster than the meter caught up.

In production, the different types of billing change what you have to meter, store, reconcile, and enforce.

Here’s how the main models differ and what each one asks from your systems.

Billing methods vs. billing systems

Billing methods define how you charge customers, while billing systems run the work required to apply those rules. A billing method is the commercial model, and a billing system is the product infrastructure behind it.

How billing methods and systems work together

Billing methods come first because they set the rules that billing systems need to apply. A monthly subscription may need recurring invoices and proration. Usage-based pricing needs accurate metering and rating. A credit-based plan needs balance tracking and atomic deductions.

Choose the commercial model first, then identify the systems required to support it.

8 different types of billing methods and what each system needs

The useful comparison is less about what each model is called and more about what your systems have to get right once customers start using it.

state instead of a calendar.

1. Subscription billing

Subscription billing charges a recurring amount on a schedule, often monthly or annually. It suits products that deliver ongoing value through access, seats, or a recurring allowance.

ChatGPT is a familiar subscription example. Its paid plans are priced per month, from the $8 Go tier through Plus, Pro, and Business, with Business billed per seat for teams.

Customers like knowing what the next invoice will look like, and finance teams get more predictable revenue. The model starts to get complicated once a customer changes plans between renewals.

A customer may upgrade halfway through the month, convert a trial early, or lose access after a failed payment. Each change affects the price, entitlements, and access rules. Subscription lifecycle management keeps those pieces connected.

It’s the commercial state around that charge that creates challenges.

Subscriptions need thoughtful limits when activity varies sharply between accounts. A fixed fee can work well with included usage, clear caps, or costs that stay fairly consistent.

2. Flat-rate billing

Flat-rate billing charges one price for a defined product or service. It gives customers a simple answer to what they will pay and keeps the pricing page easy to scan.

Basecamp uses this model with its Unlimited plan, which costs $299/month billed annually and includes unlimited users and projects. 

This model works well when customer value and delivery cost stay close across the customer base. A small team may pay one monthly fee for access to a product with a clear set of features and light usage.

The tension appears when customer activity starts to vary. One account may use a feature a few times each week, while another runs high-volume workflows throughout the day.

One price can cover very different levels of infrastructure, model, and support cost.

Flat-rate pricing remains useful for simple offers and early products. Many teams add limits or an overage path once high-usage accounts begin to affect margins.

3. Tiered billing

Tiered billing applies different prices across defined usage bands. It gives customers a lower unit cost as their consumption reaches higher thresholds.

For example, the first 10,000 requests may have one rate, the next 40,000 another, and higher volumes a third. Customers can see how their price changes as they grow, while the business can support larger accounts without one fixed rate for everyone.

Amazon S3 uses graduated storage tiers, where higher usage moves additional storage into lower-priced bands while earlier usage keeps its original rate.

Plan tiers and billing tiers are easy to mix up. Starter, Pro, and Enterprise describe how a product is packaged, and billing tiers calculate the price of measured consumption.

The edge cases appear around the boundary. Usage can arrive late, several requests can arrive together, or a customer can change plans partway through the billing period.

Tiered pricing depends on a shared view of the meter, the tier boundary, and the active pricing version. A pricing spreadsheet cannot resolve event timing in production.

4. Usage-based and metered billing

Usage-based billing charges customers for measured consumption. The unit might be an API call, compute minute, document processed, gigabyte stored, model request, or completed agent run.

The model fits products where activity drives customer value and operating cost. A company that uses ten times more processing pays more, which can make pricing feel fairer across a wide customer base.

A metered billing system needs to:

• Collect and validate events before they enter the billing pipeline
• Attribute usage to the correct customer, workspace, or project
• Deduplicate retries before they create another charge
• Aggregate usage within the correct billing period
• Apply pricing rules based on the active plan and rate
• Reconcile results before usage reaches the invoice

Retries show why each step matters. A client may time out and send a request again while the original request finishes in the background. Idempotency keys and deduplication keep one customer action from becoming two billable events.

Monthly invoicing can handle some delay in aggregation. Current usage state matters more when each request consumes an allowance or can trigger a costly workload.

5. Credit, token, and wallet billing

Credit, token, and wallet billing gives customers a prepaid balance that depletes as they use the product. This turns variable consumption into a unit customers can understand, purchase, and track.

A short request may call one model. A larger workflow may search files, call tools, run several models, and create follow-up actions. Credits give both actions a clear customer-facing price, even when the underlying cost differs.

Lovable uses credits as the customer-facing unit for product usage. Its system tracks credit balances, top-ups, usage, and which actions consume credits, giving users a clearer way to follow consumption as they build.

The simple version is a balance counter. Production use brings harder cases: two requests draw from the same wallet at once, promotional credits expire before paid credits, and refunds need to restore a previous debit.

Credit pricing relies on a ledger that records every grant, debit, refund, expiry, and manual adjustment.

Token-based pricing adds one more decision. Raw token costs can change as providers and models change, so the unit customers buy needs to stay clear even when the infrastructure beneath it changes.

6. Project and time-based billing

Project and time-based billing charges for completed work, elapsed time, or defined milestones. It is common in implementations, consulting engagements, data work, and larger deployments.

A contract may bill at kickoff, after a migration, and at customer acceptance. Another agreement may bill approved hours each month or reserve a set amount of delivery capacity through a retainer.

The billing record depends on project status as much as product activity. Teams need a shared definition of what counts as complete, what work is billable, and how a contract change affects the payment schedule.

The invoice follows the delivery process.

This model often sits alongside the core product charge. An annual software agreement may include a one-time implementation fee and a separate services agreement with milestone payments.

7. One-time and prepaid billing

One-time billing collects a single charge, while prepaid billing collects funds before related usage occurs. Both are useful for onboarding, implementation work, hardware, and funded consumption.

Replicate puts the balance first. Teams buy credit upfront, and each model run reduces the available amount.

Think of a customer who buys a $5,000 usage pack at the start of a quarter. The company receives the payment first, then the customer draws down that value as requests run.

A one-time fee has a clear beginning and end, such as an onboarding package or private deployment. Prepayment creates an ongoing balance that the product needs to check before allowing more consumption.

Payment and access are separate pieces of state. The financial record shows that funds arrived, and then the product balance shows how much value remains available.

Once the customer starts using the product, the payment record and available balance need to stay aligned.

An expired card should not affect a balance already funded, and a refund may need to reverse unused value. Access rules need current balance data, while finance tracks revenue as the customer consumes the prepaid amount.

8. Hybrid billing

Hybrid billing combines two or more billing methods in one commercial model. It can pair a recurring platform fee with charges tied to customer activity.

Cursor offers a hybrid example. Its paid plans include a set amount of model usage, then on-demand charges can apply after the included amount is consumed. 

A typical contract might include a monthly platform fee, five seats, 10,000 included credits, and an overage rate after those credits run out. Larger accounts may also have annual commitments, shared team balances, or custom rates.

This setup gives customers a predictable base price while letting the bill rise with heavier use. It also means several pieces of customer state can change at once.

Take a renewal at midnight. The billing period changes, new credits are granted, the active plan may update, and automated jobs may start seconds later. The system needs to answer three questions for every job:

• Which plan applies right now?
• Which balance should the job consume?
• Which rate applies if the included allowance is gone?

A hybrid pricing model needs clear ownership of those records. Subscriptions, usage events, wallet balances, and invoice rules need the same view of the customer.

Problems appear when those records update at different times. The product can allow a request under a new limit while the billing layer still applies an older rate.

How to choose the right billing type

Choose the billing type that matches how customers receive value, how your costs grow, and what your product can measure in production. The best model should make sense on the pricing page and hold up when real customer activity hits the system.

A team may like the simplicity of one monthly price, then discover that a small group of accounts generates most of its model or compute spend. Another team may launch usage pricing before it has reliable event data. Both choices create problems that surface after customers are live.

These four questions narrow the field:

1. Does your cost change with usage? Inference, compute, storage, and API calls create variable costs.
2. Does customer value rise with consumption? Usage pricing fits when heavier activity delivers more value.
3. How predictable is usage? Highly variable workloads may suit credits or prepaid balances.
4. Can your systems measure and enforce the model correctly? A pricing idea becomes an engineering requirement once production traffic arrives.

Here’s a quick way to map common situations to the billing type that tends to fit best:

The final question often decides what is practical. A billing model needs accurate metering, current customer state, and clear enforcement rules before it can work reliably at scale.

Where billing types stop and enforcement begins

Billing types set the commercial rules, and enforcement applies those rules before the product accepts more usage. Billing can calculate an invoice after the fact, while enforcement makes a live allow-or-block decision.

The two jobs can sit apart when overages are acceptable. A customer might exceed an API allowance by 10%, and the contract can bill the extra usage at the end of the month.

A hard credit balance changes the situation. Imagine a customer has five credits left when several agent runs begin at once. Here, the system can record every event accurately after completion and still leave the wallet below zero.

The costly work has already run.

This is where a billing decision becomes a request-path decision, because the product needs current balance data before it sends work to a model, tool, or compute service.

Three failure modes show up often:

• Retries consume twice when usage events or credit debits lack idempotency.
• Concurrent requests overspend one balance without atomic debits.
• Configured limits never reach the request path, which allows activity beyond the customer’s allowance.

These look like billing issues from the outside. Engineering teams see the root cause in the runtime path: stale state, separate sources of truth, or a missing decision before the request runs.

AI products make the cost visible fast. One unnecessary request may trigger a model call, retrieval work, tool use, and another chain of follow-up actions.

Building runtime controls for different types of billing

Building runtime controls for different types of billing starts when your product needs live decisions about credits, entitlements, usage limits, or AI spend. A standard recurring subscription can often stay with the billing provider that manages invoices, payments, and tax.

The requirement changes when a request has a cost or consumes a commercial allowance. Before an agent starts another run, the product may need to check the team’s active plan, remaining credits, and applicable limit.

Stigg acts as the usage runtime beside the billing stack. It enforces entitlements, credits, usage limits, and spend controls synchronously in the request path.

Here is what it adds:

• A ledger-backed credits engine for grants, debits, refunds, expiry, promotional balances, and burn order
• In-process checks for Node.js apps through the Node SDK, without a separate Sidecar deployment
• AI-native developer tooling through the MCP server, CLI, and agent skills for credits, entitlements, metering, and runtime configuration
• Entitlements that resolve current allowances from plans, add-ons, trials, and account-specific overrides
• Metering linked to customers, features, agents, products, and workloads
• Sidecar checks close to the application, with an in-memory cache for immediate reads and Edge API fallback at around 100ms on a miss (Redis is available for serverless or large container fleets)
• BYOC deployment for teams that need runtime infrastructure within their own VPC
• Sub-10ms p99 entitlement checks at 1M+ events/sec ingestion, with 99.99% uptime SLA and multi-region failover

Teams can adopt one capability at a time alongside their existing billing architecture. The Stigg docs show how these runtime controls fit into a production request path.

FAQs

1. What are the main types of billing?

The main types of billing include subscription, flat-rate, tiered, usage-based, credits or tokens, project-based, one-time or prepaid, and hybrid billing. The right model depends on how customer value, usage, and delivery cost behave.

2. What is the difference between billing models and billing systems?

The main difference between billing models and billing systems is what they define. A billing model determines how you charge, while a billing system runs the metering, rating, invoicing, collection, or other infrastructure needed to execute it.

3. Which billing type works well for AI products?

Usage-based, credit, token, and hybrid billing are common fits for AI products because cost often changes with inference or agent activity. The architecture also needs accurate metering and request-time controls when balances or limits affect whether more compute can run.

4. What is hybrid billing?

Hybrid billing combines two or more billing types, such as a recurring platform fee plus metered usage or prepaid credits. It gives the business a predictable base while still charging for variable consumption.

5. Why do usage and credit billing models fail in production?

Usage and credit billing models fail when metering and live state drift apart. Duplicate events, concurrent debits, stale limits, and unclear credit depletion rules can produce incorrect balances even when the final invoice logic looks reasonable.