Ask HN: Are Yearly Subscriptions Hard? | Hacker News Reader

Ask HN: Are Yearly Subscriptions Hard?

10 pointsgregsadetsky7 comments

I'm currently working with a large SaaS that wants to implement yearly subscriptions well. We have overages (think: you have N users as part of your subscription, but if you go over, we bill them at $X/user).

Monthly plans are "easy" as they map to Stripe's model. Stripe has "usage records". Plan changes are all handled with prorations, etc. It's great.

Yearly seems a lot more complicated. There doesn't seem to be a Stripe-native way to have invoices for overages being sent at the month end. We have to do a ton of billing date/math, keep track of the overages, of when we billed for them, and create invoices manually. It's a mess. We're trying to write valid, tested, solid code for this... but it feels like we're slowly rebuilding parts of Stripe :-)

Has anyone else gone through this? What's stopping Stripe from handling yearly subscriptions with monthly overage invoices? Are we an edge case [0]? Cheers

[0] I'm being facetious - there are clearly many companies whose business model includes yearly plans + overages-billed monthly. Slack, Zapier, etc.

Could you have a separate monthly subscription on the customer that handles overages? For example, all yearly customers would have 2 subscriptions: the base yearly subscription for up to N users, but also a monthly subscription for overages > N (so an invoice will only be sent if overages > 0).

Doing it this way, Stripe should handle the bulk of the logic; yearly and monthly subscriptions would be more or less the same from your end.

For sure, we were considering that. One drawback is that you can’t present the Stripe portal / Checkout UI to users

We’d want users to be able to use the UI that Stripe provides so that users can upgrade and downgrade by themselves. With 2 subscriptions, that stops being possible.

Are you charging yearly in advance or charging monthly but on a yearly contract?

To answer your question, yes they are hard, but they make sense from a retention and overall revenue perspective.

Charging yearly in advance.

What we want is monthly invoices that are sent out only if there were overages in that month.

If it did fit Stripe's model, we would just report usage over the year to them through the API, and they would send overage invoices during the year. But they don't do that.

I do a yearly subscription. An issue to watch out for asides billing is monitoring that your customers aren't leaving you, but you don't know about it.

First thing that popped up on my mind: do NOT think in terms of what a payment processor can do.

It should be irrelevant what Stripe can do as long as they can process payments for you.

Whether you want to offer yearly subscription should only be a matter of your commercial strategy, ie. does it make sense to offer it for your business?

Good point. In this case, it makes sense - customers want it, we're happy to give them a rebate for trusting us with their business for a year, etc.

Reply on news.ycombinator.com