Stripe Usage-Based Billing: What Stripe Handles (and Doesn’t)

A pricing change gets approved. The product team updates the plan limits. Three engineers are now blocked because usage limits are hardcoded across four services, all tied to Stripe subscription objects.

What should have been a catalog update is a coordinated deployment with three failure points. That's the Stripe entitlements problem, and it shows up faster than most teams expect.

What Stripe’s usage-based billing actually does

Stripe’s usage-based billing sits at the billing layer of a pricing architecture. Usage events are sent to the Meters API as JSON payloads tied to a customer and meter. 

Stripe aggregates those events using one of three configurable methods: sum, count, or last value. The choice affects how the billing layer interprets the event stream, so it needs to align with how the metering pipeline reports usage upstream.

Stripe supports pay-as-you-go, tiered, per-package, and hybrid pricing structures. The hard part is that none of these structures give the application any information about feature access, usage limits, or what happens when a customer hits a threshold mid-session.

At the end of the billing cycle, Stripe applies the pricing model to the aggregated usage and generates the invoice.

Stripe supports several common usage-based pricing structures:

• Pay-as-you-go: Customers pay exactly for what they consume. The system calculates charges per unit when it generates the invoice.
• Tiered pricing: Different usage thresholds apply different per-unit rates. Pricing adjusts automatically as usage grows.
• Per-package pricing: The system bills usage in bundles. For example, it may bill 3,000 tokens as 30 packages of 100 tokens.
• Hybrid pricing: A base subscription combined with usage-based overage charges above a defined threshold.

Stripe also provides surrounding billing infrastructure such as hosted checkout, a billing portal, payment method management, and tax automation. Metronome, now part of Stripe, extends this further with support for enterprise contracts, prepaid commitments, and high-cardinality usage scenarios.

In practice, Stripe acts as the billing layer of a usage-based pricing architecture. It handles usage aggregation, charge calculation, invoice generation, and payment collection once the system records the usage data.

Limits of Stripe’s usage-based billing architecture

Stripe handles usage aggregation and billing, but it does not manage feature access, entitlement enforcement, or product configuration inside the application.

Stripe’s Meters API can track usage and generate invoices. It does not:

• Control which features a customer can access based on their plan
• Enforce usage limits in real time inside the product
• Manage a product catalog that defines plans, features, and limits

This reflects the architectural boundary between billing and entitlements.

Stripe owns the billing layer. Your application still needs an entitlements layer that decides what a customer can actually do in the product.

Example: Feature access in a SaaS pricing model

Consider a SaaS product with three pricing tiers:

Stripe knows which subscription a customer purchased. Stripe does not enforce that:

• A Free user cannot access a Pro-only API endpoint
• A Pro user cannot exceed 1,000 calls/day
• An Enterprise customer has a custom limit

That enforcement must happen inside the application layer.

The common engineering pattern (and its limits)

The default pattern is straightforward, and it made sense when it was built. Resolve a customer's plan from Stripe, map it to a set of feature flags and usage limits in application code, and gate access accordingly.

At early stage, with a small catalog and a stable pricing model, that is the right call. There is no point building dedicated infrastructure for a problem that does not exist yet.

The coupling problem shows up fast:

• Custom enterprise plans stop fitting neatly into the plan structure
• New tiers introduce conditionals that spread across services
• Usage limits end up hardcoded in API handlers
• A single pricing change touches billing config, application logic, and access control simultaneously
• Each touch point requires a deployment

That coupling is the architectural signal that entitlements need their own layer. Take a concrete example of a team that wants to add a usage limit to an existing Pro plan. 

With entitlements coupled to Stripe, that one change requires:

• Updating the Stripe product configuration
• Modifying application code that reads plan limits
• Deploying across every service that checks that limit
• Updating the UI if the limit affects what users see

What should be a catalog change becomes a coordinated multi-service deployment with multiple failure points.

The missing layer: Entitlements

The entitlements layer sits between the application and the billing system, resolving one runtime question on every request: Does this customer have access to this feature, and how much have they used?

At runtime, effective entitlements are resolved from multiple sources:

• Active plan and any parent plan inherited
• Active add-ons, which can increment or override plan limits
• Trials and promotional overrides granted directly to the customer
• When sources conflict, the most generous value wins

That resolution logic has to be consistent across every service that checks entitlements. Without a dedicated layer, it ends up coupled to Stripe subscription objects in application code, plan IDs get hardcoded, usage limits scatter across services, and every pricing change requires a coordinated deployment to stay consistent.

How Stigg and Stripe work together architecturally

Stigg and Stripe solve different parts of the pricing stack. Stigg manages product configuration and entitlements inside the application. Stripe manages billing and payments.

Think of the architecture like this:

The application never needs to ask Stripe whether a user can access a feature. It asks Stigg, which evaluates the customer's plan, limits, and current usage.

Stigg's Sidecar runs as a Docker container alongside your application, caching entitlement data in Redis so access decisions resolve locally even if the Stigg API is unreachable.

Cache hits are immediate, and cache misses fall back to Stigg's Edge API at around 100ms, with a configurable timeout to prevent upstream latency from cascading into your application.

Data residency requirements don't force a tradeoff between compliance and enforcement speed. The Sidecar runs inside your own infrastructure, keeping entitlement state within the VPC and resolving cached access decisions locally, without a round trip to any external service.

If the Stigg API loses availability, the local cache keeps enforcement running without falling back to open access or blocking all requests.

How data flows between Stigg and Stripe

Stigg acts as the source of truth for pricing configuration.

When teams add a new plan or update pricing in Stigg, the change automatically syncs to Stripe.

Typical flow:

1. Define plans, features, and usage limits in Stigg
2. Stigg syncs pricing objects to Stripe
3. Stripe handles checkout, invoices, and payments
4. The application checks feature access through Stigg

For pay-as-you-go subscriptions, Stigg can also send usage data to Stripe when Stripe generates invoices.

How entities map between Stigg and Stripe

The feature row is the key architectural difference. Stripe models billing objects like products, prices, and subscriptions. It has no concept of a product feature, what it does, or how much of it a customer can use. 

Without a dedicated layer to model that, the logic ends up in application code coupled with Stripe plan IDs, and every change to feature limits becomes a deployment.

See the documentation for the complete mapping between Stigg and Stripe entities.

Integration and environment setup

Stigg connects to Stripe through OAuth and handles bidirectional synchronization automatically. Plans, add-ons, coupons, and subscriptions defined in Stigg propagate to Stripe without manual mapping. For usage-based subscriptions, Stigg sends usage and total amount to Stripe at invoice generation time.

Stigg environments map directly to Stripe test and live accounts, so pricing changes can be validated in staging against real Stripe objects before they reach production. That isolation matters when pricing changes affect checkout flows, entitlement enforcement, and billing configuration simultaneously.

Flexibility for billing provider changes

Stigg supports multiple billing providers. Teams migrating from Zuora to Stripe can run both in parallel during the transition.

Because entitlements live in Stigg, application code does not need to change when the billing provider changes.

Checkout and in-app billing experience

Stripe provides a hosted checkout page and billing portal that work out of the box. They require little engineering work but redirect the customer outside the application, which interrupts the in-app experience.

Stigg keeps checkout and billing inside the product.

Stigg provides an embeddable checkout widget that runs directly in the application. The widget automatically reflects the product catalog defined in Stigg. When pricing changes in Stigg, the checkout updates automatically without a code deployment.

The widget handles:

• Plan selection
• Add-ons and upgrades
• Payment collection through Stripe
• Real-time provisioning once payment succeeds

Stigg also provides an embeddable customer portal where users can:

• View current usage
• Manage their plan
• Access billing details

When integrated with Stripe, the portal surfaces Stripe’s billing interface for payment methods and invoice history.

Because the product catalog lives in Stigg, pricing updates propagate automatically to:

• Checkout
• The in-app customer portal
• The entitlements enforcement layer

The application does not need a redeploy for pricing changes.

For example, Webflow has run Stigg alongside Stripe for more than three years. Before that, their VP of Engineering described every deep entitlement change as painful, with multiple rounds of testing, PR reviews across teams, and manual customer migrations in Stripe on launch day.

When they scoped building an equivalent system in-house, the estimate came out at five engineers for six months, and he later admitted that was probably an underestimate. After moving to Stigg, the team went from turning down 80% of pricing requests to supporting all of them.

When to use Stripe alone vs. Stripe with an entitlements layer

The architectural decision comes down to where entitlements logic lives and how often it needs to change.

Coupling entitlements to Stripe subscription objects works when the pricing model is stable and the catalog is small. The cost compounds as complexity grows: new tiers add conditionals, enterprise plans create exceptions, and usage limits end up hardcoded across services. The first major pricing change usually forces a rebuild.

A dedicated entitlements layer makes sense when:

• Plans have different feature limits that change independently of billing
• Usage-based pricing requires real-time enforcement inside the product
• Credit models or token balances need to be tracked at request time
• Billing providers may change and entitlements should not need to follow

The table below maps common scenarios to the right architecture:

Stripe alone works well when:

• The pricing model is simple
• Entitlements logic can remain in the application code
• The team can maintain custom metering and access control

Stripe with an entitlements layer works better when:

• Pricing changes frequently
• Multiple plans have different feature limits
• Usage-based pricing requires real-time enforcement
• The system must track credit models or token balances
• Billing providers may change in the future

Coupling entitlements directly to Stripe works early on, but the cost compounds as the pricing model evolves. Teams that build this coupling in-house often rebuild the system once the first major pricing change arrives.

Extending Stripe usage-based billing with an entitlements layer

Stripe handles usage, invoicing, and payments. But plans, feature access, and usage limits still live in your application, where they get hardcoded and tied to Stripe.

Stigg is the layer that sits above Stripe and removes that coupling. Entitlement checks, credit balances, usage limits, and spend governance resolve in the request path before compute runs, so pricing changes go through configuration instead of code.

For engineering teams who have hit that wall:

• On a cache hit, access decisions resolve locally. On a cache miss, the Sidecar fetches from Stigg's Edge API at around 100ms, before the request reaches any downstream system, including Stripe
• Each credit draw references the correct balance pool, applies precedence rules across paid and promotional credits, and writes an immutable event so the ledger stays accurate under concurrent load
• Per-user, per-agent, per-team, and per-department budget controls are first-class data model primitives, not conditional logic bolted on when an enterprise prospect first asks for them
• Running the Sidecar inside your own VPC means enforcement decisions never depend on external availability, and entitlement state never leaves your infrastructure boundary
• Updating a plan tier, adjusting a feature limit, or launching a new pricing experiment touches the product catalog once and propagates automatically to checkout, the customer portal, and access enforcement

See how Stigg’s entitlements layer fits into a Stripe usage-based billing stack.

FAQs

1. Should you use Stripe for usage-based billing?

Yes, Stripe is a strong choice for usage-based billing. Stripe’s Meters API tracks usage events, aggregates consumption, and generates invoices accurately at scale. However, Stripe focuses on billing, while feature access control and entitlements enforcement typically require a separate infrastructure layer.

2. What is the difference between Stripe billing and entitlements management?

The main difference between Stripe billing and entitlements management is what each layer controls. Stripe billing handles invoices, payments, and tax compliance after a purchase. Entitlements management controls which features a customer can access and what their usage limits are within the product.

3. Does Stigg replace Stripe?

No, Stigg does not replace Stripe. Stigg integrates with Stripe through OAuth and acts as the product catalog and entitlements layer between the application and Stripe. Stripe continues to handle invoicing, payments, and tax, while Stigg manages feature access, usage limits, and pricing configuration.

4. How does Stigg sync with Stripe?

Stigg syncs with Stripe bidirectionally. Changes to plans, add-ons, coupons, and subscriptions in Stigg automatically propagate to Stripe. For usage-based subscriptions, Stigg also sends usage data to Stripe for invoice generation.

5. What does Stripe not handle in a usage-based billing architecture?

Stripe does not enforce feature access, usage limits, or product catalog logic inside the application. Stripe’s Meters API tracks usage for billing purposes, but enforcing plan limits and feature access requires a separate entitlements layer.