Kill Bill wasn’t our first billing system. As we developed these systems, even though the very core always looked the same (i.e. compute invoices and charge customers on a regular basis), it became obvious that each and every one of them required a great deal of flexibility and heavy business logic customization. In Kill Bill, while we addressed the need for plan customization via our catalog module and its set of rules and policies, we developed a plugin framework for pretty much anything else, from reacting to system events to third party integrations. When designing this plugin framework, we quickly settled for an OSGI integration. This gave us a lot of features for free, such as lifecycle and isolation, and allowed us to support non Kill Bill specific bundles (we call these platform plugins). As an example, we run in production the Felix Web Console, which is a great debugging tool. OSGI is quite a complex framework though, so we tried to hide as much complexity as possible from the user who simply wants to develop a Kill Bill specific plugin. We made it so that all that is required is to implement certain interfaces that Kill Bill will use to communicate with the plugin. The type of interfaces implemented determine the type of plugin. The first type of plugin supported is payment plugins. By default, Kill Bill doesn’t know about any payment gateway. Instead, each account has a series of payment methods (credit cards, PayPal accounts, Bitcoin wallets, etc.) attached to it, and each payment method is associated with a given plugin. There is no built-in concept of credit...
