Hey guys, my company is developing a SaaS product,...
# general
a
Hey guys, my company is developing a SaaS product, and we want to have a “subscription” model… basically a way for our Customers to pay for the Software… We were looking for serverless/nodeJS out of the box solutions, but we can’t find anything yet… We also have a legacy platform built in Laravel, so we found an interesting alternative: Laravel Cashier BUT I would like to know from you guys, what you guys using for these kind of integrations.
t
I did some research on these recently. Basically a layer on top of stripe, let me try to remember what I found
Stripe honestly has a lot of the primitives you need out of the box
I can't remember the other ones I tried
a
Nice, thank you very much @thdxr, checking.
So you implemented some of these in Node?
Like doing API calls or what?
And also, what information you keep in your side?
t
I ended up going straight with stripe from typescript. Only info I kept on my side was the stripe id associated with each user (which I created on signup). Everything else can be stored with stripe
a
Interesting.
But do you also have Subscriptions Plans and such?
And also, similar to SEED, what happens if you add a new user to the plan?
t
Yeah stripe lets you model subscriptions + all their details in their dashboard
a
Interesting, might need to try it from scratch then.
c
@Adrián Mouly if you haven’t already bumped into this, one way to get started is to leverage Stripe’s Customer Portal to handle the functionality and UI for account and billing management. Your work then becomes just integrating the handoff for a known/authenticated user over to Stripe’s portal. This may not be the final, fully integrated UX/UI solution you arrive at, but a good place to start that can be used in production and easily built upon, presuming you’ll be using Stripe – https://stripe.com/docs/billing/subscriptions/customer-portal
a
I’m also using stripe along with a couple of other payment processors. I’m using stripe primarily for international payments and it works like a charm. I got a better deal to deal with local payments than stripe and hence the fragmentation. My implementation is a combination of Plans, Orders, Payments, and Coupons. Based on the user’s country code I show them different plans and use different payment processors to fulfil them. For the status tracking I’ve some webhook endpoints that just validate the signatures and add them to sqs for processing. Works fine for my use case, currently have around 45k users with an annual subscription. I want to improve this further by auto-refunds via Webhooks, and use EventBus for processing the webhook requests from sqs rather than lambda.
o
I’m looking at this problem now too. I looked at Stripe Billing, Chargebee, Chargify, Paddle and Recurly. My requirements are a bit different in that I wanted to run the payments and accounting through my own product (Fragment), but wanted something to handle the subscription logic. None of those fitted the bill for various reasons but the biggest one being they are all very card-focused and I wanted to use ACH because of the much lower fees (we do a few big transactions vs lots of small ones). We use Octane for usage-based billing, which has some subscription management built-in so my current plan is to have Octane generate invoices each month and build a little retool app that takes those invoices, updates a customer-specific Notion page with it, and calls the Fragment API to bill the customer over ACH. The missing piece in all this is tax (calculation, tracking, payment, filing), which is solved by various combinations of Stripe Tax, Tax Jar, Paddle et al. Octane are working on adding some simple tax calc functionality at my request, but I’ll need to figure out the tax rate per customer and track how much we’ve tax we’ve collected per US state (probably using TaxJar)