Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: We built an open source, zero webhooks payment processor

github.com

Post reply on HN
Print view View original

161–170 of 230 posts

Re: Show HN: We built an open source, zero webhooks payment processor

#161

Post by agreeahmed »

jedberg wrote: post #92

I am not a smart person. How are you avoiding using webhooks but giving the same functionality? I read the materials but still don't understand.

We eat all the webhook pain so you don’t have to. Much of our code is dealing with complex state transitions triggered webhooks. We just avail you the end result.

Instead of having to implement all that yourself, you just read the latest billing and entitlement state for each of your customers from Flowglad:

const billing = flowglad(user.id).getBilling()

const hasFastGen = billing.checkFeatureAccess(‘fast_generations’)

Re: Show HN: We built an open source, zero webhooks payment processor

#162

Post by owenwil »

agreeahmed wrote: post #98
clintonb wrote: post #2

> Not to mention choreographing the lifecycle of our business domain with the Stripe checkout flow and webhook event types, of which there are 250+ You don’t need to listen for all event types if you aren’t using _every_ Stripe feature.

But you do have to figure out which ones are salient to you and how they map to your specific app's lifecycle. As a very small example: would you need to handle `charge.succeeded` and `payment_intent.succeeded`? How would you dedupe processing these events vs `customer.subscription.created`? Today, there's a lot of incidental knowledge about your payment processor's specific approach to webhook events that you need t…

Yeah, this isn’t great today. We have been exploring Webhook bundles/groups for common integration shapes that make a bit easier to make the right choices based on what you’re doing and hope to have something out here to help soon.

Re: Show HN: We built an open source, zero webhooks payment processor

#163

Post by globalise83 »

agreeahmed wrote: post #109
codegeek wrote: post #96

Earlier quoted context omitted.

The landing also doesn't clearly answer if they use their own stripe or we need to connect our own stripe account.

That feedback is very well received, thank you. Currently you set up a new Stripe Connect account to get started. We tried the "connect existing account" flow and discovered that, maybe due to regulations or Stripe policies, we weren't able to debit the existing accounts. Our Stripe flow is different from the run of the mill billing SaaS because we're involved in the movement of money (rather than simply using your S…

I believe that means you are more or less setting yourself up as a payment facilitator, meaning you and your other merchants will be kicked off Stripe at any time if too many of your merchants misbehave. Is your compliance team ready for that?

Re: Show HN: We built an open source, zero webhooks payment processor

#164

Post by vivzkestrel »

agreeahmed wrote: post #103
game_the0ry wrote: post #61

I have an idea. Would be happy to get feedback + criticism. What if there was some standard API interface for payment processors? Basically AWS S3 API, but for payment processors. The idea being that migration between payment providers should be low friction and standardized. If you're in Stripe jail or banned, start using paypal (or something else) just by changing endpoints + credentials. Since Stripe is the gold s…

This would be awesome, it's just really hard to manifest because every payment processor is different, has different life cycle events, etc. They also have different risk and antifraud functions, which you have to consider because they shape how their checkout components behave. And then they also all have slightly different payment methods that they support, each of which behave slightly differently. You can kind of…

or maybe you dont abstract it away, let each payment api behave the way their service supports, add some common functions on top that users can use and for specific functions they always look for specific classes. Ex class Gateway { abstract function send(), abtstract function receive() } class Visa extends Gateway { send()...receive()..., otherVisaSupportedFunctions() } class MasterCard extends Gateway { ....}

Re: Show HN: We built an open source, zero webhooks payment processor

#165

Post by whiskey-one »

owenwil wrote: post #162
agreeahmed wrote: post #98

Earlier quoted context omitted.

But you do have to figure out which ones are salient to you and how they map to your specific app's lifecycle. As a very small example: would you need to handle `charge.succeeded` and `payment_intent.succeeded`? How would you dedupe processing these events vs `customer.subscription.created`? Today, there's a lot of incidental knowledge about your payment processor's specific approach to webhook events that you need t…

Yeah, this isn’t great today. We have been exploring Webhook bundles/groups for common integration shapes that make a bit easier to make the right choices based on what you’re doing and hope to have something out here to help soon.

Having to figure out which of the 100s of Stripe event types we need to handle and which ones overlap was the most stressful part of adopting their system. Simplification here is welcomed.

Re: Show HN: We built an open source, zero webhooks payment processor

#166

Post by duckerduck »

Congrats on getting to beta!

I very much relate to the problems you're trying to solve, so much so that I have created a Stripe integration library [0] that has very similar DX to flowgrad! (not nearly as feature rich however). I've also written a blog post as to why I built it[1].

Key difference is where the final billing information is stored, our library also ships db schemas and the webhook handlers write to that local db.

You should also check out our (open source, MIT) library[1] this is built on, it could be useful for you guys!

[0]: https://fragno.dev/docs/stripe/quickstart

[1]: https://fragno.dev/blog/split-brain-stripe

[2]: https://fragno.dev/docs/fragno

Re: Show HN: We built an open source, zero webhooks payment processor

#167

Post by jedberg »

agreeahmed wrote: post #161
jedberg wrote: post #92

I am not a smart person. How are you avoiding using webhooks but giving the same functionality? I read the materials but still don't understand.

We eat all the webhook pain so you don’t have to. Much of our code is dealing with complex state transitions triggered webhooks. We just avail you the end result. Instead of having to implement all that yourself, you just read the latest billing and entitlement state for each of your customers from Flowglad: const billing = flowglad(user.id).getBilling() const hasFastGen = billing.checkFeatureAccess(‘fast_generations…

Oh I see, you're still running a server, the open source bit is just your SDK. I thought your entire system was open source and didn't understand how you could trigger workflows without webhooks. Makes more sense now, thanks!

What are you using to manage your workflows on your backend?

Re: Show HN: We built an open source, zero webhooks payment processor

#168

Post by mrweasel »

mattfrommars wrote: post #123

But who actually processes payment? Is it stipe, bolt or some other payment processor? How can any of this work without dealing with credit card payment processors

Calling it a payment processor is a bit of an issue. The term "payment processor" has a very specific meaning in the world of online payments, and this isn't it.

This is a frontend for Stripe, so it's even a bit of a stretch to call it a Payment Service Provider. Payment gateway maybe, but really it's a Stripe frontend.

Re: Show HN: We built an open source, zero webhooks payment processor

#169

Post by mrweasel »

swedishuser wrote: post #11

> 2.9% + 30¢ Very expensive!

When Stripe entered, people stopped caring about the cost of payment processing. I don't work in the industry anymore, but Stripe became rather popular at the time where I worked on online payments. We looked at it, because the Stripe API and services are really nice, but the cost is just insane.

We where never even close to 2.9% on credit cards, and we'd certainly never consider paying 30¢. Part of that is working out of the EU, that caps your credit card fee, so around 1% and 0.10EUR per transaction is closer to the standard. Then you can start negotiating lower raters from there, depending on the number of transaction you make.

Re: Show HN: We built an open source, zero webhooks payment processor

#170

Post by skrebbel »

agreeahmed wrote: post #142
CuriousRose wrote: post #141

Congratulations on the beta launch, an impressive product we will consider integrating. As a relatively new developer, I'm curious why the dependancy on React? Was there no way to get the UI you wanted without implementing a framework like React? We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.

That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.

May I suggest web components? For all their warts, they are perfect for a use case like this. Even React, the IE of frameworks, supports them properly in v19.
Post reply on HN