Hacker News Reader

Comment by reilly3000 | Hacker News Reader

Recurring billing is hard stuff. If you haven't touched it and don't know what Dunning means, or how to handle upcoming card expirations, or proation, or mixing one-time and recurring purchases, then you probably won't appreciate what kind of value is provided by a 3rd party service. Its a wonderful thing to outsource for many SaaS companies. If you have a totally novel business model with unique billing requirements it may make sense to build, otherwise its almost universally cheaper and more maintainable to buy.

View on HN

Some of those things are pretty easy to solve.

For example checking upcoming card expirations is running a DB query on a daily background / cron job that returns cards where the expiration date <= some threshold that makes sense for your app (maybe 2 months). It's like 3 lines of code with most popular web frameworks. Typically you'd be storing a card's last4, card type, exp date and an association to a user in your system so this info is handy.

It doesn't take much more effort to send emails out as warnings for that. I've done it in a few systems before Stripe had this email feature.

The smart retries is interesting but this feels like another thing where Stripe is happy to collect our data but then re-sell it to us at a premium once they've gathered enough data. Similar to having to pay a lot more money per transaction to get fraud protection rules (Radar). Basically we pay Stripe to train their system and then they double dip and charge us extra to use these features.

>It's like 3 lines of code with most popular web frameworks

We doing DB/cron queries now with "web frameworks" ? :O

> We doing DB/cron queries now with "web frameworks" ? :O

It depends on what web framework you use, but yes.

If you had a Flask, Django, Rails, Phoenix or Laravel app it's a matter of writing a DB query in your ORM / data mapper of choice and having that execute on a scheduled job using Celery, Sidekiq or Oban (a couple of different popular job processing tools).

So yes in those cases I would treat that as something my web app handles. Going into the implementation details of ORMs and background job processing strategies didn't seem important for the sake of that post. The takeaway is it's possible to solve that problem with very little code in a typical web app.

Recurring billing is not trivial, but it's not performing open heart surgery either.

The big time waster these days, at least for those of us around Europe, is the tax and regulatory hassles. But Stripe and other payment services following similar models offer limited help with a lot of that stuff anyway.

You often expect this service to be included with a payment processor that is already charging you for transactions.

Reply on news.ycombinator.com