We are very pleased to announce the new Kill Bill 0.20.x release train (current version at the time of this blog is 0.20.1). This has been a long cycle and a lot has happened since our 0.18.x release. If anything, comparing the picture we posted when we released 0.18.0 a year and a half ago, we can see that the Salesforce tower has now been completed. So, what kind of tower have we completed on our end? This blog post will surface some of the main things we (and the community) have achieved during this time. Kill Bill Core On the Kill Bill core side, our release notes go into some amount of details about the main changes. A lot of those changes have been driven by real customer uses cases, to provide more control on how the system behaves. In fact, this release is not adding a whole lot of new features per say, but instead, is focused on extending and refining what we already offer with the intent to address each and every possible use cases. After 7 years of development, Kill Bill already provides a lot of features, and one of the main reasons for users to choose Kill Bill – besides the fact that it is open-source and free to use — is the ability to configure a system that will address one’s specific needs. In this release, we have made some modifications on the catalog for finer control through a plugin API, provided additional configuration hooks on the invoice level to refine invoicing behavior, and enhanced our payment control plugin API for more control. And of...
Over the past year, we continued to invest heavily in Kaui, the Kill Bill Admin UI. While originally it was only used by Customer Support teams, it has now become a swiss army knife for developers, operations, finance teams and product managers. Going through all of the usability improvements, bug fixes, and new features we’ve made for Kill Bill 0.20 would require several blog posts — here are just the highlights. New features We now offer an advanced search functionality: any object in Kill Bill is pretty much searchable. We also have new audit and history screens, displaying the full history of objects and what changed over time. Usability updates The Catalog screen has been improved with the ability to switch between the simple view and the full XML view. Performance has also greatly been improved (one user tested with his catalog, containing over 50 versions, producing a 140M+ JSON!). The plugins configuration tab has now a simple view for when the administrator only need to configure basic properties. The advanced view, providing full configuration, is of course still available. With regulations like SOX and PCI, developers have less and less access to production environments nowadays. Not being able to grep through logs or issue free-form SQL queries can make it difficult to track down issues. As a workaround, we worked hard to expose more and more information through the UI without cluttering it by default. While UUIDs are still being truncated by default (the idea being that, most of the time, you only match by the last few characters when glancing over the screen), positioning the cursor over...
After 7 years of improving our code base and answering diligently questions on our mailing list , we have decided that one of the main focus of our upcoming 0.20 release should be focused around API and documentation. We have worked on a series of initiatives, all related to these particular topics: APIs On the API side, our effort has been mostly focused on the endpoints — HTTP/REST level API — to make sure we reach some level of consistency. So, we went through our 250+ available endpoints and re-visited things like http verb, json format, http headers, http status to make those as uniform as possible. As we were doing that work, we took a second pass at all the Swagger annotations to make sure they are aligned with the code, and therefore we end up with a Swagger doc that is as precise as it can be. One nice side effect of doing this work, is that we are then able to rely on existing Swagger tools to start generating client code: At this point we have 3 fully generated client libraries: Java client Python client GO client: This came as an external contribution from the folks at Google — thanks Prem! On that side, also note the nice go command line contribution. For other languages — e.g ruby client –, we are still using our manually generated client libraries for now but code contributions to work on the swagger codegen are welcome 😉 Documentation On the documentation side, we have worked on the following aspects: We have aggregated our different docs under http://docs.killbill.io/ to make it...
When we first started the work on Kill Bill 6 years ago, our original focus was centered around subscription billing/invoicing and the payment system was mostly a side module used to pay existing invoices. In the last 3 years, we have shared our resources between enhancing the original subscription/invoicing system and developing a fully mature payment system, mostly to accommodate the complex needs of building a global payment platform for Groupon. At this point, a typical elevator conversation such as “So, what is Kill Bill?” became harder to answer before reaching the destination floor: Should we talk about billing system — large topic in itself — or payment routing and optimization — another deep topic? What’s interesting here is not the answer but the question itself: Kill Bill can be used as a billing system, but can also be used independently as a payment platform. More so, we have just released a new payment plugin that can be used to bridge 2 different deployments of Kill Bill, one used for billing needs and one used for serving payment needs. There are quite a few good reasons to deploy 2 distinctive systems: Keeping invoice/subscription engine separate from payment system fits well in a micro-services architecture model Related to previous micro-services architecture point, this also allows to decouple the responsibilities — different teams, deployment schedule, … Allow to fully leverage the internal payment gateway to implement more advanced things like payment routing, payment optimization, … while keeping all this aspect hidden from core subscription/invoice engine Use the payment platform for other part of the organization (e.g selling goods) Different compliance scopes...
We are very eager to announce the new Kill Bill 0.18.x release train (current version at the time of this blog is 0.18.2). Our last announcement for a ‘major’ release (see current Kill Bill versioning scheme) was almost a year ago . Since this release somehow coincides with the end of the year, it feels natural to not only review what it contains but also to provide an overview of what happened through 2016. Obviously, a lot has happened in a year and this blog post will just touch the surface of some of the main things we (and the community) achieved. Main New Features: At this point the platform is already pretty features-rich, and each new feature brings further complexity and also has the potential to destabilize the system. So, we have to balance fulfilling the desire of some of our (most loyal) users with the stability and risk associated with such new features. Some of the main features we added are: Hierarchical Account Shopping Card Apis Blocking State Abstraction Migration Apis (along with migration guide) Subscription Bill cycle day (BCD) change Subsystem/Feature Rework: With more adoption comes more bug reports, use cases we never thought of, … and so a large part of the work we did throughout the year was about hardening and enhancing the various sub-modules. Catalog: A lot of effort was invested in the catalog to address some of the shortcomings (e.g. ability to have plans of different shapes on the same pricelist), provide apis to dynamically add Plans on the current version of a catalog, harden validation, and greatly improve performance for large catalogs....
Until now, Kill Bill only allowed to configure the Bill Cycle Day (BCD) attached to each subscription through the use of billing alignment catalog rules. As a reminder, the BCD defines the day when a specific subscription gets billed. For instance assuming customers get billed in advance, then creating a monthly subscription on 6/1/2016 with a BCD=1 would generate a first invoice on the 6/1/2016 for the month of June, and then a next invoice on July 1st for the month of July, etc… In the current scheme, there are 3 different possible billing alignment policies, that are configured using special catalog rules: ACCOUNT: All subscriptions whose Plan is defined with an ACCOUNT alignment will use the same account level BCD. This allows to group all subscriptions for an account on the same invoice. The BCD is either set using api, or if not set, the system will infer that BCD when the first subscription on the account is created (by looking at the first Phase in the Plan whose recurring price is not 0). SUBSCRIPTION: The BCD is based on the subscription startDate and by also looking at the first Phase in the Plan whose recurring price is not 0. BUNDLE: This is similar to the SUBSCRIPTION case but the system will use the start date of the base subscription to compute the BCD. With the existing mechanism, the administrator configures once the various policies in the catalog and then everything happens automatically. This approach is convenient but rather static (does not allow to change a BCD for an existing subscription). In order to provide a more dynamic...
