SaaS Billing Models: Subscriptions, Seats, Credits, and Add-ons

Billing is product strategy expressed in code. If your starter only handles a single checkout link, you will rebuild it as soon as pricing changes.

This article breaks down the billing models a SaaS foundation should support.

Flat Subscription

The simplest model is one plan, one recurring price.

Use it when:

• The product has a clear single package.
• Usage does not vary much across customers.
• Support and infrastructure costs are predictable.

Implementation needs:

• Checkout session.
• Subscription created webhook.
• Subscription updated webhook.
• Subscription canceled webhook.
• Customer portal.
• Plan state in the database.

Tiered Plans

Most SaaS products need at least two paid tiers.

Typical differences:

• Feature access.
• Usage limits.
• Support level.
• Number of seats.
• Data retention.
• Integrations.

Store planId in your subscription table and map it to a local plan catalog. Do not rely on provider price IDs as your product logic.

Seat-Based Billing

Seat billing is common for B2B SaaS. It aligns price with customer team size.

You need:

• Current seat count.
• Optional max seat cap.
• Member invite logic.
• Checkout or subscription update flow.
• Billing UI that explains renewal impact.

Screenshot placeholder: billing screen with current plan, active seats, and max seat cap.

Usage Credits

Usage credits work well for AI, API calls, file processing, or metered workflows.

Track:

• Total credits.
• Used credits.
• Reset date.
• Usage events.
• Budget alerts.
• Overage policy.

Credits should be visible to the customer before they become a billing surprise.

Add-ons

Add-ons let you expand revenue without forcing every customer into a higher tier.

Examples:

• Extra storage.
• White-labeling.
• Priority support.
• Advanced analytics.
• Additional AI credits.
• Premium integrations.

Your checkout and subscription state need to support multiple line items, not just one plan.

Trials

Trials are useful when activation requires product usage. They are less useful when setup is complex and a sales conversation is needed.

If you support trials, store:

• Trial end date.
• Trial status.
• Conversion events.
• Reminder schedule.
• Cancellation behavior.

One-Time Purchases

Some developer products sell lifetime access or source code licenses. That model needs different state than recurring SaaS:

• License tier.
• Project count.
• Update period.
• Support period.
• Delivery workflow.
• Receipt and access email.

Do not mix one-time license logic into recurring subscription code without clear types.

Webhooks Are the Source of Truth

Checkout success pages are not enough. Provider webhooks should update your database.

At minimum, handle:

• Checkout completed.
• Subscription created.
• Subscription updated.
• Subscription deleted.
• Payment failed.
• Refund.

Log webhook delivery and errors. Silent billing failures are expensive.

Admin Billing Support

Your admin panel should show:

• User name and email.
• Provider.
• Plan ID.
• Status.
• Seat count.
• Renewal date.
• Cancellation state.

Support should not need direct database access to answer a billing question.

Pick the Model You Can Explain

The best billing model is not the most sophisticated one. It is the one customers understand and your system can enforce.

Start with the simplest model that matches value, but choose a codebase that can add seats, credits, add-ons, and trials when your pricing evolves.