Why Stripe Fails at Complex Usage-Based Billing

Billing doesn’t start as a problem. A few plans, a pricing page, some logic to generate invoices, it’s all manageable in the early days.

But as pricing evolves, it becomes a bottleneck. Suddenly, you’re dealing with usage-based metering, one-off customer deals, credit-backed models, and discounts that behave differently across time zones or contract terms.

The billing codebase stops being something you maintain. It becomes something you fear touching.

And that fear comes from experience, because every engineer who’s worked on billing has hit the same wall:

• You're not fixing bugs

• You're rewriting logic that already worked.

Just slightly differently, for one more customer.

Why Billing Infrastructure Keeps Breaking

The problem with billing isn’t the logic. It’s the accumulation of exceptions.

Your system starts with a basic model, plans, usage, and maybe some discounts. But pricing evolves. Finance introduces a new deal structure. Sales negotiates a custom clause. 

Product experiments with a hybrid model. None of these changes are wrong in isolation, but every one of them requires a code-level intervention.

Billing logic becomes an append-only log of one-off requirements.
And no one’s cleaning it up.

Complexity compounds silently.

You’re not just tracking usage anymore, you’re reconciling it against multiple parameters. Such as contract terms, time zones, trial windows, revenue recognition rules, grace periods, renewals, discounts, and billing cycles that don’t align.

Each component is manageable alone. Together, they multiply the state your system has to manage. Even if the core logic is correct, edge cases will emerge in how systems interact. You’ll debug discrepancies that originate in a missing webhook retry or a race condition between usage ingestion and invoice finalization.

Eventually, it's not the logic that fails, it's trust in the system. And once you lose that trust, you start to fear touching the system at all.

The spaghetti isn’t accidental

You build around what’s already there, patches, flags, duplicated logic. Eventually, the same input stops producing the same output.

Look at Cursor. They moved from 500 to unlimited requests. Even with experienced devs, it took days to fix. They had to hide usage (showing “0” requests) just to calm things down. Many users got hit with unexpectedly high bills.

Check out this Reddit thread by Cursor

If a company like Cursor can run into this, so can you. That’s why billing needs to be built like infra, not duct-taped on top.

Why not just use Stripe?

Stripe works well for standard use cases.
But Stripe is closed-source, opinionated, and deeply coupled to its payments ecosystem. That’s fine until you want to use your own metering system. Or bill through credits. Or plug invoices into your internal finance tooling.

Stripe works, until it doesn’t. It handles standard cases well. But the moment you need custom metering, multi-step billing flows, or postpaid usage with credit-backed models, you’re writing glue code around a black box.

One of our early users put it best:

Earlier we used to do subscription billing on Stripe, and as soon as we started to move towards usage-based pricing, our systems started breaking. From credits and rollover to just basic upgrade/downgrade logic, everything became a pain. We tried other open-source billing tools, but Flexprice came as a blessing. Now we don't need to touch billing with every single pricing change or migration. Flexprice handles it all.

—Muhindi (Samson) Asena, Software Engineer, Savannah Informatics

Then you start writing glue code. You wrap Stripe in background jobs. You maintain logic outside the system, because the system can’t be changed.

Flexprice flips that model:

• Metering, invoicing, credits, grants, and charges are first-class objects.

• The system is event-driven, stateless where possible, and composable.

• You can self-host or use our cloud. No vendor lock-in.

We don’t take a cut of your revenue.
We don’t control your payment stack.
And we’ll never prevent you from debugging your own billing.

Why We’re Building an Open Source Billing Engine

Billing is hard, not because it’s unsolved, but because it keeps getting solved in isolation. Every engineering team builds partial solutions: patches, workarounds, custom logic. And every time pricing changes, the billing system becomes harder to maintain.

We believe billing deserves a shared foundation.

That’s why Flexprice is open source, not as a branding choice, but as a structural one

Most billing platforms are closed boxes.

• You can’t see how calculations happen.

• You can’t contribute a fix when you hit an edge case.

• You can’t debug issues without waiting on support or building wrappers around undocumented behavior.

In billing, that opacity becomes a risk.
Because when you’re dealing with usage spikes, pro-rated upgrades, custom credits, or blended hybrid plans, you need to know exactly how your system behaves.

Flexprice gives you full access to the billing engine itself:

• Every grant, every charge, every invoice is traceable, inspectable, and reproducible.

• All logic is versioned, event-based, and testable like real infra.

• And if something breaks, you can read the code, fork it, fix it, or submit a PR.

That’s the difference between a service and infrastructure. And we’re building the latter.

Shubhendu from Simplismart summed it up well:

“We are an Infra company, and hence pricing changes a lot really quickly. While we were using one of the other billing tools, the initial setup was good, but as soon as we started to roll out changes, everything seemed to break, from regenerating invoices, credit adjustments, partner billing, and more…

We were left with close to no support, and now that we have moved to Flexprice, the comfort of close to real-time support is just such a breather. The team is really nimble with requests and understands the space and requirements really well, with an almost spotless execution.”

—Shubhendu Shishir, Head of Engineering, Simplismart

Why OSS works for billing (when closed platforms fall short)

Closed-source billing products optimize for the common 80%.
The rest, the long tail of real-world edge cases, is left for you to handle manually.

But billing complexity lives in that last 20%:

• A customer needs usage charged monthly but invoiced quarterly.

• Credits expire, unless they’re promo-based.

• One customer has a grace period that’s been grandfathered for years.

No platform can predict all of this. But a good one can give you the primitives to build it, without rewriting the entire system.

Open source billing is the only model that enables shared progress across teams solving these problems in parallel. What you build for your edge case might help another team next month. And vice versa.

Flexprice is where that knowledge compounds.

Where we are, and what’s next

We recently launched five foundational features in five days as part of our Commit Launch. Check that out!

Each of these features reflects months of conversations with teams navigating real billing pain, engineers trying to bridge gaps with glue code and finance leaders fighting for visibility into revenue.

This momentum is just the start.

Our public roadmap is open for a reason. We want you to build with us. You can see what’s coming, suggest what should come next, and track how we prioritize across use cases.

We believe billing infra should evolve in the open, visible, extensible, and aligned with how real teams ship pricing.

If you're tired of solving billing from scratch, or maintaining a fragile Stripe wrapper that can't handle your edge cases, you don’t have to keep doing it alone.

• ⭐ Star us on GitHub to follow our progress

• 🤝 Join our community to share feedback and collaborate