KillBill – Open-Source Subscription Billing and Payment Platform | Hacker News Reader

KillBill – Open-Source Subscription Billing and Payment Platform

killbill.io

167 pointstortilla44 comments

NICE. I've been looking for something like this for a while. The problem with subscription startups like chargebee, recurly, etc. is vendor lockin. Why lock the most fundamental part of your business into an unproven startup? That's a hard bargain to drive, even if the charts are really pretty.

There's no reason that Chargebee, Recurly could not be emulated in open source software. The solution to the saas problem is simply a nice API + dashboard, with pluggable billing backends. You should be able to swap merchant accounts seamlessly, since that's the biggest point of failure.

What would be nice is a "launch KillBill on digitalocean" button (I think someone posted a Show HN like this recently?) so that you could launch your own service and start using it immediately.

More generally, I think a lot of SaaS startups are ripe for disruption from open source projects. However, many projects miss the mark of usability. What people need is a self-hosted, open source API that's as usable as chargebee or recurly, for instance. This means that OSS should be targeting microservice architectures more often, instead of self contained solutions with a bunch of wiring required. I want to see more OSS projects that are structured as a standalone app server with an API and dashboard, so that you can self-host but still get the benefits of a composable API.

A good example of an open-source project leveraging "microservice architecture" for self hosted solutions is Seatgeek's AB testing project, sixpack. [0]

[0] https://github.com/seatgeek/sixpack

@pierre from Kill Bill here.

I saw the DO button post this morning, pretty cool indeed. We've recently been playing with Docker to standardize our deployments. Pushing an image to DO should be easy.

http://killbill.io/blog/having-fun-with-docker-stripe-kill-b...

Yeehaw! That's exactly what I'm looking for. I think I stumbled upon Killbill over the summer but it wasn't quite where it is today. I'll definitely be taking a hard look at this.

Hope you don't mind if I hijack the thread a bit. I'm curious what your business model is, how does Kill Bill make money?

Do you offer paid support and hosting?

I'm asking because I'm a big fan and proponent of OSS, but I often struggle to see or understand the business models for OSS companies.

I'm wondering the same and obviously can't answer for them, but it looks like killbill is a two person side project. If they intend to monetize it, I'm sure they could do so by offering a hosted version of the library.

Very nice indeed, I likewise have been looking for something like this and couldn't find a solution that's not either over-simplistic, or over-engineered "enterprisy" and expensive... until this.

If you're looking for a solution that's integrated more tightly into your app I recently put together Payola[1], which is specifically for Stripe and Rails. The PCI requirements are the same as with Stripe generally (don't store things the API doesn't return, use HTTPS, use stripe.js, fill out any forms they ask you to fill out, etc).

[1]: https://www.payola.io

I really dig this, I think I might use your project as a reference to create a Django equivalent.

Awesome!

I think this is a fascinating experiment and will be interested to see how this goes. Many people look at Open Source and say "Why would I pay ChargeBee or Recurly $300 or $3000 per month when this is free?" Seems like a no brainer. But when it's running your billing and it's driving $100,000 or $1 million a month in revenue then it's looked at from an entirely different view. Saving $1000 a month is great but if it means you are missing out on $5000 or $10,000 because you can't support a business model then it isn't such a great proposition. Now I'm not saying Kill Bill is better or worse than the alternatives. Just that open source solutions where the effects on productivity and revenue are so clear are judged by a different type of measurement than other areas.

Good luck!

Very interesting, and I would definitely see a use. Just a few comments:

- How does this fit into the PCI picture, only thing I have seen on the site is a 2 line faq entry. Not enough to help on scoping or identifying requirements that would apply.

- How secure is it, and how are security notifications done? Keeping the software secure and up to date should be considered as critical. I would add a section on the site pertaining to security and addressing vulnerabilities. I did not see on the site information about security updates/patches. They might be on GitHub but it is way to deep to be useful to most people.

This kind of software is a perfect example of a high-value target for intrusion, I am a bit worried for the security of the information it contains, especially for smaller startups with limited resources, as well as zombie installations that can be forgotten in a corner with personal information or cards information inside.

Not saying it's a bad idea BTW, just a few concerns as a security analyst.

Good point, we'll update the docs.

Regarding PCI, it's up to you. You can run it inside your PCI environment or delegate it to your payment provider (via CC tokenization).

If your company has a PCI environment, i'm not that worried (you probably have a pretty good idea of what you are doing, at least in theory), but most startups do not have this, as far as I know. Most just want to get a product/service out of the door. This is where I get worried :-)

It is very easy to setup a system in a corner (here, we'll install this piece of software, that will save us the 99$/month recurly subscription...) then forget about it until it is too late...

Some guidance would be very important, as well as mentioning ways to make it more secure, including tokenization, logging of CC numbers in server logs, knowing if the data transits through your server or not depending on provider, maybe even keep the software behind a a firewall without internet access, these can make a big difference in managing the risk.

As an open source project, you cannot be held responsible on what the people using the software is doing, but I think making sure that they understand that even if the software is free and easy to install and use, that additional work is required to make sure that the data is safe.

mentioning ways to make it more secure, including tokenization, logging of CC numbers in server logs, knowing if the data transits through your server or not depending on provider

"logging of CC numbers in server logs" is an almost guaranteed way to make your setup not PCI compliant.

The PCI industry as a whole is missing a lot of this kind of guidance, in general. There's no "here's the minimum you need to do to be PCI Level X compliant". The reason is that the industry considers every situation to be different (I doubt most are all that different or if they are, 90% of them can fit into a handful of buckets), and you're supposed to hire PCI auditors to come in and certify you. Another reason there are no minimum guidelines is that PCI seems to be more about awareness than actual specific architecture. You can sidestep certain things as long as you document them and what your mitigating implementation is. This leads to...

Last time I went through a PCI setup, it was a unspoken spoken rule that if we hired an auditor that didn't certify us even though we thought we should be, we could hire a different auditor, and keep doing so until we got one we liked.

Billing is such a complicated beast for most startups. I've been working on one for about a year and we were waiting until we got some traction to finally tackle it. We have multiple products as well as multiple plans per product.

We had a difficult time trying to find a solution and recently just built our own package that would drop right into our startup. Another feature we wanted was portability of our business critical data like invoices and transactions so we went with a multi gateway approach so we can switch if we need to down the road.

For those who use Laravel the package is at http://github.com/mmanos/laravel-billing. We also worked a while back on an open source project for a time called Volcano http://github.com/volcano/volcano.

I met the guys from KillBill at the Money 20/20 Hackathon and I think they're doing a great job with their platform, which is already serving big players like GroupOn. They clearly know the payment ecosystem and this is a good way to set up billing in a way that does not lock you in and gives you flexibility for the future as you scale your business, including Fraud Prevention plugins. Disclaimer: I'm product lead at Feedzai, one of their supported Fraud Prevention solutions.

Oh god, I hate online billing. I try to download my statements every month from a cron job, and some are fairly easy to script with WWW::Mechanize, others are monstrous. My retirement account statement actually kicks you out if it can figure out that it's a robot doing the access... as if this is an inherently evil status.

Please, please, please, whoever writes for this... make automated statement downloads a thing. Make it a fucking default option.

If you are big I think it makes sense to control every part of your business but otherwise it's massive headache because of security and taxes, especially now that the EU wants to collect VAT for european customers even from companies that are outside EU, there are payment services that do all the tax things and even if the fees are higher if you are small it will cost you less and keep you focused on growing.

There are third-party solutions which can take care of tax calculations for you - these can be plugged into Kill Bill.

One of the main core values of Kill Bill is that you own your data: this is especially important if you focus on growth, so you can run real-time reports on MRR, churn rates, upsells, etc.

This looks like a good solution for larger companies, but (someone correct me if I'm wrong) it likely won't be a good fit for a fast moving startup. The last thing you want to worry about when developing a product is PCI compliance and other security measures. Platforms like Braintree and Stripe allow you to bypass most of this as CC and Bank info never really touch or pass through your own servers.

You can still delegate PCI to your payment provider (via tokenization). SafeKiddo[0] just launched using Kill Bill + Braintree.

[0] https://www.safekiddo.com/

PCI DSS 3.0 will change that

Not substantially. You'll need to do minimal, common-sense things on your servers (firewalls, IDS, etc) and certify that you're not storing anything interesting.

What did SafeKiddo see in the Kill Bill API's that was lacking in Braintree's own recurring/subscription API's?

There are small things - e.g. you can't do weekly / fortnightly billing.

Once I discovered that I stopped investigating BT for our primary subscription engine. We just hold the card tokens and use BT to charge the card.

It's not ideal, but it does give us more flexibility.

Got it. Thanks very much.

I can see the value of having an OSS solution as an API layer for any start-up that has complex billing needs.

A lot of start-ups make the "mistake" [1] of locking themselves into fundamental business services at the start: whether that's a payment provider, finance or CRM system. In my experience it's fine for a while, but you really feel the problems as you start to scale the business. Everything creaks and groans as you grow, and then you have to go back and fix the underlying business processes. Issues in some of these areas are actual company killers. Billing is a classic. Lots of companies fail due to running out of cash, and poor management of subscriptions and billing is often the underlying issue. There's a lot to be said for not getting tied in early on, and making sure the fundamental architecture is right!

[1] You can argue it's not a "mistake" as the primary goal is to relentlessly focus on shipping product that customers want.

Everybody talks about PCI compliance as if it's some huge obstacle impossible for startups to overcome. It's actually extremely simple. See the requirements on the last page of this doc. [0]

Basically, what you need is:

- Firewall (default on almost any cloud host)

- No vendor-supplied default passwords (not audited, and you should do this anyway)

- Encrypt the credit card number IF YOU STORE IT AT ALL

- Put a privacy policy on your homepage

That's it. Super easy. Takes an hour. The hardest part is writing (or copying) a privacy policy. If you aren't storing credit cards, it's even easier to be PCI compliant.

[0] https://www.pcisecuritystandards.org/documents/PCI_DSS_v3_AO...

> You and every other Kill Bill user can check it for accuracy and security flaws.

I mean, sure, but... there's got to be a better way to phrase that.

I've been following this for a while, any companies besides Ning have any good experience with this system?

@stephane from Kill Bill.

Groupon is also using the platform (https://engineering.groupon.com/2014/misc/groupon-adopts-kil...)

I'm interested in any almost drop-in solutions that can do saas billing and payments, especially recurring ones. Ideally for rails. I see some a couple listed in the comments, but they seem to be more invoice oriented.

Anyone else have suggestions?

Neat! Naive question: is this just API glue for third party payment platforms (Paypal, Square, etc), or would it be theoretically possible to, say, hook up a payment system directly to my bank account (or to a corporate bank account)?

@stephane from Kill Bill.

Kill Bill can 'talk' to payment gateways but can also go straight to payment processors, providing the plugin has been written (and we are working on that).

dope, good luck guys : )

This is awesome.

This is also the kind of enterprise/b2b open source project which you can reliably* turn into a $300-500m exit in ~5y or so. Covers a clear pain point, has clear revenue model, can sell packaged version and support.

[*] Not easily. But possible.

Example would be really nice, some pictures of the product, instead of a giant download button.

There are no pictures of the product. It is essentially back-end only.

Yes, it's mostly back-end. We do provide a front-end (a mountable Rails engine), but it's mostly for administrative tasks only (for your support team to handle refunds, chargebacks, upgrades and downgrades, etc.).

Those are pretty important use-cases. If I'm evaluating this vs. Braintree at an early stage, I want to avoid writing my own dashboard software. The only dashboard functionality I care about in the immediate term is refunds, credits, cancellations, and adjustments. If you have this functionality, you should definitely be showing it off. I agree with the grandfather comment that it's unclear you have it. I looked for it and didn't see.

poor name choice given the well-known Tarantino movie. its a bit like naming your new, say, stellar formation simulation SaaS (to give a contrived example)... StarWars.

no, I like the memorable name and don't see a problem here sice it is about adressing the billing beast, killing the all the headaches

I'm glad they never made a sixth movie in that series. Although I would hope I'd get a cameo. -Bill Six

Eeek, written in Java. Bloatware alert!

I also just checked out https://github.com/hillelcoren/invoice-ninja and it also seems heavyweight @ ~300k

I think sane businesses will just move out of Europe, where they don't have to charge VAT and script invoicing themselves with something like BrainTree. https://www.braintreepayments.com/landing/international

Reply on news.ycombinator.com