Kill Bill on AWS - Single AMI

What do you like best about the product?

I run Kill Bill in production as a real subscription engine, not a checkout wrapper. Catalog XML, plan phases, IN_ADVANCE / IN_ARREAR (postpaid), usage, add-ons, invoices, auto-renewal, and overdue / block-unblock are first-class — not a bolt-on. Multi-tenant works for a platform with many customers.

I also love the plugin system. Payment, invoice, and entitlement hooks let me extend Kill Bill without forking the core. The one I use most: an invoice plugin that changes line items at generation time, so we can apply discounts when the invoice is built — not in a messy after-the-fact patch.

On my team I was the person who actually learned how Kill Bill behaves (catalog versions, charged-through dates, requestedDate, blocking states) and then introduced most of those billing features — auto-renewal, add-ons, postpaid, block/unblock, runtime invoice discounts — because nobody else here knew the engine that well. I can read the source, prove a charge or a date, then post a full repro on killbilling-users. People there (and on GitHub) answer with code and issues, not marketing. I am still learning it. That is the point: it is deep enough that there is always more to understand. We are not paying Kill Bill a SaaS bill. The price is engineering time: I had to own catalog, requestedDate, overdue, and plugins before the invoices were trustworthy. Stripe Billing would have been more features on day one and a real invoice to Stripe every month. I would rather pay that time and keep the BSS than rent a prettier stack and lose the source. For what we actually pay (hosting + my hours, not a license), the value is there — if someone on the team will sit with the dates. If you only count the sticker price and ignore that learning, it looks “free” and then it is not.

What do you dislike about the product?

The hard parts are not “create a subscription.” They are dates, catalog pinning, and overdue edges. You have to understand the system first or it will not do what you expect.

Block / unblock and auto-renewal dates will not do the job if you treat requestedDate as optional decoration. Auto-renew end is an exact invoice-generation day, not a random calendar pick. If that date is wrong, the block lands on the next day: you get proration you did not want, or the next invoice still charges, or entitlement stops a day late. The docs are correct that a block with no requestedDate is immediate. You can pass the date you want — but it has to be the real generation / period-end date, not “today” and not “whatever.” I use a few different API call shapes (endpoint + params) so the effective day matches that invoice date. I learned that from clock tests and invoices, not from the happy-path doc. A new engineer who blocks blindly will ship a date that looks fine and a bill that is wrong.

Overdue can skip WARNING. After a customer pays some invoices but not all, the earliest unpaid date shifts. The next check can fire late and jump CLEAR → BLOCKED, so no grace email. We posted a repro; the team tracked it (GitHub #2297). Some balance / invoice-count jumps they treat as expected if your XML gaps are too small. Turning overdue on late, when old invoices already blow every threshold, can go straight to cancellation unless you plan tags or temporary day values.

New add-ons vs existing subscriptions: catalog V2 adds an add-on, old subs still fail with 1019. Plan-change-to-same-plan unlocks it but can rebill on MONTHLY mid-cycle (#2261). Painful when the catalog evolves.

IN_ARREAR cancel after an upgrade used to invoice recurring immediately vs end-of-term depending on whether a cycle had already closed. I hit that on 0.22.33, then walked the releases and found the change around 0.24.5 (a condition in the invoicing path). After we moved to that line, the cancel timing matched what we expected. Daily unblock is still a design limit: a few minutes before midnight can bill a full previous day, because Kill Bill does not invoice below a day — you design the clock, the engine will not split the day for you.

I am still learning the behaviour. That time is the real cost. Buyers should budget an engineer who will sit with the dates — not only an integration ticket.

What problems is the product solving and how is that benefiting you?

Before Kill Bill, our billing work struggled on what customers actually ask for: auto-renewal, add-ons, postpaid (IN_ARREAR), discounts on the invoice, and block / unblock when service should stop or resume. A checkout tool does not own that. Building it from scratch is years of invoice math.

Kill Bill is the BSS. Our app stays product and UX; Kill Bill generates invoices, tracks charged-through dates, applies catalog rules, and drives blocking states. I introduced most of those capabilities here by learning how the engine behaves and wiring the right calls and plugins.

Two concrete wins. Discounts: an invoice plugin lets us change line items at generation time, not after the invoice already exists. Auto-renewal / block: the end date is an exact invoice-generation day. If requestedDate is wrong, the block lands on the next day and you get proration or an extra charge. If you omit the date, it is immediate — as the docs say. I use a few API shapes so the effective day matches that generation date.

The benefit is we can ship those features at all, prove them from invoices and source, and extend via plugins without forking the core. I am still learning. The engine is worth it if someone on the team will own the dates.

What do you like best about the product?

Kill Bill is a performant, open source billing solution. It runs on Linux, which was a requirement. It integrates well with our application through REST endpoints while our application supplies the customer facing user experience. In addition, it is extensible through plugins. The developer community is active and responds quickly to questions and issues.

The apis and the catalog and subscription management system are very robust. This provides us the necessary tools to layer on our own subscription and account management UX. The plugin apis provided the means for critical extensions for our niche market. The API documentation is also quite good. For any endpoint, all the necessary user information can be found there.

What do you dislike about the product?

It is complex to get started. This can initially be a little discouraging. It has an administration interface, but the interface is a bit confusing when getting started. However, as the application grew, the administration system (Kaui) design became more obvious. Ultimately, it proved powerful. But we had to move past that initial feeling. The catalog too is very powerful but also complicated. Errors are strictly rejected so it takes some getting used to. In addition to complexity, there have been issues with manually correcting account errors. During error testing, account state has occasionally become corrupted with no clear way to reconcile the account manually. Eventually, we wound up decoupling the accounts from the app accounts so that in these rare cases, support can reset the user with a completely new account.

What problems is the product solving and how is that benefiting you?

Kill Bill provides business flexibility for our SaaS offering. Our mission is to promote innovation and entrepreneurship for our customers through flexible pricing models that provide easy, staged access that adapt with their business as they develop proficiency with new features and resource consumption grows. Through the catalog and subscription services, Kill Bill allows us to offer diverse plans to achieve this goal. The open source and plugin architecture give us the freedom to immediately take Kill Bill where we need it go go, and then submit the best of these extensions for consideration in the future. The current payment plugins allow us to adapt to our intended market, and pursue additional relationships with providers as necessary.