Thanks for sharing this! I had done a PWA that displays some revenue forecasting[1] based on Stripe Subscriptions but I found their APIs can be slow[2]. Having that data synced up in a db sounds like a good enhancement so will definitely look into this more.
Yes, this is one of the bigger use-cases for this library. Lots of folks want custom analytics on their Stripe data and this provides a nice way to do just that.
Let me know how you find it! Happy to implement any fixes and PRs welcome!
From a marketing perspective I'd argue it's good naming, since it sells the value of the library, rather than simply its feature/s. (i.e. its feature is 'handling webhooks' but its value is in allowing (the dev) to not have to deal with webhooks.
Steve Jobs once quipped about a similar thing he observed in the dairy industry's 'Got Milk?' marketing campaign, which focused on the absence of the product https://www.youtube.com/watch?v=XzPwMguPasM
With the library you’re able to use stripe without thinking about web hooks. The library is named based on what it enables a user to do, not how it works internally.
It is indeed painful to figure out all the Stripe events one needs to handle. However, for me it’s worth it to do it once, and then be able to handle the interactions between my app and Stripe directly, instead of adding more layers.
That’s a fair point. But of course, this library also helps with other matters - wallets, credits and a code as config based system which can be quite useful too.
And also, if you record all the webhooks events (and a backfill), that basically gives you your whole Stripe data available locally - I’ve actually put it to good use in diagnosing payment failure issues before.
Great question. Basically, you would change your billing.config.ts and update the price.
Then, you run the `sync` command - it matches prices by a composite key: `productId:amount:currency:interval`. Since the amount has changed, it won't find a match for the old price. So, it will create a new price in Stripe and update the Price ID. Your new customers automatically get the new price in the Pricing Table component.
Your old subscriptions stay on the old price - which is still active in Stripe. We haven't added support for migrating these customers to the new price yet but it's in the roadmap!
I would like to add that we've tried making the porcelain / user API for the library to best fit today's commonly uses SaaS pricing models so most actions usually do what you would expect (like this price update) but, it's hard to strike a balance between customizability and the _just works_ factor.
other contributor of stripe-no-webhooks here. Yes we support Clover but should be compatible with most versions, if you have any problem open a github issue and we'll fix it ASAP
> You don't have to figure out which webhooks you need or write listeners for each one. The library handles all of that. This follows the approach of libraries like dj-stripe in the Django world (https://dj-stripe.dev/).
I don’t figure out these types of things anymore. I just make sure they work in dev, staging and production.
this doesn't work. Most of people follow the workflow you described and call it a day. The problem comes later when, for example, you realise stripe gives a grace period when payment for a subscription fails but the subscription still shows as active in your backend (by this time bad actors have been abusing your software for months).
With stripe-no-webhooks the default behaviour is that subscriptions get cancelled when payment fails and you can deal with your internal logic by putting it inside onSubscriptionCancelled hook.
There are many of small quirks that can be extremely costly (for example if you offer an AI product) and we take care of this for you
Hey, no. We are not dealing with raw card numbers. It’s just a layer on top of the existing stripe SDK that makes using stripe easier. PCI compliance does not kick in here.
Thanks for sharing this! I had done a PWA that displays some revenue forecasting[1] based on Stripe Subscriptions but I found their APIs can be slow[2]. Having that data synced up in a db sounds like a good enhancement so will definitely look into this more.
[1] https://github.com/hbcondo/revenut-app
[2] https://github.com/stripe/stripe-dotnet/issues/2284#issuecom...
Yes, this is one of the bigger use-cases for this library. Lots of folks want custom analytics on their Stripe data and this provides a nice way to do just that.
Let me know how you find it! Happy to implement any fixes and PRs welcome!
Haha "Stripe-no-webhooks library"
Library based on processing ... wait for it ... webhooks".
From a marketing perspective I'd argue it's good naming, since it sells the value of the library, rather than simply its feature/s. (i.e. its feature is 'handling webhooks' but its value is in allowing (the dev) to not have to deal with webhooks.
Steve Jobs once quipped about a similar thing he observed in the dairy industry's 'Got Milk?' marketing campaign, which focused on the absence of the product https://www.youtube.com/watch?v=XzPwMguPasM
Here a slightly longer version of that talk, that adds a lot more context. https://www.youtube.com/watch?v=doehWhv9SHU
It took a bit of hunting the internet, so I felt like sharing it.
With the library you’re able to use stripe without thinking about web hooks. The library is named based on what it enables a user to do, not how it works internally.
Like serverless
haha yes, it’s definitely a bit of a silly name. The idea is you the user does not have to deal with the webhooks!
Hi HN, library creator here.
I've linked a demo app linked in the post to try this out:
<https://snw-test.vercel.app>
It uses Clerk for auth and Clerk seems to be having problems:
<https://downdetector.com/status/clerk-inc/>
So if you're having any issues loading the app, you may have to wait a bit!
> Stripe's API has a 100 rpm rate limit
Small correction, 100 rps
source: https://docs.stripe.com/rate-limits#:~:text=the%20number%20o...
OK, so how does it differ from Supabase one? https://github.com/supabase/stripe-sync-engine
Something strange is afoot with this post -- this is the third time it's showed up in the Newest RSS feed
It is indeed painful to figure out all the Stripe events one needs to handle. However, for me it’s worth it to do it once, and then be able to handle the interactions between my app and Stripe directly, instead of adding more layers.
That’s a fair point. But of course, this library also helps with other matters - wallets, credits and a code as config based system which can be quite useful too.
And also, if you record all the webhooks events (and a backfill), that basically gives you your whole Stripe data available locally - I’ve actually put it to good use in diagnosing payment failure issues before.
This is really cool. How do you handle changes of pricing with something like this?
Great question. Basically, you would change your billing.config.ts and update the price.
Then, you run the `sync` command - it matches prices by a composite key: `productId:amount:currency:interval`. Since the amount has changed, it won't find a match for the old price. So, it will create a new price in Stripe and update the Price ID. Your new customers automatically get the new price in the Pricing Table component.
Your old subscriptions stay on the old price - which is still active in Stripe. We haven't added support for migrating these customers to the new price yet but it's in the roadmap!
I would like to add that we've tried making the porcelain / user API for the library to best fit today's commonly uses SaaS pricing models so most actions usually do what you would expect (like this price update) but, it's hard to strike a balance between customizability and the _just works_ factor.
Thank you for sharing. I've been using the Better-Auth's Stripe integration but it has some quirks.
Which Stripe version does your lib support? Clover?
Hey, I’m on mobile right now and can’t remember this off the top of my head. Will check and update in a few hours.
other contributor of stripe-no-webhooks here. Yes we support Clover but should be compatible with most versions, if you have any problem open a github issue and we'll fix it ASAP
Thank you!
A related, generalized idea: https://github.com/webhookdb/webhookdb
> You don't have to figure out which webhooks you need or write listeners for each one. The library handles all of that. This follows the approach of libraries like dj-stripe in the Django world (https://dj-stripe.dev/).
I don’t figure out these types of things anymore. I just make sure they work in dev, staging and production.
this doesn't work. Most of people follow the workflow you described and call it a day. The problem comes later when, for example, you realise stripe gives a grace period when payment for a subscription fails but the subscription still shows as active in your backend (by this time bad actors have been abusing your software for months).
With stripe-no-webhooks the default behaviour is that subscriptions get cancelled when payment fails and you can deal with your internal logic by putting it inside onSubscriptionCancelled hook.
There are many of small quirks that can be extremely costly (for example if you offer an AI product) and we take care of this for you
why call it no webhook when it's wait for it a webhook?
Well it’s a silly name, yes. _You_ don’t have to deal with webhooks - it happens in the background and is taken care of by the library!
That's not the same as no webhooks. It's totally using webhooks.
> It's totally using webhooks.
Nothing gets by you!
If used, will you now have to be PCI-compliant?
Hey, no. We are not dealing with raw card numbers. It’s just a layer on top of the existing stripe SDK that makes using stripe easier. PCI compliance does not kick in here.