Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How do I integrate subscription billing to my SaaS

news.ycombinator.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Ask HN: How do I integrate subscription billing to my SaaS

#11

Post by davismwfl »

user3487 wrote: post #9
davismwfl wrote: post #8

Earlier quoted context omitted.

So if your plans vary based on usage patterns and that carries additional charges, then yes, you'll have to run some sort of scheduled job to check for users getting close to plan thresholds. IMO you don't want to auto upgrade people, but rather warn them at say 80%, then 90% and give them the option to upgrade or be frozen at their current use level. This prevents chargebacks and complaints for auto upgrades they di…

This is amazing, thank you again! It seems that the way you have decided to solve this is both scalable and modular, so it's very likely that I will adopt it. I will talk with my business people about the best solution for us on handling tier upgrades, notification etc. Right now you have assured me I can let the subscription integration wait, so I'll continue focusing on the actual product and implement the subscrip…

Awesome, glad I could help some, good luck!

Re: Ask HN: How do I integrate subscription billing to my SaaS

#12

Post by user3487 »

codegeek wrote: post #10

Even though you should use stripe (we all love it), you should not directly code for stripe only. Here is how: - Create an abstract "Ecommerce" module in your app and let it configure different payment gateways. In your case, start with stripe as the only payment gate way to choose from. But doing it this way now lets your app easily plug into other payment APIs in future as needed. - For the user model, instead of h…

Thank you for the answer!

Mr. @davismwfl gave me some really good directions on my problem in his answers, do you agree on that way? Is there a reason you suggest managing the subscriptions directly in the app instead of in Stripe? And does it count as "my app" if I manage it in a separate service, as @davismwfl solution?

Re: Ask HN: How do I integrate subscription billing to my SaaS

#14

Post by davismwfl »

user3487 wrote: post #12
codegeek wrote: post #10

Even though you should use stripe (we all love it), you should not directly code for stripe only. Here is how: - Create an abstract "Ecommerce" module in your app and let it configure different payment gateways. In your case, start with stripe as the only payment gate way to choose from. But doing it this way now lets your app easily plug into other payment APIs in future as needed. - For the user model, instead of h…

Thank you for the answer! Mr. @davismwfl gave me some really good directions on my problem in his answers, do you agree on that way? Is there a reason you suggest managing the subscriptions directly in the app instead of in Stripe? And does it count as "my app" if I manage it in a separate service, as @davismwfl solution?

Codegeek is right on with this, the description I gave is in line with the same thing he is stating. Our data store is mongo so we use documents for the subscription details but if I was in an rdbms it would likely be a key/value pair as described.

The detail about storing all your subscription details locally is valid. We do it but also put the details in Stripe as that is what enables the recurring billing. That is also what I was pointing out in the web hooks as we store all the Stripe history from the web hooks. Works great.

Re: Ask HN: How do I integrate subscription billing to my SaaS

#15

Post by jasonkester »

Stripe. Just how you think you'd do it, with a CustomerID field in the user (or company) table.

Don't sweat the possibility that you'll have to change payment providers one day. You probably will, and it won't be anywhere near as much effort as you think.

I once switched a couple of my services from Amazon Payments over to Stripe in the course of an afternoon, fixing up the fields, adding a PaymentProviderID column to the table, and rewiring the backend. It was in no way painful. Certainly less effort than it would have been to build in an abstraction layer ahead of time that would have been any help at all during the conversion process.

This is a great example of "you aren't going to need it" combined with "you're just going to build the wrong thing" combined with "quit fannying about building crap you don't need and actually ship your product". To pull off the perfect abstraction layer, you'd need to know not only the system you were integrating, but also enough about the next system that you wouldn't have to do all those things I describe above anyway. It'll take you just as much time to do the work up front as it would to do it when you actually need it, but in the meantime you won't have a shipped product.

In short, don't sweat it.

Post reply on HN