How We Built Chargebee’s Usage-Based Billing to Enable Pricing Agility

Prefer listening? Here’s the full audio version of this post.

Pricing has evolved from a set-it-and-forget-it financial decision to a dynamic GTM lever that companies pull continuously. Pylon’s CEO recently shared that they’ve iterated on pricing 10 times already, and they’re still experimenting. Lovable actively polls users about credit limits, treating pricing like a product.

This isn’t companies being indecisive. It’s the reality of building in the AI era, where product capabilities evolve rapidly and customer value perception shifts constantly. Yet most companies hit the same wall: as products become more sophisticated and usage patterns more complex, their ability to iterate on pricing actually slows down.

After studying dozens of AI and SaaS companies struggling with usage-based billing, we discovered that the problem isn’t analysis paralysis—it’s architectural. The very systems designed to enable pricing flexibility were creating rigidity.

That’s why pricing agility is one of the core objectives for Chargebee’s Usage-Based Billing system. We knew that without it, companies would be trapped by the same architectural constraints we observed everywhere else.

But what do we actually mean by pricing agility? Here are the key questions that define it:

These capabilities became our design requirements. Every architectural decision we’ve made—from schema-flexible ingestion to modular billing layers—is driven by ensuring teams can answer “yes” to these questions without straining the engineering bandwidth already torn between the AI product roadmap and supporting internal teams.

The insights that shaped our approach reveal universal principles that any company can apply when building or evaluating usage-based billing systems.

Lesson 1: Rigid Schemas Force Premature Monetization Decisions

The Problem: Every company we studied faced the same trap: billing systems that force upfront decisions about data structure AND monetization logic before understanding how customers actually use their products.

AI companies spend weeks debating whether to track “interactions,” “tokens,” or “successful resolutions,” when the answer is “all of the above, plus attributes we haven’t thought of yet.”

Example: Consider Intercom’s Fin AI. They start tracking:

{
  "customer_id": "dhrj3y92", 
  "timestamp": "2025-08-22T10:15:30Z",
  "event_type": "ai_interaction",
  "ticket_id": 455789,
  "tokens_used": 230,
  "resolution_time_seconds": 45
}

But customer behavior quickly reveals new value dimensions worth tracking:

• Issue complexity (simple FAQ vs. technical problem)
• Resolution success without human handoff
• Customer satisfaction rating
• Issue category and language

Traditional billing system architecture creates two critical problems:

• Schema rejection: The system would reject the new attributes as they were not defined in the original schema configured, forcing engineering refactoring
• Monetization coupling: The systems assume all usage attributes directly tie to billing, which is not the case

This creates a vicious cycle: companies need to track new attributes to discover monetization opportunities, but can’t add attributes without expensive system changes in the billing system.

Chargebee’s Solution: Accept the full payload without enforcing rigid schemas. Any attribute can be added on-the-fly and stored at full fidelity:

{
  "customer_id": "dhrj3y92", 
  "timestamp": "2025-08-22T10:15:30Z",
  "event_type": "ai_interaction",
  "ticket_id": 455789,
  "tokens_used": 230,
  "resolution_time_seconds": 45,
  "issue_complexity": "medium",
  "resolution_successful": true,
  "customer_satisfaction": 4,
  "issue_category": "billing",
  "exchanges_count": 2,
  "language": "en-uk"
}

Now that these crucial attributes are in Chargebee, you can build meters on top of it (e.g., counting just the number of successful ticket resolutions) to track adoption across customer segments without necessarily putting a price tag on it.

Lesson 2: Tightly Coupled Systems Turn Pricing Changes Into Cross-Team Projects

The Problem: We witnessed the same cycle repeatedly: product identifies a new value metric, finance gets excited, but implementation requires coordination across engineering, finance, and operations—each with different priorities and sprint cycles.

The conversation typically goes like this:

This coordination overhead kills experimental momentum. The root cause isn’t just process friction—it’s architectural:

• Tight coupling within billing systems: Traditional architectures couple data collection with monetization, treating packaging changes as architectural changes rather than configuration changes.
• System fragmentation: Usage tracking happens in one system, feature entitlements are hard-coded in the application, usage metering logic live in another platform, and billing runs elsewhere. Each system boundary becomes a coordination point, and each integration becomes a potential failure mode for pricing changes.

Consider the above example: a company wants to add usage caps specifically for GPT-5 tokens while making GPT-4 unlimited. In tightly coupled systems, engineering must modify the event pipeline to separate GPT-4 vs. GPT-5 usage before sending it to billing. But what happens when you want to experiment with GPT-5 credits instead of hard caps, or test different pricing for a new model entirely?

This is the core problem: each pricing change cascades into engineering work across multiple systems. What should be a configuration change becomes a coordination project spanning data pipelines, billing logic, and application code—all owned by different teams with competing priorities.

Chargebee’s Solution:

Build billing as a modular system where each layer can evolve independently, eliminating unnecessary cross-functional dependencies:

• Modular architecture with clear data flow: Each layer (ingestion → metering → entitlements → rating → invoicing) handles a single responsibility and connects through well-defined interfaces. Usage data flows downstream while each component can evolve independently—pricing changes don’t touch ingestion, entitlement changes don’t require billing rewrites.
• Configurable over code: Business teams define meters, entitlements, and catalog mappings in Chargebee. Engineering emits events once and then steps out of the loop. 

Example:

An AI chat product wants to deploy GPT-5 for enterprise only, while opening GPT-4 for all plans:

• Engineering adds model_name to the existing data pipeline – single field addition, no schema changes required
• Product team sets up usage tracking – creates separate meters for GPT-5 vs GPT-4 usage directly in Chargebee’s UI, filtering by the new model_name attribute
• Configure plan entitlements (again, directly from the UI):
  • Enterprise customers: 1000 GPT-5 tokens included monthly, $0.02 per additional token
  • All plans get unlimited GPT-4 access
• Deploy gating logic – application checks entitlements (with Chargebee) before model selection, returns upgrade prompts for non-enterprise users requesting GPT-5
• Go live!

The key difference: The Product team configures the business rules while engineering focuses on the one-time technical change.

Lesson 3: Build Usage as an Action Engine, Not Just Billing Input

The Problem: Most billing systems treat usage data purely as a billing input, leaving tons of insights trapped within subscription and usage data. Sales can’t access usage patterns to identify upsell opportunities. Customer success can’t see usage decline that might signal churn risk. Product can’t analyze feature adoption to inform roadmap decisions. Finance can’t propose business strategies rooted in product reality.

Even when teams identify opportunities, execution becomes painfully slow because there’s no single system to run pricing experiments with the full context of the customers, subscriptions, and their usage data. We’ve seen teams spot perfect upsell moments only to watch months slip by before offers reach them. The front-end team builds popups, the back-end wires metadata, and QA runs sandbox tests, and by launch time, the moment has passed.

Given the speed at which companies are forced to adapt, this disconnect between data collection and business action is a huge blocker for businesses. 

Chargebee’s Solution: 

Build usage infrastructure as an action engine from the ground up. 

Usage data isn’t just an input for invoice generation in the Chargebee ecosystem; it’s a first-class object that powers business decisions across every function. The same usage events that calculate billing amounts also trigger lifecycle campaigns, identify expansion opportunities, and predict churn risk.

Example: A help desk company launching AI agents needs to decide: charge per conversation or per successful resolution? Here’s how they can navigate it with Chargebee:

• Instrument once, capture broadly: Instead of deciding upfront what’s billable, send full usage events (conversation IDs, resolution status, agent type, costs). No schema lock-in means nothing has to be rebuilt later if they want to test a new angle.
  
• Define meters flexibly: Configure “AI agent conversations” and “successful resolutions” as two meters. Each has its own aggregation logic and filters, but both pull from the same raw events.
  
• Run pricing experiments: A/B test cohorts: half on conversation (usage)- based pricing and half on resolution (outcome)- based pricing. This can be deployed with a user-friendly interface without separate tooling or maintenance overhead.
  
• Measure revenue impact directly: Instead of proxy metrics (click-through, conversion intent), they see each cohort’s actual revenue performance because the experiment runs at the billing layer.
  
• Act quickly: Roll out a winning model across your new and/or existing base without engineering sprints.

The Real Cost of Pricing Infrastructure Decisions

The SaaS and AI companies that win today aren’t necessarily those with the best initial pricing model—they’re the ones that can evolve their pricing models fastest. In our research, 83% of companies tested pricing before making changes, but those that rolled out updates within a month were much more likely to see success.

So, the architectural decisions of your billing system strongly influence your team’s ability to move faster on pricing and packaging. 

Here’s what we learned from the trenches, building Chargebee’s modern UBB system:

• Design for schema evolution, not schema perfection. JSON schemas that enforce strict validation upfront become technical debt when business requirements change. We learned to accept looser typing at ingestion and apply validation at the business logic layer, where it can evolve with product needs.
• Separate your data layer from your business logic. The biggest architectural mistake we wanted to avoid: forcing billing rules into the usage collection layer. When companies wanted to test new meters or change aggregation windows, they ended up rewriting entire ingestion pipelines. Our clean separation and composable architecture mean your pricing experiments don’t require deployments.
• Build usage data as a shared business intelligence layer, not a billing silo. The more systems you deploy to meter, bill, and analyze usage data, the more context gets lost and the longer it takes to test offers. We use the same event stream to generate usage charges, track feature adoption, predict churn, and run lifecycle offers without duplicate instrumentation.

Your pricing will change more in the next two years than in the previous five. Build your usage infrastructure like you’d build any other high-change system—with clear interfaces, loose coupling, and the assumption that every “final” requirement will evolve.

At Chargebee, we didn’t just theorize about these pitfalls—we built the next-generation usage-based billing infrastructure to overcome them. Today, we support 500+ companies across AI and SaaS as they experiment with usage and hybrid models. Our mission is simple: help businesses adapt pricing as fast as they adapt their products.

Want to see these principles in action?

• Interactive tour of Chargebee UBB (no signup required)
• 2-minute product demo (no signup required)