Show HN: We built an open source, zero webhooks payment processor
58 comments
·November 25, 2025baobabKoodaa
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.
codegeek
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.
amelius
It's probably because "we built our castle inside Stripe's kingdom" doesn't sound very cool.
However, if enough people start using this then they might become the new gatekeepers because they could swap Stripe for any other payment processor without the need of the user knowing.
Aurornis
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 learn that they can make some sales by promising a non-technical manager that buying this product will actually save them money because it’s easier to use.
whizzter
Literally describes one company I work for periodically.
skwee357
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.
runako
It looks like this is more akin to a React-only Chargebee where entitlements etc. are stored with the billing provider.
(Apologies if I am misreading the site.)
agreeahmed
For now, yes. The game plan over time is to get deeper into the actual card rails side of things. But first we really want to nail the developer experience.
jfyi
You can't standardize the developer experience across different processors. I'm not trying to be negative here, just practical.
You are going to run into things like TSYS closing out batches every three days regardless of what happens.
The handling features for them and their customers thing is going to be a herculean task over even a couple different platforms. Not impossible, but it's big and you would do well to see what's out there before committing to a standard interface. Take a look at https://datacapsystems.com/ to see it done well.
Also, adding another layer like this, you better have an early plan to staff a support desk.
Oh, also, you are gateway, not a processor.
whizzter
You intend to restrict this to a single market? There's some sibling comments that do point out that.
Much "annoyances" when it comes to money is all those weird laws and rules from lower level companies in place, improving things for developers is a laudable goal but I do hope that you guys have some real world experience with these systems apart from frustrations as system users because doing a good DX right now feels like it could make you end up in a dead end.
Denvercoder9
That's fine, but it does mean that your current submission title is factually incorrect. You didn't build a payment processor, you build a payment gateway.
turnsout
The DX of Stripe is already great—it sounds like you want to give Stripe reasonable defaults. Not a bad idea, but if you know what you're doing, you can have AI read the Stripe docs and implement something based on established patterns. Who is your ICP?
guessmyname
Who cares about developer experience? Genuinely asking, because I’m a developer too and I certainly don’t care. What we care about is solving the actual problem of payments with the downstream companies.
jazzyjackson
DX = developers not shooting themselves in the foot and making it impossible to cancel my free trial because my account got deleted but the autopay didn't
fewers bugs = happier customers not getting charged for shit they didn't agree to be charged for
poly2it
Stripe became dominant by improving developer experience, which cuts implementation costs.
mcflyin619
I care about my own developer experience. If i can save a headache and some time integrating payments, I'm all for it.
Scubabear68
“Well your payments platform doesn’t actually do payments, but the developer experience of doing nothing was flawless!”
Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
redbell
So, this is somehow similar to Polar (https://polar.sh/)
dperfect
It looks like this does make some things easier, but I'm not sure if it's actually better.
From what I can tell, any time you use this to check something like the customer's subscription state (or anything else payment-related) - either from the front end or the back end - it's going to perform an API request to Flowglad's servers. If you care about responsiveness, I'm not sure that's a good idea. Of course, you can cache that state if you need to access it frequently, but then it kind of defeats the purpose of this layer.
Stripe integration can be tricky, but if you don't want to store anything locally, you might as well just hit Stripe's APIs without the middleman. For the payment systems I've worked on, having cached state in the database is actually really nice, even if it's a bit more work. Want to do a complicated query on your customers based on payment/subscription state and a bunch of other criteria? It's just a DB query. With this, I think you'll be hoping they expose an API to query what you need and how you need it. Otherwise, you'll be stuck waiting for a thousand API requests to fetch the state of each of your customers.
baobabKoodaa
For what it's worth, the landing page is one of the most beautifully designed things I have seen in a long time. Congratz on the launch, didn't want to be so negative. I just hate that this is built on top of Stripe :(
willcodeforfoo
I liked it too, reminds me of zed.dev...
seanw265
Stripe billing definitely leaves something to be desired and agree that a layer on top can improve the DX tremendously.
What differentiates you from competitors like Lago and Autumn?
clintonb
> 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.
OsrsNeedsf2P
Sure, but everything from the Stripe UI down to their API is feature creeped. I remember using it 10 years ago and I got it working in 10-20 minutes. Last month I see it up for my new project and it took almost a whole day
tyre
Were you using it in the same way?
agreeahmed
I'd bet the typical payments integration has more complex requirements now than those from 10 years ago. That's what usually happens as a space becomes more important and, therefore, more regulated. Usually new entrants will come in and try to provide a tidier interface for solving an increasingly complex problem. In payments, as others in the comments have pointed out, that process is hampered by the gatekeepers involved.
You'd have to commit to building an amazing developer experience and navigating bank partnerships and compliance (per country), risk, antifraud, etc.
That's why the payments devex feels so behind the DB, hosting, or auth devex today.
huflungdung
[dead]
aftbit
How does the actual payment processing work? Do you need a Stripe token or Braintree or some other fixed provider?
agreeahmed
Currently we're using Stripe to process payments, so you get all the benefits they provide for antifraud etc. baked in. You don't need to provide a Stripe API key, you just go through a Stripe Connect account creation through us. You're still the settlement merchant.
Over time, we'd like to go deeper on that layer of the stack. But it's a long journey and we're still super early.
pat_space
They say they use stripe for now
fuddle
I have to say, this is a great approach to open source licencing: https://github.com/flowglad/flowglad/blob/main/LICENSE
It makes it very clear, and easy to understand.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3
fuddle
It looks like you need to update this file https://github.com/flowglad/flowglad/tree/main/platform#read... Its still using the Mintlify starter kit
harrisontelyan
thanks for heads up, fixing
swedishuser
> 2.9% + 30¢
Very expensive!
rickcarlino
Isn't this pretty much what every processor everywhere charges? I have been out of the industry for 10+ years but I remember this being pretty standard.
agreeahmed
It ain't by much, but we're a tiny bit cheaper than Stripe when you consider how much they charge for Billing (.7% for them vs .65% for us). And pretty much every Stripe integration uses Stripe Billing (unless they pair with a 3rd part billing SaaS)
runako
> pretty much every Stripe integration uses Stripe Billing
Isn't Stripe Billing only for subscriptions?
skramzy
That's Stripe's transaction fee, not theirs
irisman
Don't think there is a cheaper alternative to stripe. Polar and Dodo is 4% + 40¢
tyre
Braintree says it is 2.89% + $0.29 USD. Specifically priced at one bip and one cent cheaper lol
koakuma-chan
Name "Braintree" is much worse than "Stripe" so them being one bip and one cent cheaper is completely cancelled out.
baobabKoodaa
Standard.
koakuma-chan
Something tells me the main problem with payment processing is integrating with card companies like visa and mastercard, and not whether you use webhooks or not (if I understand correctly how online payments work).
agreeahmed
Closer-to-the metal integrations with providers is definitely a big headache. Solving that problem takes a bit longer because you need bank partnerships, in many cases have to pass compliance screens, etc. We're aiming to tackle the more tractable part first which is the developer experience
koakuma-chan
If you're trying to be like Vercel—it's a red flag for any reasonable person when you clearly spent more effort on your landing page than your actual product. What made Stripe so successful is that, I personally would not even attempt, like you said, "integrations with providers" "bank partnerships" "compliance screens" because that sounds basically impossible.
harrisontelyan
we're lucky enough to have a founding designer who makes it look easy in about a week - we spent about a year on the product in silence.
irisman
"It's hard so you shouldn't try doing it"
thank you, very productive reply
baobabKoodaa
Yep! I would love for somebody to actually solve that problem.
mcflyin619
What sold me on flowglad was the single source of truth and not having to hold customer stripe info in my DB. Although it took me a little while to figure that out lol
baobabKoodaa
Six minutes after this story was posted on HN you made this HN account to post this. So when you say it took you a little while to figure out... by little while you mean less than six minutes?
mcflyin619
I appreciate your concern and can understand your suspicion of when my account was made and when this post was posted. I am in their discord, because I have used their product for about 6 months now, and they mentioned hackernews, and I was curious because I have never heard of it. Now does that mean my comment about how the product has helped me in my projects is now not valid? Have a great day, and either try it or dont, but no need to try and bring me down for supporting a company that has made my job easier.
baobabKoodaa
Okay, fair enough. It just looked like a sockpuppet account, but okay, I believe you you're real. Sorry.
FWIW your claim here is false: "Everything you have commented on this post has been negative". I don't think this comment of mine was negative: "the landing page is one of the most beautifully designed things I have seen in a long time". Also note that when someone criticized the level of fees, I responded to that comment by saying that the fees were "standard" (as opposed to high). So just to set the record straight, not "everything" I commented here was negative.
null
Hi HN! For the past bit we’ve been building Flowglad (https://flowglad.com) and can now feel it’s just gotten good enough to share with you all:
Repo: https://github.com/flowglad/flowglad
Demo video: https://www.youtube.com/watch?v=G6H0c1Cd2kU
Flowglad is a payment processor that you integrate without writing any glue code. Along with processing your payments, it tells you in real time the features and usage credit balances that your customers have available to you based on their billing state. The DX feels like React, because we wanted to bring the reactive programming paradigm to payments.
We make it easy to spin up full-fledged pricing models (including usage meters, feature gates and usage credit grants) in a few clicks. We schematize these pricing models into a pricing.yaml file that’s kinda like Terraform but for your pricing.
The result is a payments layer that AI coding agents have a substantially easier time one-shotting (for now the happiest path is a fullstack Typescript + React app).
Why we built this:
- After a decade of building on Stripe, we found it powerful but underopinionated. It left us doing a lot of rote work to set up fairly standard use cases - That meant more code to maintain, much of which is brittle because it crosses so many server-client boundaries - Not to mention choreographing the lifecycle of our business domain with the Stripe checkout flow and webhook event types, of which there are 250+ - Payments online has gotten complex - not just new pricing models for AI products, but also cross border sales tax, etc. You either need to handle significant chunks of it yourself, or sign up for and compose multiple services
This all feels unduly clunky, esp when compared to how easy other layers like hosting and databases have gotten in recent years.
These patterns haven’t changed much in a decade. And while coding agents can nail every other rote part of an app (auth, db, analytics), payments is the scariest to tab-tab-tab your way through. Because the the existing integration patterns are difficult to reason about, difficult to verify correctness, and absolutely mission critical.
Our beta version lets you:
- Spin up common pricing models in just a few clicks, and customize them as needed - Clone pricing models between testmode and live mode, and import / export via pricing.yaml - Check customer usage credits and feature access in real time on your backend and React frontend - Integrate without any DB schema changes - you reference your customers via your ids, and reference prices, products, features and usage meters via slugs that you define
We’re still early in our journey so would love your feedback and opinions. Billing has a lot of use cases, so if you see anything that you wish we supported, please let us know!