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

111–120 of 230 posts

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

#111

Post by [deleted] »

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…

[deleted]

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

#112

Post by codegeek »

agreeahmed wrote: post #110
codegeek wrote: post #43

Earlier quoted context omitted.

Pretty much my 1st question when I see a new billing product. Thank you for answering that. I don't understand why products like these hide that fact or keep it hidden. A great product that requires connecting a payment processor can still be a great product but it is not an actual payment processor and that part needs to be clear immediately on your landing page.

This is great feedback. We aren't trying to keep it hidden at all. But we could be clearer in how we communicate it. The processing happens through our Stripe Connect platform, through which you currently have to set up a Stripe account. Over time, these details will be more abstracted away, much like Vercel is reselling AWS under the hood but doesn't require you to hand over AWS keys. Right now, the reason this feel…

All good. You know HN feedback is straight and brutal but we are all trying to be helpful.

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

#113

Post by agreeahmed »

Aurornis wrote: post #44
baobabKoodaa wrote: post #7

For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe.

I’ve been in software long enough to know that there’s a market for products that make things slightly easier for devs and their managers who think even common APIs like stripe are too hard. The number of devs who are struggling with web hooks and simultaneously have some budget to spend is probably bigger than you think. Often these products are pitched and sold to non-technical managers, too. The sales team will le…

Definitely - it's the nature of software that it tends towards higher order abstractions that make the tools easier and easier to use. The final frontier is English as a programming language. The tools that are easiest to program in English (via a coding agent that "compiles down" your prompt into code) tend to have the tersest APIs, with the least amount of reasoning about state across service boundaries.

It's very likely at this point that the supermajority of future programmers will have almost no formal computer science education. They'll want tools that don't require a deep understanding of the prior generations' layer of abstraction. That's kinda the world we're preparing for - builders who don't need to be deeply technically involved in the details of their vendors in order to build successful software companies

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

#114

Post by eli_yumnik »

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

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

#115

Post by ghurtado »

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?

You still need to have a payment provider / merchant account, so that part remains the same

For all I could see this is no different than any other payment gateway service. Well, it is different in one important way: you'll pay a higher percentage per transaction, since the middle man needs to make money somehow.

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

#116

Post by agreeahmed »

ForHackernews wrote: post #75
skwee357 wrote: post #49

Earlier quoted context omitted.

I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe. I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.

There's a lot of React devs out there who have never touched a server-side anything.

As the Javascript ecosystem has spilled out from just the frontend to also the backend, a lot of these React devs have found fullstack responsibilities on their shoulders.

Imo you can trace a lot of how devtools, particularly webdev tools, have evolved to this. They are more React-brained. Specifically they try to take state management responsibilities off their users' plates.

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

#117

Post by gopher_space »

withinboredom wrote: post #60
skwee357 wrote: post #49

Earlier quoted context omitted.

I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe. I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.

I had the pleasure of working with teams that couldn’t even figure out how to use analytics in their product. They had zero idea who was using it and how many people were using it. They ignored the thousands of DB deadlock messages in the logs; well, they just ignored the logs completely, actually. All they cared about was shipping the next feature and getting the one QA guy to agree it was working correctly so the t…

Your example is hilarious; it sounds like the team understands analytics just fine if they're solely working towards one metric.

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

#118

Post by agreeahmed »

mbesto wrote: post #93
agreeahmed wrote: post #74

Earlier quoted context omitted.

> Oh, also, you are gateway, not a processor. Technically right now we are a value-added payment acceptance reseller. Eventually we'd like to become a payfac. And maybe with the new regulations that came out in Georgia, a chartered merchant acquiring bank. But that's down the road. You're totally right about standardizing the devex across processors. We want to go as "close to the metal" as we realistically could as…

> We want to go as "close to the metal" as we realistically could as soon as we could. All of the value in payments is on the top (acquiring payfac side)...all of the value on the issuing side is only made via extremely high volume and requires a ton of tech that just schleps data (no fun). I'd recommend getting this idea out of your head.

Unless I'm misunderstanding, I think you might have gotten sides mixed up?

Issuing side (the side that "issues" the cards) is usually the one that people describe as "all of the value", while acquiring (the side that "acquires" merchants) usually is that one that needs to bring substantial volumes to market.

For context to anyone not familiar with payments, about 60-70% of the card revenue in a transaction goes to the customer's / issuing side because they are the side that assumes credit risk for the consumer. The merchant's / acquiring side has significantly tighter margins and usually needs substantial volume before it can become an interesting business. One way that entrants on the merchant side of the stack monetize is by bundling value-add software.

E.g. Stripe does this with Billing (+.7%) and Connect (+.25%).

Fwiw I agree that most people will find this tech extremely un-fun. But I'm a "payments rail guy" in the way that others might be "train guys". My inner child lights up at the thought of payment rails. My Substack, Vivid Leaves, is basically a bunch of essays about historical payment systems - some we worked with in Kenya, and others I studied from the USSR. I wrote all this before I had any idea I'd be starting a payments company: https://agree.substack.com

We know it's going to be a schlep, and we're going to have a blast schlepping through it.

* vocab fyis for anyone reading this not familiar with payments.

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

#119

Post by agreeahmed »

jfyi wrote: post #79
agreeahmed wrote: post #74

Earlier quoted context omitted.

> Oh, also, you are gateway, not a processor. Technically right now we are a value-added payment acceptance reseller. Eventually we'd like to become a payfac. And maybe with the new regulations that came out in Georgia, a chartered merchant acquiring bank. But that's down the road. You're totally right about standardizing the devex across processors. We want to go as "close to the metal" as we realistically could as…

Technically you are a wrapper api, but you are acting as a gateway. Though, if you were to claim to be a gateway you'd need pa-dss/ssf validation and that would cost a good chunk of that yc money, so I understand.

Exactly. One of our advisors who previously an exec at one of the card networks says that currently we are technically a "value-added gateway reseller".

Doesn't exactly roll off the tongue, but that's the most precise way to describe us right now. And not necessarily where we will stay.

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

#120

Post by johnxie »

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 experiments… and the experiments never stop now.

So anything that lets teams iterate without rewiring state machines every week is going to find an audience. Most people just want to ship, test, adjust, repeat, without their billing layer collapsing under the pace of AI.

Nice launch!

Post reply on HN