by Stéphane Brossier | Jul 26, 2018 | Billing Systems, Payments
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...
by Pierre-Alexandre Meyer | Jul 18, 2018 | Billing Systems
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...
by Stéphane Brossier | Jul 12, 2018 | Billing Systems, Payments
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...
by Pierre-Alexandre Meyer | Dec 8, 2017 | Payments
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...
by Stéphane Brossier | Aug 8, 2017 | Billing Systems, Payments
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...
by Pierre-Alexandre Meyer | Apr 12, 2017 | The Kill Bill Story
It’s hard to believe that Kill Bill is turning 6 already! I still remember that afternoon in Palo Alto when we decided to start the open-source project: Stéphane reluctantly rushed to his ophthalmology appointment while I got started on writing a Jetty skeleton. As soon as he came back, we pair programmed what would eventually become the Kill Bill platform. Over the next two years, while migrating the subscriptions of the 100,000 Ning-powered sites, we exposed ourselves to the complexity of the subscription billing world and the myriad of its use-cases as more and more users started reaching out to our mailing-list. More recently, we deepened our integration with the payments world by adding support for all sorts of international payment methods required for the Groupon migration. Join us, as we look back at our journey, in San Francisco on Thursday, July 13, for an evening of celebration, featuring presentations by various companies using Kill Bill in the real world. Here’s to the next 6 years! Kill Bill Birthday #6 Celebration Thursday, Jul 13, 2017, 6:30 PM Location details are available to members only. 14 Members Attending Join us in celebrating Kill Bill’s 6th birthday!Existing users and newcomers, join us to (re-)discover all of the features Kill Bill, the open-source subscription billing and payments platform has to offer, and to learn from others using the system.https://www.youtube.com/watch?v=f2IHcz3OLYoAgenda6:00 – Doors Open* 6:30 – Welcome message by th… Check out this Meetup →...
by Stéphane Brossier | Mar 24, 2017 | Payments
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...
by Stéphane Brossier | Jan 9, 2017 | Billing Systems, Kill Bill Internals, Payments
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....
by Pierre-Alexandre Meyer | Oct 21, 2016 | System Integration
We are excited to announce our brand new integration with Dwolla! Lots of traditional credit card payment gateways have added support for ACH over the years. These APIs lowered the barrier of entry for merchants to accept bank to bank transfers. Unfortunately, virtually all implementations offer transfer times of at least 3 to 4 days. Introducing Dwolla: the company has built over the years a robust infrastructure specifically designed to offer a more modern way to access and leverage the ACH transfer network. The result reduces the transaction time down to as little one day and provides the building blocks for all sorts of integrations, business models, payment flows and end-user experiences (your users don’t even need a Dwolla account). You can trigger a payment by having your customers authenticate into their online banking account, recurring, variable payments for subscriptions are supported through On-Demand Transfers and you can even trigger payouts if you are a marketplace. Building this integration had been on our radar for a very long time, but we just never had the time to focus on it. Luckily, once again, the community helped. A consulting firm from Argentina took on the task, and they did a terrific job implementing a full solution! This new plugin supports both Dwolla Direct (co-branded product, easier to setup), as well as Dwolla White Label (for deeper, seamless experiences within your own native applications). Funding sources can be verified through both IAV (Instant Account Verification) and Micro-deposit verifications, and Dwolla.js makes sure that no sensitive payment information hits your servers. You can even configure it to listen to webhooks, to get...
by Stéphane Brossier | Sep 27, 2016 | Payments
There has been a lot of ink written about software models and why/when it makes sense to use open-source software (OSS); there was recently an interesting article about that specific topic. The short story is that such decision is based on many different factors, including the available options (OSS and non OSS), engineering organization, short term/long term choices, company DNA, … In this post, i would like to focus on our project specifically by asking two questions, one addressed to folks looking for billing and payment solutions and one to the Kill Bill team (note that i am both asking the questions and answering them for all parties, which is quite convenient…) Fictitious Journalist: “So, you are looking for billing and payment solutions, what are your choices, why Kill Bill?” In the world of billing and payments, companies are left with 3 main options (all of them with their pros/cons): 1. SAAS model This is often presented as a turn key option that will solve all your problems so you can focus on your IP and not be distracted by things that are irrelevant to your business: This statement is true in the sense that pretty much any developer using (pretty much any language of his choice) could quickly integrate with a SAAS business and start processing subscriptions, or making payments through a gateway. However, it is also misleading for the following reasons: Each business will need its special business logic and so simply using the raw apis from the SAAS will not be enough; often there is a need for another system in front of that SAAS (to implement...
