SaaS Pricing Models

Pricing in SaaS systems is often treated as a marketing decision. In reality, pricing is a system architecture problem.

A pricing model defines how entitlements propagate through the platform. It determines how features are enforced, how resource consumption is limited, and how revenue aligns with infrastructure cost. When pricing architecture is poorly designed, enforcement becomes inconsistent. Teams add ad hoc checks across the codebase. Feature flags become fragmented. Billing logic leaks into business logic.

A robust SaaS platform treats pricing as a formal system layer. Pricing determines feature availability, resource quotas, and operational limits. These rules must be represented in a model that can be evaluated reliably across API boundaries, background workers, and administrative systems.

This article examines the architectural design of pricing systems in SaaS platforms. The focus is not marketing strategy. The focus is how pricing rules become enforceable software constraints.

Pricing enforcement intersects directly with SaaS Security Architecture: A Practical Engineering Guide and Designing Tenant-Aware Background Jobs in SaaS Platforms.

Problem Definition and System Boundary

A SaaS pricing system must repeatedly answer a single question:

Is this tenant allowed to perform this operation?

The answer depends on multiple layers of constraints.

A tenant may be limited by:

• subscription tier
• enabled features
• resource quotas
• usage-based billing thresholds
• organizational limits

Pricing rules operate at the boundary between product logic and business policy.

Typical evaluation pipeline:

Customer account
→ Subscription plan
→ Entitlements
→ Feature access
→ Usage tracking
→ Billing events

Example operations requiring pricing evaluation:

• creating additional users
• generating reports
• uploading files
• running background jobs
• accessing premium analytics features

If enforcement is inconsistent, the system experiences revenue leakage or accidental service denial.

Pricing architecture therefore becomes a formal enforcement layer.

Core Components of a Pricing System

A structured pricing architecture typically contains four internal models.

Plan Model

A plan defines a commercial offering.

Examples:

• Starter
• Growth
• Enterprise

Plans contain metadata such as:

• monthly price
• billing interval
• feature groups
• base quotas

Example schema:

CREATE TABLE Plans (
    Id UUID PRIMARY KEY,
    Name TEXT NOT NULL,
    MonthlyPrice NUMERIC NOT NULL,
    BillingInterval TEXT NOT NULL,
    CreatedAt TIMESTAMP NOT NULL
);

Plans represent a stable contract between the platform and the customer.

Entitlement Model

Plans should not directly control application behavior.

Instead they grant entitlements.

An entitlement represents a capability granted to the tenant.

Examples:

• can_export_data
• api_access
• priority_support
• advanced_analytics

Example schema:

CREATE TABLE PlanEntitlements (
    PlanId UUID REFERENCES Plans(Id),
    EntitlementKey TEXT NOT NULL
);

Using entitlements decouples application logic from marketing tiers.

Quota Model

Many SaaS limits are quantitative rather than binary.

Examples:

• number of users
• storage capacity
• API calls per month
• report generation limits

Example schema:

CREATE TABLE PlanQuotas (
    PlanId UUID REFERENCES Plans(Id),
    ResourceKey TEXT NOT NULL,
    LimitValue INTEGER NOT NULL
);

Example resource keys:

• users
• projects
• api_requests
• reports_generated

Usage Tracking Model

Quota enforcement requires accurate measurement.

Usage counters typically track consumption per billing period.

Example schema:

CREATE TABLE UsageCounters (
    TenantId UUID NOT NULL,
    ResourceKey TEXT NOT NULL,
    PeriodStart TIMESTAMP NOT NULL,
    UsageValue INTEGER NOT NULL,
    PRIMARY KEY (TenantId, ResourceKey, PeriodStart)
);

Without reliable usage tracking, quota enforcement fails.

Pricing Enforcement Architecture

Pricing rules must be enforced consistently across the platform.

Two architectural approaches exist.

Embedded Enforcement

Small SaaS systems embed pricing checks directly inside services.

Example:

public async Task CreateUser(CreateUserRequest request)
{
    var usage = await usageService.GetUsage("users");
    var quota = await pricingService.GetQuota("users");

    if (usage >= quota)
        throw new QuotaExceededException();

    await userRepository.Create(request);
}

This approach works initially but becomes difficult to maintain as the system grows.

Centralized Entitlement Service

Larger platforms introduce a dedicated entitlement evaluation layer.

Example interface:

public interface IEntitlementService
{
    Task<bool> HasFeature(string tenantId, string featureKey);
    Task<bool> WithinQuota(string tenantId, string resourceKey, int requestedAmount);
}

Evaluation pipeline:

API Request
→ Authentication
→ Tenant Resolution
→ Entitlement Service
→ Business Logic

This centralizes pricing enforcement and reduces duplication.

Request Lifecycle Enforcement

Pricing checks should occur early in the request pipeline.

Example lifecycle:

Incoming Request
→ Authentication
→ Tenant Context Resolution
→ Entitlement Evaluation
→ Application Service Execution

This prevents expensive operations from executing when entitlements are missing.

ASP.NET Core Implementation Example

Pricing enforcement can integrate with ASP.NET Core authorization.

Example requirement:

public class FeatureRequirement : IAuthorizationRequirement
{
    public string FeatureKey { get; }

    public FeatureRequirement(string featureKey)
    {
        FeatureKey = featureKey;
    }
}

Authorization handler:

public class FeatureAuthorizationHandler
    : AuthorizationHandler<FeatureRequirement>
{
    private readonly IEntitlementService _entitlements;

    public FeatureAuthorizationHandler(IEntitlementService entitlements)
    {
        _entitlements = entitlements;
    }

    protected override async Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        FeatureRequirement requirement)
    {
        var tenantId = context.User.FindFirst("tenant_id")?.Value;

        if (await _entitlements.HasFeature(tenantId, requirement.FeatureKey))
        {
            context.Succeed(requirement);
        }
    }
}

Controller usage:

[Authorize(Policy = "advanced_analytics")]
public async Task<IActionResult> GenerateReport()
{
    return await reportService.Generate();
}

Real Failure Scenario

A SaaS analytics platform enforced pricing only in the frontend interface.

Feature buttons were hidden depending on subscription tier.

However the backend API did not enforce entitlements.

Users discovered that sending API requests directly allowed unlimited report exports.

Consequences:

• revenue leakage increased
• infrastructure load increased
• enterprise customers experienced degraded performance

Root cause:

Pricing enforcement existed only in the UI layer.

The fix required introducing centralized entitlement validation inside the backend.

Operational Considerations

Plan Evolution

Pricing plans change over time.

Existing customers may remain on legacy plans while new customers adopt updated pricing.

Plan versioning must be supported.

Usage Aggregation

Usage events may originate from multiple services:

• API gateways
• background workers
• scheduled jobs
• analytics pipelines

Centralized aggregation ensures accurate quota enforcement.

Billing Provider Synchronization

External billing systems manage subscription payments.

Typical flow:

Billing Provider Webhook
→ Subscription Update
→ Internal Plan Assignment
→ Entitlement Recalculation

Internal systems must remain the source of truth for enforcement.

Abuse Prevention

Quota systems must assume adversarial behavior.

Example race condition:

Multiple requests create users simultaneously before counters update.

Mitigation strategies:

• transactional quota checks
• row locking
• atomic counter updates

Pricing Architecture Tradeoffs

Feature-Based Pricing

Advantages:

• simple enforcement
• easy to communicate

Disadvantages:

• rigid product evolution
• encourages artificial feature segmentation

Usage-Based Pricing

Advantages:

• aligns revenue with infrastructure cost

Disadvantages:

• requires reliable metering
• billing disputes may occur

Hybrid Pricing

Most mature SaaS systems combine:

Plan\

• Feature Entitlements\
• Quotas\
• Usage-Based Overage

Hybrid models increase flexibility but add system complexity.

Connecting Pricing to SaaS Architecture

Pricing architecture intersects with multiple platform layers:

• tenant resolution
• authorization policies
• usage analytics
• billing infrastructure
• background job processing

Treating pricing as a first-class architecture component prevents inconsistent enforcement and allows pricing models to evolve without rewriting application logic.

For a broader architectural overview of SaaS system design and tenant-aware infrastructure, see:

Complete Guide to Multi-Tenant SaaS in ASP.NET Core

Need implementation support? Explore our services.

Related Articles

• Complete Guide to Multi-Tenant SaaS in ASP.NET Core
• Handling Tenant-Aware Caching in SaaS Platforms
• Designing Tenant-Aware Background Jobs in SaaS Platforms
• SaaS Security Architecture: A Practical Engineering Guide