Ask HN: How do you deal with recurring payments?

Stripe is very simple and has a very high quality API. They recently made some improvements to their dashboard for subscription management.

I've never used a service on top of Stripe for handling payments but I'd love to hear what others use.

* An accounts table with a paid_through column to identify when each person should next be billed

* A payments table into which you insert one row per payment for accounting/metrics

* A website form that submits to https://spreedly.com/ to tokenize payment information; the token is all you store

* A 100-line cron job that selects all the accounts whose paid_through date is in the past, then charges their subscription against their payment token, sends receipts or dunning mails depending on whether the charge went through, and updates the paid_through dates

Coupons, discounts, etc can be accommodated just by adding some columns and tweaking the billing script's SQL query. The payments table is sufficient information to calculate all the valuable SaaS metrics from your database as well -- CLTV, MRR/ARR, churn rate, etc.

Integrating with Spreedly instead of directly with a payment provider means you can change processors without changing any code -- your choice of payment processor becomes just another token.

@dangrossman mentioned storing cards in spreedly. I'm pretty sure chargebee does that already on the backend.

I built Quaderno two years ago because I was tired to deal with payments, invoicing, accounting, and tax rules (specially now when there are more and more digital taxes worldwide) in my past projects. My goal was to automate the whole accounting process for any SaaS.

Of course you can use your own billing system, but as Josh from Baremetrics say, "the danger in building internal tools is not that it saves an insignificant amount of cash, but that if stifles future cash" (Full article: https://baremetrics.com/blog/build-it-buy-it).

If you have any questions about Quaderno or how to manage payments for SaaS, please let me know. Happy to help.

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 support card data portability (we also use Spreedly to vault card as a service but we pay for it as an infrastructure) and in the case of Stripe we directly vault it in Stripe, as they do a great job of being friendly with customers and supports portability as well.

Apart from very detailed subscription management use cases, we enable hundreds of small things that come up as you grow beyond the first 50 customers - invoice based payments, coupon promotions for sales, credits (cash vs. promotion credit vs. proration credit) that finance cares about, detailed invoicing, accounting integration flow, taxes etc., while enabling pretty much everything with API as well.

Most of our customers find our product most useful once you grow beyond the 2 member founding team as the needs grow but you don't want to build spend your time building internal systems.

We share a lot of customers with Stripe / Braintree - Freshdesk, Study.com, Soylent etc.,

We also put a lot of focus on our customer support to respond within an hour for most queries and we generally deal with detailed use cases from non-technical members of team and we assist them.

This is a key area of focus for us, as that frees up a lot of developer distraction to address queries, as and when the cases arises. For an essential service like billing I believe it adds a lot of value, so we have built everything around having a very good customer support.

Happy to answer any questions.

We see this question asked a lot it really boils down to resources and what you want to spend your time on. Yes, it is pretty easy to build a basic system with a gateway such as Stripe or Braintree but there are two main problems: 1. It does not scale well (your needs will likely increase) 2. Building and maintaining your own system takes away from focusing on your product (and it is not a core competency)...

As Krush said, there are "hundreds of small things that come up as you grow." By using a best of breed tool, most of these things are available out of the box with little to no dev work needed such as testing plans, coupons/promo codes, taxes, reporting/analytics, billing portal for customer account management, a portal for your support team to see/edit account history/info, system emails, dunning management, and so much more.

The price for billing software like Chargify is minimal compared to the time saved building and maintaining your own system. In fact, the money saved by leveraging our dunning features alone have proven to provide a 4x return based on the monthly cost of Chargify's software. So not only does it save a lot of resources, it provides an ROI.

We have a ton of people that come to us after building their own system, and wished they implement Chargify in the beginning. But it is never too late!

Happy to answer any specific questions.