Live data from Hacker News

Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

github.com

11–20 of 31 posts

Re: Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

#12

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.

Re: Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

#14

Haha "Stripe-no-webhooks library" Library based on processing ... wait for it ... webhooks".

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.

Re: Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

#16
> 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.

Re: Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

#18

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.

Re: Show HN: Stripe-no-webhooks – Sync your Stripe data to your Postgres DB

#20

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

Post reply on HN