When you look at the marketing slides for various SaaS billing software, you usually see colorful charts with checkmarks and Xs, similar to this feature comparison of the Kill Bill platform with SaaS billing systems.
Feature comparisons are okay, but the main difference between Kill Bill and other billing systems is not the features. It’s actually woven into the billing system design and architecture, an open model that we adopted from the beginning:
- Open source
- Open data
- Open architecture
So, while Kill Bill is a billing and payments system, it’s also a platform for building billing and payment systems.
Open Source
When we began designing and creating the Kill Bill platform, we decided to go open-source. Open-source software is brilliant for many reasons, like sharing knowledge to help all of us harness Kill Bill for our specific use cases and bug detection. Being open-source also makes it simpler to maintain the open billing system design and architecture – the modularity – of Kill Bill.
Creating Kill Bill as open-source software forced us to make the code as clean as possible. We didn’t impose our business logic onto the system (even though we were developing Kill Bill for a particular organization at the time). We needed to abstract the business logic and have modular code.
Open Data
What we mean by open data is owning your data, the ability to save it, retrieve it, manipulate it in any way necessary.
We had learned from experience that when we didn’t have full access to billing and payment data, it forced us to create workarounds, like a proxy in front of a SaaS billing system. But this causes you to code on top of a system you have no control over, leading to the proxy breaking or not working reliably. (You also deal with unhappy executives who don’t have their numbers. If the executives aren’t happy, nobody’s happy.)
When you have complete control over your billing system and its data, accessing the numbers and generating the reports that keep the execs happy is vastly simpler.
Open Architecture
As mentioned above in the “Open Source” section, Kill Bill is modular and relatively generic. But don’t get me wrong; out of the box, Kill Bill has plenty of features.
But it’s likely that Kill Bill won’t immediately fit your specific business needs. You need something else on top of it, a way to tweak that system to become the system you want. That’s what we mean by open architecture.
Kill Bill Architecture
This section is a high-level view of the Kill Bill architecture.
Note: For more detail on the Kill Bill system architecture, check out this blog post.
Platform
The platform handles the life cycle for the core services: initializing, starting, stopping (and so forth). Something different about Kill Bill is that it is event-based (instead of being batch-oriented). Every time there is a change in the system, the system emits an event, and the whole system will be aware of it.
Core Services
The core services are the bulk of the billing and payment code. Subscriptions, entitlement, invoicing, payment, dunning… everything.
Plugins
On top of it, we have the plugins. Plugins could be those we wrote ourselves because they are rather generic (for instance, integration with a payment gateway). Or the plugins could be the place where you have your business logic to tweak the system in the way you want. We cover plugins in detail in this blog post.
JAX-RS Layer
The JAX-RS layer offers HTTP REST APIs on top of the core services. So, while you can use Kill Bill as an embedded library, most users will probably want to use it as a web application.
Thanks for stopping by!
Kill Bill’s strength lies in its open architecture, open-source code, and open data. It takes time and effort to tweak Kill Bill to conform to your business needs. However, it’s much better to put in this time/effort upfront rather than struggling with a billing system that forces you to work in a specific way (their way!).
Trust us. We’ve been there. A billing and payment system that doesn’t work for you or your customers will quickly become a nightmare.
