killbill/killbill

What it does

You define plans, with trials and promotional discounts, and it works out what each customer owes and when. It keeps the subscription history, so a plan change halfway through a month produces the right amount rather than an argument. It handles the payment side as well, including retries. Analytics and financial reports come as part of it rather than as an add-on, which is the piece most projects leave to you. It is built to be taken apart: features can be switched off or replaced with systems that are already in place, and there is a published framework for extending it. It can run on your own machines or on rented ones, and the project offers a one-click deployment for one cloud provider. The quick start runs three containers: the billing engine on one port, an administrative interface on another, and a MariaDB database. The newest release is killbill-0.24.22, from 29 September 2026, and code landed on 12 October 2026, from 10,378 commits since 2010. What the project says it is not is an all-in-one solution. It is also spread over many repositories rather than one, so the code you will read is not all in this one place.

Why it matters

Who it suits. Anyone whose charging is complicated enough that the billing provider's own rules have become the problem: usage-based pricing, mid-cycle changes, several currencies, or an accountant who wants the numbers to reconcile. It also suits anyone who cannot accept a billing provider deciding their pricing model for them, which is the reason the project gives for existing. Skip it if a payment provider's own subscriptions page already covers your plans, because this is a large system to run for a problem you do not have.

Verdict. The most serious piece of software on this page, and sixteen years of maintenance is the reason to take it seriously rather than the star count. Billing is the area where a small mistake becomes a refund, an angry customer and a wrong number in the accounts, and a system that has been corrected for sixteen years has had those mistakes found. Against that, be honest about the cost: 4 GB of memory, a database, Java if you are not using containers, and a codebase spread across an organisation rather than one repository. Read the documentation before deciding, because the repository page itself carries no installation instructions at all. getlago/lago at 10,300 stars is the modern alternative aimed at usage-based pricing, under AGPL-3.0, and Edition 11 covered it; it is the one to prefer if metered usage is the main problem and a long history is not required. paymenter/paymenter at 2,700 stars is the much smaller MIT-licensed option built for hosting companies selling services, and Edition 47 covered it.