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

121–130 of 230 posts

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

#121

Post by agreeahmed »

ripped_britches wrote: post #104

How does this work in terms of having a merchant bank? Surely you need something else besides this repo right?

Yes, while this is OSS, we haven't yet figured out how to self host an acquiring bank partnership... For now we're using Stripe Connect to set up a merchant account through our Stripe Connect platform. So as long as you are a legal entity (individual or business) in the countries that Stripe does merchant acquiring you should be good to go with us.

Eventually we want to get to a place where we are embedded deeper on the payments side. But for now that's the flow.

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

#122

Post by agreeahmed »

eli_yumnik wrote: post #114

This looks like a REALLY cool tool for tech-focused startups. I like that its not just resolving the stripe bloat but also the code. You can setup a full production-ready payments processor without worrying about the code. I'm wondering - is there some overhead required to keep operations up? Or Flowglad takes care of everything between code and compliance Also, sick sweater I have the same one XD

This isn't quite a boilerplate to start your own payment processor - but an open source payments provider which you does the entire job to be done: handling the flow of both money and value inside your app. And yes, for now your coding agent + our MCP and SDKs handle the code. Our API handles the state management of entitlements usage credits etc. This is the really messy part that hasn't been well addressed yet by incumbents.

And then we, alongside the processing partners we use on the backend (currently Stripe, soon hopefully beyond) handle the rest.

Re the sweater: great minds ;)

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

#127

Post by handfuloflight »

agreeahmed wrote: post #126
handfuloflight wrote: post #124

Is your pricing ON TOP of what Stripe charges? Are we bringing our Stripe API Key to this?

No that’s the total cost to you. This isn’t a BYOK setup, you create a Stripe account through us using Stripe Connect

This is great! Where does the Stripe Connect process happen, I'm not seeing it in the dashboard?

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

#128

Post by agreeahmed »

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

Under the hood we are using Stripe to process the payments, but you set up a Stripe sub account through our platform using Stripe Connect

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

#130

Post by agreeahmed »

johnxie wrote: post #120

Feels like pricing is becoming a moving target again. Cursor’s experiments showed how fast teams will change plans the moment usage patterns shift, and LLM speed only accelerates that loop. Every new model drop forces you to rethink what’s “metered,” what’s “included,” and what users actually feel in the product. The part that buckles first is always the billing logic. Not the API calls, but the lifecycle math behind…

Thank you! That’s exactly what we saw after speaking with a bunch of devs. They wanted to iterate on pricing as they all figure out how to price their AI products.

It turns out that the architectural changes that make that easier also make the tool generally easier to use for a bunch of different use cases.

In urban planning they have a name for this: the “curb cut effect”, whereby urban planners found that curb cuts, that had been made for a specific accessibility need such as people in wheelchairs, ended up being useful to all kinds of people: cyclists, people walking at night, pedestrians with weaker joints.

Devtools seem to benefit from a similar curb cut effect, where gains in a tool’s usability for one domain generalizes across many others.

Post reply on HN