FAQ

Kill Bill is an open-source project which started at Ning in 2010 by Martin Westhead, Pierre-Alexandre Meyer and Stéphane Brossier.

You can follow our blog, to get insights on what the team is working on.

All of our code is hosted on Github, in the killbill organization. The core of the Kill Bill platform can be found here.

Contrary to any SaaS solution:

Because you host your own instances, you are in full control of your data. Note though that the Kill Bill platform reports anonymous data on startup to Google Analytics for development purposes.

The core development team is primarily interested in:

Data is anonymous and not shared with any third-party. No financial data is collected (the code can be found here).

To disable tracking, specify org.killbill.server.updateCheck.skip=true in your killbill.properties.

We are relying on this data to help us focus our development efforts. If your environment prevents you from sharing this automatically, but would like to help, please reach out to the mailing-list instead and describe your deployment. Thanks in advance!

All contributed code must be license under the Apache License, Version 2.0.

Kill Bill is currently running in production in private and public companies, and has been invoicing billions of dollars and charging millions of credit cards over the past years. We perform thousands of tests before each release, and introduce regression tests whenever bugs are discovered.

Note though that Kill Bill is a platform to build billing systems. There are lots of combinations of configurations possible and we cannot test them all. We provide a test framework to help you verify your system before going to production. Take also extra care when installing third-party plugins (only the plugins hosted on our GitHub organization are officially supported).

There are two release trains:

There are thousands of tests that we perform before each release:

Yes! We try to hide most of the complexity so you can use simply Kill Bill as a service, using our client libraries. Currently, plugins can only be written in Java or Ruby though.

Try our Getting Started tutorial.

The core of the platform is agnostic to the type of billing you use: Kill Bill supports recurring billing, usage billing and one-time transactions. Kill Bill is designed to be modular and most features can be turned on or off as you need. See our Usage documentation to understand the various types of usage Kill Bill supports.

There are various ways of customizing Kill Bill. Besides System Properties, which let you configure the core platform, most internal modules have a second, more advanced, layer of configuration, usually through XML files. These let you configure the dunning (overdue) policy, the various plans and billing policies, etc.

If you need more advanced (billing or non-billing) logic, Kill Bill has a plugin capability. You can write custom code (in Java or Ruby) to extend or even override Kill Bill default behaviors.

Finally, Kill Bill is open-source! We are happy to accept contributions.

The core of the billing platform was designed to be internationalized. The catalog module has support for all currencies, including crypto-currencies (e.g. Bitcoin). The invoice module will understand these various currencies and respect localization rules. For example, it will correctly round US dollars to two decimal places but Japanese Yen amounts will have no decimal portion.

Accounts can have a designated locale (for example, $1,234.99 will be displayed as 1.234,99 $ for accounts with the French Canada locale) and timezone (to generate invoices in their timezone, instead of the merchant’s).

From a payment perspective, Kill Bill supports payment gateways via plugins. If your international gateway isn’t supported yet, you can simply write a plugin for it. All of Active Merchant processors for instance can be handled.

A bundle is a collection of subscriptions. A typical bundle has exactly one BASE subscription and a collection of ADD_ONs. Grouping logically these subscriptions together makes it easier to automatically cancel all ADD_ONs when the BASE subscription is cancelled for example.

Yes! If you are not ready to charge your customers (for example, during an activation phase), you can configure your plan with an initial free phase. Alternatively, you can set the AUTO_PAY_OFF tag to their account and Kill Bill will generate invoices but won’t attempt to charge them. When you decide to remove this tag, payments will automatically occur.

Absolutely! This can be useful during onboarding flows, if you need your customer in your CRM engine, databases, etc. but before she has actually signed-up.

Kill Bill supports all credit and debit cards your payment gateway supports. Additionally, tracking of external payments (ACH, checks, cash, …​) is also a feature: when you receive the money, simply let Kill Bill know about it (either via our administrative UI or our APIs).

Even if Kill Bill is used in PCI compliant companies today, it is your responsibility to get certified. Depending on how you plan to use Kill Bill, you can outsource most of the PCI complexity to your payment gateway by not storing credit card information. Check the PCI DSS website for more information.

While it is your responsability to ensure you remain compliant, Kill Bill avoids storing any PII information by default.

Here are some general tips on securing your Kill Bill installation:

It is eventually your responsibility to make sure your Kill Bill installation is secure and compliant.

At a high level, collecting sales tax seems easy. In the US, one may think that each state has its own rate (e.g. 9.25% in NY) and adding rates to an invoice total boils down to adding a single line item. Same story with VAT in Europe (e.g. simply add 20%).

In practice, taxation is not that simple unfortunately. Here are a few examples to highlight this complexity in the US:

Rules also change constantly. In 2015, software products were taxed 450 different ways across 45 different categories. If you are selling in more than 2 states, it is impossible to keep-up with tax laws without an in-house research team.

For these reasons alone, we’ve decided to partner with Avalara to outsource tax compliance. Our AvaTax connector provides real-time and on-demand calculations to prevent overcharging or undercharging tax.

For those of you with an European presence, while VAT calculation might be simpler, integrating Avalara lets you leverage their filing service across the EU (they do also offer fiscal representation wherever needed).

Finally, their pricing model seeks to bill whenever value has been provided: you are only billed when tax decisions are needed, which makes it a very affordable service.

A free sandbox is available at https://www.avalara.com/integrations/killbill/ or contact us for an introduction. The plugin can be downloaded here.

If you have a very large catalog (e.g. thousands of products) and/or if it is highly dynamic, maintaining the catalog as an XML file may not be practical. Instead, you can use the CatalogPluginApi to write a plugin that would provide an alternative catalog implementation (such as integrating with your existing catalog system). See the documentation.

Here are Java and Ruby examples.

There are several ways to handle coupons and discounts:

For more details, check this blog post.

The email notifications plugin lets you send emails to your customers regarding upcoming invoices, payment successes and failures, subscription cancellations, etc.

Kill Bill has successfully been deployed in private datacenters as well as in AWS, Heroku, OpenShift, Azure, etc. We also provide scripts to ease the deployment story. Check out the killbill-cloud repo on Github.

This is a tough one to answer as it depends on the plugins you want to be running, your expected traffic, etc. If in doubt, send us your details on the mailing-list.

You can either write a custom plugin (all Kill Bill events are visible to plugins) or register an endpoint that Kill Bill will send events to via HTTP POST (check our push notifications documentation).

Find the project you want to contribute to on GitHub and follow the Fork & Pull Collaborative Development Model. If you are not sure where to start, drop us a note on the mailing-list.

See our developer documentation.

See our debugging documentation.

When asking for help on the mailing-list, provide us your catalog XML, server side logs and curl commands to reproduce the problem. Additional information, such as your JVM, container and OS versions, are very helpful too.