Interesting! Is there an escape hatch to drop down to raw Stripe primitives if someone needs a feature you haven’t modeled yet?
This feels like something many teams eventually build internally — curious how you’re thinking about long-term API surface + compatibility with new Stripe features.
yes, the library is ~mostly a wrapper around Stripe with a convenience layer of a simple API that works on the your local DB. So, you will always be able to call Stripe as per usual.
The idea here was to fill the gaps left by the official Stripe implementation:
- direct access to your Stripe data in your own DB - this lets you get around Stripe API rate limits and do custom aggregations (user dashboards? I love what Cursor has done on their usage dashboard for eg)
- easy support for multiple credit types, topups and auto-topups
- usage billing that's much simpler to use (meters, usage products and prices are not exposed to the users)
Other than these basic primitives, everything else is just Stripe under the hood. You can and SHOULD use Stripe SDK for any write operations, for eg.
> This feels like something many teams eventually build internally ...
Exactly right - we've talked to so many teams who has mostly vibe-coded something fragile that mostly works for them and the pattern is common enough that we thought this separate library would be widely useful.
Speaking of holes in the stripe API there’s an annoying one where you can’t easily directly look up what user redeemed a specific promo code
Interesting! Is there an escape hatch to drop down to raw Stripe primitives if someone needs a feature you haven’t modeled yet?
This feels like something many teams eventually build internally — curious how you’re thinking about long-term API surface + compatibility with new Stripe features.
Hey Tony,
yes, the library is ~mostly a wrapper around Stripe with a convenience layer of a simple API that works on the your local DB. So, you will always be able to call Stripe as per usual.
The idea here was to fill the gaps left by the official Stripe implementation:
- direct access to your Stripe data in your own DB - this lets you get around Stripe API rate limits and do custom aggregations (user dashboards? I love what Cursor has done on their usage dashboard for eg)
- easy support for multiple credit types, topups and auto-topups
- usage billing that's much simpler to use (meters, usage products and prices are not exposed to the users)
Other than these basic primitives, everything else is just Stripe under the hood. You can and SHOULD use Stripe SDK for any write operations, for eg.
> This feels like something many teams eventually build internally ...
Exactly right - we've talked to so many teams who has mostly vibe-coded something fragile that mostly works for them and the pattern is common enough that we thought this separate library would be widely useful.
Looks really interesting. Can you do custom plans for some users?
Hey Felix, yes you can.
This library is simply a wrapper around Stripe with easier implementation and some additional primitives (credits / wallets / real-time usage).
So, just as in Stripe, where you would make a new custom plan for, say, an enterprise use, simiarly here, you'd do the same.
Though, I will admit your `billing.config.ts` file will get pretty crowded...
I will think on it and try to come up with a more user-friendly UX for this use case.
Hey this is cool!