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

You setup a payment flow and it took you less than a day, and you are upset? I don't understand.

Gotta say we admire both teams, and have a lot of respect for anyone trying to make progress in this space.

As far as differences: both are an additional service you need to bolt-on in addition to signing up for Stripe. We're aiming to consolidate onboarding as a single provider that both processes. A lot of work still to do on our side, but that's where we want to end up: that you get your dream devex without needing to sign up for 2 products.

Both are essentially billing-only services where you bring your API key. We have a billing engine that we built from scratch, and are actually processing the payments, currently using Stripe Connect under the hood.

Lago seems to still require you to deal with webhooks - if not theirs, then Stripe's - and is focused on "billing as write operation" (their first-class concern is producing a correct, well-formed charge or invoice object). We want to solve both the "read" (what features can my customer access, what balance does their usage meter have?) and the "write" more conventional billing operations like charges, prorations, converting free trials to paid, etc.

With Autumn we're tackling a similar problem but they currently still require you to use Stripe Billing + your API key. So you'll be paying for Stripe Billing + Autumn (unless you self host). Overtime as we get deeper into the money movement side of things our paths will look more different, as more of our devex will include smoother ways to handle funds flows, tax compliance, etc.

And compared to both, at least from what I can tell from the outside, we're putting relatively larger share of our brain cycles towards making our SDK and docs deeply intuitive for coding agents.

We want to design our default integration path around the assumption that you will have a coding agent doing most of the actual work. As a result we've got some features like e.g. an MCP-first integration path that makes it easy for your coding agent to ask our docs pointed questions that may come up as it integrates Flowglad. And a dynamically generated integration guide md file that considers both your codebase context. A lot of that is the result of our own trial and error trying to integrate payments with coding agents, and we're going to be investing a lot more time and care into that experience going forward.

100% agree - this is not a space to tread into lightly.

We have some really knowledgeable payments people in our corner, including several veterans with many decades of payments industry experience as leaders at the big payments players. There's a lot that we've been able to learn from them as they help us navigate the financial services side of this business. We're conscious of how much work there is to do, and how the "good DX" is really just the visible tip of the iceberg.

Currently through Stripe we are able to onboard merchants wherever Stripe can serve them directly. Our upcoming merchant of record offering (which we hope to launch soon), will be available to merchants wherever Stripe can send payouts, which is a longer list of maybe 150+ countries.

The pathway to building deeper payment rails will indeed have to be country-by-country as each one requires new banking partners and compliance regimes.

Basically this. The existing integration paradigm for payments, at its worst, feels like a warehouse filled with footguns on the floor with the lights turned off. Esp for newer developers who are used to more modern devexes which explicitly try to take reasoning about complex state transitions off of your plate.

give the product a go and lmk how vibe coding payments performs