Billing is one of the few systems in a B2B product where the vendor gets to dictate your architecture. The platform decides how you integrate, how pricing is structured, and in some cases which processor you settle through. Every other critical dependency in a modern stack has a developer-friendly, inspectable option. Authentication does. Analytics does. Payments does. Billing mostly does not.
That gap is what open source billing infrastructure closes, and the difference shows up in specific places rather than as a general philosophy.
What does open source actually change for a billing system?
It changes where the code runs and who can read it. With an open source billing engine you can inspect the rating logic, run the whole system inside your own infrastructure, and extend it when your pricing outgrows what the vendor modelled. With a closed platform, none of those are options, and the workaround is usually a layer of custom code that reimplements part of the billing system anyway.
Integration on your terms
Billing sits in the middle of every B2B stack, and no two stacks are the same. Some teams settle through Stripe, some through Razorpay, some through Paddle, and some keep an internal ledger as the system of record. A billing layer that assumes one of those is the answer will fight the other three.
Flexprice is metering-first infrastructure built for usage-based and hybrid pricing, and it's not tied to any payment gateway. The metering and rating layer produces the amount owed. What collects that amount is a separate decision you keep.
That separation matters most when it changes. Adding a second processor for a new region should be an integration, not a billing migration.
Running it where your data already lives
The strongest argument for self-hosting a billing system is not cost. It's that usage and revenue data is some of the most sensitive data a company holds, and shipping all of it to a vendor's cloud is a decision that's hard to reverse once auditors and customers are involved.
Flexprice offers three deployment options, and all three run the same engine.
- Your VPC. Deployed inside your own virtual private cloud on AWS, Azure, or GCP.
- On-prem. Deployed inside your own data centre, in any geography.
- Flexprice cloud. Fully managed by Flexprice, for teams that do not want to operate it themselves.
Because Flexprice is open source and self-hostable, usage and revenue data can stay entirely inside your own infrastructure and never reach a vendor's cloud. This is what makes Flexprice usable by companies with data residency, sovereignty, and audit requirements that hosted-only billing vendors cannot meet.
The self-hosting guide covers the deployment path, and the architecture page shows what the components are before you commit to running them.
Pricing that does not scale with your revenue
A large share of billing platforms take a percentage of the revenue they process. The logic behind that model is that billing volume tracks value delivered. In practice it means your billing bill grows every time you have a good quarter, for work that does not get harder as the numbers get larger.
Teams that hit this often respond by building billing in-house, which trades a recurring fee for a permanent maintenance cost and an on-call rotation nobody wanted.
Flexprice is open source and free to self-host. The managed cloud is priced per plan rather than as a share of revenue.
Composability, because pricing keeps moving
Flat subscriptions are no longer the default. Most products now run some combination of a base plan, metered usage, prepaid credits, feature gating, and add-ons, often on the same invoice. Closed platforms tend to model one of those well and treat the rest as an extension point.
Flexprice models them as primitives you compose. A metered feature is defined by an event name and an aggregation. A plan attaches prices to features. A wallet holds prepaid or promotional balance and draws down against usage. Whether you are metering GPU seconds, API calls, seats, or a business metric that only exists in your product, the modelling step is the same.
{
"event_name": "gpu.seconds",
"external_customer_id": "cust_123",
"properties": {
"seconds": 420,
"instance_type": "a100"
},
"source": "worker"
}
That event is the unit of billing. Everything downstream, including aggregation, rating, credit drawdown, and invoicing, is configuration applied to the stream rather than code in your services.
The edge cases are the product
Proration on a mid-cycle upgrade. A downgrade that leaves unused prepaid credit. A refund that has to reverse a partially consumed entitlement. Multi-region tax handling. Retries that must not double bill.
These are the cases that consume the time of every team that builds billing themselves, and they are exactly the cases a closed vendor is least likely to prioritize, because each one affects a minority of customers. Open source changes the economics of that. A fix that matters to you can be read, patched, and contributed rather than filed and waited on. The contributing guide is the entry point if you want to work on the engine itself.
Pricing changes without engineering sprints
Treating billing as a finance system makes pricing static by default, because every change becomes a ticket. Teams that run pricing as an ongoing experiment need the opposite: new plans, packaging changes, and usage-based trials that go out without a deploy.
When plans, prices, and entitlements are data rather than code, changing them is a configuration change. That's the difference between testing a price point this week and scheduling it for next quarter.
Where to start
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.
Clone it, run it locally, and send an event through it before deciding anything else: github.com/flexprice/flexprice.
Top comments (0)