pamonrails

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!

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)

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).

No fake marketing :-)

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).

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).

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 :-)

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.

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)

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/

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

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.

[1] https://killbill.io/

@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.

@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).

Here is the 2016 version: http://killbill.io/blog/having-fun-with-docker-stripe-and-ki... ;-)

I'll echo what others said: run your own.

Using a SaaS-based recurring billing solution has its drawbacks:

* You are limited by the features offered by the provider for your pricing schemes (for example, most only offer basic forms of usage-based billing)

* You don't have direct access to your data (analysis are limited by the types of reports the provider offers)

* Vendor lock-in: it's extremely difficult to move to a different provider (for example, you need to cancel subscriptions in provider A and re-start them at the right date in provider B to avoid double billing)

That being said, don't write your own! It's not as easy as it seems when you need to deal with multi-currency support, pro-rations calculations, timezones, etc.

5 years ago, we built Kill Bill (http://killbill.io/), the open-source subscription billing and payments platform:

* The platform offers a lot of billing schemes out of the box, but you can extend the logic (via plugins)

* Because you run the software, data belongs to you

* Payments are still delegated to a third-party gateway (Stripe, Braintree, etc.) which can take care of the PCI complexity

* For taxes specifically, you can either calculate them yourself or integrate with a third-party solution (e.g. AvaTax)

We do a lot of migrations from custom systems or SaaS integrations to Kill Bill (open-source subscription billing and payments platform) [0] and we've summarized our strategy and usual pain points in our migration guide [1]. You might find it useful.

Happy to chat offline too if you want to go into specifics.

[0] http://killbill.io/ [1] http://docs.killbill.io/0.16/migration_guide.html

Have you considered managing the subscriptions yourself? With Kill Bill[0], you can own the subscription piece while still delegating payments to PayPal and/or Stripe.

[0] http://killbill.io/ - Open-Source Subscription Billing & Payment Platform.

Removing support for credit cards in Kill Bill: http://killbill.io/blog/deprecating-support-debit-credit-car...

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.

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.).

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).

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

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

@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...