Announcing Kill Bill release 0.20

Announcing Kill Bill release 0.20

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...
API, documentation and client libraries

API, documentation and client libraries

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...
Kaui 0.16 Release

Kaui 0.16 Release

We are pleased to announce that Kaui 0.16 has shipped! Kaui, the Kill Bill Admin UI, is an invaluable tool complementing any Kill Bill deployment. Customer Service agents use it to see and modify customers accounts and subscriptions while on the phone, Product Managers to push updates to the product catalog in real time, and developers to test and debug the system. A lot has happened since our last 0.15 release, so we figured we’d share some of the highlights. New features The Hierarchical Accounts feature is now fully integrated with the account screen: you can add, update and delete relationships, as well as navigate through the accounts hierarchy. In 0.15, we had introduced catalog management screens. We have now done the same for the Overdue (dunning) configuration. Configuration Auditing is a core feature of Kill Bill to help with compliance. As a matter of fact, any write API operation requires specifying the user requesting the change and a reason code. While these are free-form fields at the API level, these reason codes used to be hard-coded in Kaui. They are now configurable to match your own compliance requirements. On the topic of Role-based access control (RBAC), users stored in a third-party directory (such as LDAP or Okta) are now supported. Payment specific features We have done a lot of work over the past couple of years on our payment subsystem. We have now integrated some of these features into Kaui. Plugin specific properties can be specified when adding a payment method or triggering a payment operation. Similarly, control plugins can be specified on the process transaction screen. The...
Kill Bill Payment Bridge Plugin

Kill Bill Payment Bridge Plugin

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...
ACH simplified through Dwolla

ACH simplified through Dwolla

This is a guest blog post written for Kill Bill by Andrew T., a developer at Dwolla. Dwolla’s Access API has been integrated with Kill Bill’s subscription billing platform to provide access to the ACH network. Learn more about the Kill Bill & Dwolla partnership. At Dwolla, we have spent a lot of time making it as simple as possible to send ACH bank transfers. With one API call, you can initiate a transfer of funds from one of your customer’s bank accounts, into the Dwolla “Account”, and then out to another customer’s bank account. From a technical perspective, this is accomplished by using Hypertext Application Language (HAL) hyperlinks to describe the source and ultimate destination of the transfer, rather than by sending ACH routing information to our API for every transfer: { “_links”:{ “source”:{ “href”:”https://api.dwolla.com/funding-sources/{sender-funding-source-id}” }, “destination”:{ “href”:”https://api.dwolla.com/funding-sources/{receiver-funding-source-id}” } }, “amount”:{ “value”:”12.00″, “currency”:”USD” } } Have you ever wondered what Dwolla is doing behind the scenes to make the sometimes complicated or confusing ACH network available within a payments API? First off, what is ACH? The Automated Clearing House (ACH) is an electronic network that allows originators to transfer money by debiting or crediting U.S. bank accounts. At a high level, an Originating Depository Financial Institution (ODFI) submits a file containing specific instructions to an ACH Operator. These instructions are used to locate the account (routing number, account number, account type, account holder’s name,…) as well as the amount to credit or debit. The ACH Operator uses these instructions to locate the Receiving Depository Financial Institution (RDFI), and the RDFI can then credit or debit the specific bank...
Kill Bill 0.18.x Release

Kill Bill 0.18.x Release

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....