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 (SOX, PII, PCI, …)
Feel free to reach out on the mailing list for any questions or clarifications!
