[HN Gopher] Show HN: Stripe-no-webhooks - Sync your Stripe data ...
___________________________________________________________________
Show HN: Stripe-no-webhooks - Sync your Stripe data to your
Postgres DB
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 }); Effectively,
you don't have to deal with either the Stripe dashboard or the
Stripe API/SDK any more if you don't want to. The library gives you
a nice abstraction on top of Stripe that should cover ~most
subscription payment use-cases. 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", }, }, }
Then on the CLI, you run the `init` command which creates the DB
tables + some API handlers. Run `sync` to sync the plans to your
Stripe account and create a webhook endpoint. When a subscription
is created, the library automatically grants the 500 API completion
credits and 2000 tab completion credits to the user. Renewals and
up/downgrades are handled sanely. Consume code would look like
this: await billing.credits.consume({
userId: user.id, key: "api_completion", amount: 1,
}); And if they want to allow manual top-ups by the user:
await billing.credits.topUp({ userId: user.id, key:
"api_completion", amount: 500, // buy 500 credits,
charges $5.00 }); Similarly, we have APIs for wallets
and usage. 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.
Author : prasoonds
Score : 33 points
Date : 2026-02-10 17:14 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| prasoonds wrote:
| 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!
| hbcondo714 wrote:
| 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...
| prasoonds wrote:
| 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!
| tonyx wrote:
| This is really cool. How do you handle changes of pricing with
| something like this?
| prasoonds wrote:
| 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.
| xn wrote:
| A related, generalized idea:
| https://github.com/webhookdb/webhookdb
| lukaslukas wrote:
| Haha "Stripe-no-webhooks library"
|
| Library based on processing ... wait for it ... webhooks".
| prasoonds wrote:
| 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!
| enigma101 wrote:
| why call it no webhook when it's wait for it a webhook?
| prasoonds wrote:
| 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!
| whiskey-one wrote:
| 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.
| prasoonds wrote:
| 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.
___________________________________________________________________
(page generated 2026-02-10 23:00 UTC)