pamonrails
Joined 13 years ago
Karma
41
Submissions
32
Member since
Dec 31
Co-founder of Kill Bill, the open-source subscription billing and payments platform (https://killbill.io/)
View on Hacker NewsRecent submissions
Comment · 2 years ago
Pierre from Kill Bill here. This sounds like something that is be supported out of the box. I'm not sure I understand why the Stripe plugin needs to be rewritten, but feel free to reach out to our Google groups if we can help!
Comment · 4 years ago
It really depends on your usecase, but some benefits:
* Lower cost (just pay for payment processing, not the subscription features) * Ability to integrate with multiple gateways (to lower cost, support more payment instruments, higher resiliency, etc.) * More advanced subscription features * Ability to customize the system through custom code (plugins) * Data ownership (easier to run analytics reports, since you own the subscription data)
Comment · 4 years ago
FYI this is just a managed sandbox, to test things out. We don't offer Kill Bill aaS, as it goes against our value proposition (Kill Bill is a framework to build your own internal subscription billing and payments platform).
Comment · 4 years ago
No fake marketing :-)
Comment · 4 years ago
FWIW the very vast majority of our users are integrated with either Adyen, Braintree, or Stripe (all open-source plugins).
I know of ~20 integrations with more advanced gateways/processors: these are closed-source plugins, but the overall community wouldn't benefit much from accessing them (e.g. it doesn't make sense for many companies to directly integrate with mastercard APIs).
Comment · 4 years ago
Fair. That being said, we've come a long way by now. Lots of our users deploy Kill Bill in "cloud-native" environments these days (e.g. k8s).
Also, we've deprecated JRuby support. Plugins are either written in Java or in other languages through grpc shims (e.g. Go).
Comment · 4 years ago
We don't follow SemVer (yet?).
We use even minor versions for LTS releases (e.g. 0.22.x) and odd versions for dev releases (e.g. 0.23.x). Kill Bill is very much stable now :-)
Comment · 4 years ago
Kill Bill (note: I'm a co-founder) provides payment routing capabilities, so you can integrate with multiple providers (e.g. Stripe + Adyen) and shift payment traffic to go through one or the other dynamically. This is very common in large b2c companies.
That being said, to your point, this still requires either a vendor neutral vault for the cards or to tokenize them in all of the vendors. Possible, but still hard to do in practice.
Comment · 6 years ago
If you are looking to manage subscriptions outside of Stripe, but keep using Stripe for payment processing, take a look at Kill Bill, the open-source subscription billing & payments platform: https://killbill.io/
- Stripe tutorial: https://docs.killbill.io/latest/stripe_plugin.html
(I'm a Kill Bill cofounder)
Comment · 6 years ago
It sounds like you are looking for an entitlement system[1]?
In my experience, none of the SaaS providers mentioned help you with this, probably because it's very dependent on your product and business logic. Even with Kill Bill, which has an entitlement system[2], some amount of coding would be required to manage and enforce states like "max amount of users reached for that plan" (the logic would be abstracted from the billing though).
- [1] http://killbill.io/blog/subscriptions-entitlement-billing-an... - [2] http://killbill.io/blog/blockingstate-abstractions/
Comment · 6 years ago
This is a bit of shameless plug, but if you are looking to manage subscriptions outside of Stripe, and simply use Stripe for payment processing, take a look at Kill Bill, the open-source subscription billing & payments platform: https://killbill.io/
- Stripe tutorial: https://docs.killbill.io/latest/stripe_plugin.html
Comment · 6 years ago
Take a look at open-source solutions, specifically Kill Bill [1] (disclaimer, I'm a core contributor)
It provides a subscription management platform with all the features you would expect out of the box (recurring billing, plans management, dunning, notifications, etc.), but with also a plugin framework where you can implement your own billing logic.
You can continue to use processors like Stripe to handle the recurring charges (and compliance associated with storing cards), but they are only used to charge the payment methods. The mess that OP mentions stays in-house, where you have tighter control over it.
Comment · 8 years ago
@pierre from Kill Bill here.
Back in the days, we tried very hard to have a good native integration with the blockchain for recurring payments (see the "Extension for BIP-0070 to support recurring payments" thread on the bitcoin-dev list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014...). It didn't go anywhere unfortunately, so we added support for the major providers at the time (Bitpay, Coinbase, ... see http://killbill.io/blog/coinbase-integration-experiment/).
In the end though, as the interest for Bitcoin as a currency decreased, none of our users were interested to offer Bitcoin as a payment mechanism anymore. We've since put this experiment on the backburner. Happy to revisit whenever there is demand for it.
Regarding other non traditional payments methods (wire transfers, Boleto, etc.), this is absolutely supported and heavily used outside of NA.
Comment · 8 years ago
@pierre from Kill Bill here.
First, regarding maintaining plugins in general, the project is over 7 years old now. We have everything from very small to very big companies using us (some of them have their logo displayed at http://killbill.io/), each with their own requirements. Over the years, we have created about 60 plugins to fulfill these, and the matrix to maintain has become huge (company X is using feature F of vendor/plugin Y with Kill Bill version Z).
It's getting impossible for us (core developers) to maintain all of these for each combination of {F,Y,Z}, while also continuing to maintain and improve the core codebase. This is why we are asking more and more for the community to help us (read: submit PR) and we are more than willing to provide support and guidance (if you want to fix something specific, feel free to reach out on the mailing-list).
I also agree that Kill Bill can be difficult to grasp initially. We've been working hard over the past year to improve our manuals (http://docs.killbill.io/) and API docs (https://killbill.github.io/slate/). There is always more we could do, so happy to iterate if you have specific feedback. That being said, subscription billing and payment is really hard, and after reviewing requirements for dozens of companies over the years, none are alike, hence the complexity of Kill Bill (it's a generic system with lots of knobs to tweak to fulfill most requirements).