hckrnws
Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB
by prasoonds
Hey HN, stripe-no-webhooks is an open-source library that syncs your Stripe payments data to your own Postgres database: https://github.com/pretzelai/stripe-no-webhooks.
Here's a demo video: https://youtu.be/cyEgW7wElcs
Why is this useful? (1) 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/). (2) Stripe's API has a 100 rpm rate limit. If you're checking subscription status frequently or building internal tools, you'll hit it. Querying your own Postgres doesn't have this problem. (3) You can give an AI agent read access to the stripe.* schema to debug payment issues—failed charges, refunds, whatever—without handing over Stripe dashboard access. (4) You can join Stripe data with your own tables for custom analytics, LTV calculations, etc.
It creates a webhook endpoint in your Stripe account to forward webhooks to your backend where a webhook listener stores all the data into a new stripe.* schema. You define your plans in TypeScript, run a sync command, and the library takes care of creating Stripe products and prices, handling webhooks, and keeping your database in sync. We also let you backfill your Stripe data for existing accounts.
It supports pre-paid usage credits, account wallets and usage-based billing. It also lets you generate a pricing table component that you can customize. You can access the user information using the simple API the library provides:
billing.subscriptions.get({ userId });
billing.credits.consume({ userId, key: "api_calls", amount: 1 });
billing.usage.record({ userId, key: "ai_model_tokens_input", amount: 4726 });
Let's see how it works with a quick example. Say you have a billing plan like Cursor (the IDE) used to have: $20/mo, you get 500 API completions + 2000 tab completions, you can buy additional API credits, and any additional usage is billed as overage.
You define your plan in TypeScript:
{
name: "Pro",
description: "Cursor Pro plan",
price: [{ amount: 2000, currency: "usd", interval: "month" }],
features: {
api_completion: {
pricePerCredit: 1, // 1 cent per unit
trackUsage: true, // Enable usage billing
credits: { allocation: 500 },
displayName: "API Completions",
},
tab_completion: {
credits: { allocation: 2000 },
displayName: "Tab Completions",
},
},
}
Consume code would look like this:
await billing.credits.consume({
userId: user.id,
key: "api_completion",
amount: 1,
});
await billing.credits.topUp({
userId: user.id,
key: "api_completion",
amount: 500, // buy 500 credits, charges $5.00
});
This would be a lot of work to implement by yourself on top of Stripe. You need to keep track of all of these entitlements in your own DB and deal with renewals, expiry, ad-hoc grants, etc. It's definitely doable, especially with AI coding, but you'll probably end up building something fragile and hard to maintain.
This is just a high-level overview of what the library is capable of. It also supports seat-level credits, monetary wallets (with micro-cent precision), auto top-ups, robust failure recovery, tax collection, invoices, and an out-of-the-box pricing table.
I vibe-coded a little toy app for testing: https://snw-test.vercel.app. There's no validation so feel free to sign up with a dummy email, then subscribe to a plan with a test card: 4242 4242 4242 4242, any future expiry, any 3-digit CVV.
Screenshot: https://imgur.com/a/demo-screenshot-Rh6Ucqx
Feel free to try it out! If you end up using this library, please report any bugs on the repo. If you're having trouble / want to chat, I'm happy to help - my contact is in my HN profile.
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
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!
Something strange is afoot with this post -- this is the third time it's showed up in the Newest RSS feed
OK, so how does it differ from Supabase one? https://github.com/supabase/stripe-sync-engine
Hi HN, library creator here.
I've linked a demo app linked in the post to try this out:
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...
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?
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!
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.
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.
Crafted by Rajat
Source Code