What do you like best about Kill Bill?
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. Review collected by and hosted on G2.com.
What do you dislike about Kill Bill?
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. Review collected by and hosted on G2.com.
