Top
Best
New

Posted by prasoonds 6 hours ago

Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB(github.com)
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.

35 points | 13 comments
lukaslukas 3 hours ago|
Haha "Stripe-no-webhooks library"

Library based on processing ... wait for it ... webhooks".

zffr 1 minute ago||
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.
prasoonds 2 hours ago||
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!
hbcondo714 5 hours ago||
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 4 hours ago|
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!

prasoonds 5 hours ago||
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!

whiskey-one 2 hours ago||
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 2 hours ago|
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.

xn 3 hours ago||
A related, generalized idea: https://github.com/webhookdb/webhookdb
tonyx 4 hours ago||
This is really cool. How do you handle changes of pricing with something like this?
prasoonds 4 hours ago|
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.

enigma101 3 hours ago|
why call it no webhook when it's wait for it a webhook?
prasoonds 2 hours ago|
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!