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.
We have a plan to allow you to store more of this data on the merchant's side and still benefit from the work we've done to refine our data model, and make the SDK super usable. Even if you do hit Stripe's APIs, you will need to maintain mappings of price ids to your plans, your plans to what features you grant for each, stripe customer ids to your customer ids, etc. That's the kind of grunt work and maintenance burden we'd like to eliminate.
Plus, Stripe is explicitly designed to be a write-optimized system, and discourages[0] using them as a realtime read layer. We're super early in the journey but that's the problem we want to solve: how can we give software devs the same unified money movement + value movement experience that Shopify has availed to DTC brands for nearly 20 years?
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.
Appreciate the response. I suppose the follow up is, why not make the library framework agnostic initially or work towards that, rather than have to maintain support for x number of frameworks into the future?
That’s a devilish engineering question. If you are truly framework agnostic you limit how much work you can do for your users, because a lot of the work happens inside of the framework. We decided we’d commit to doing the work so our customers didn’t have to.
E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.
How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains.
In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify has webhooks but they are not the primary load bearing site of payment integration for most storefronts.
Payments webhooks were, from what I can tell in the history, a hack for side stepping gnarly problems in domain modeling and read optimization.
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.
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.
With Flowglad you’d pay ever so slightly less than you would with a vanilla Stripe integration which usually includes Stripe Billing. That total cost is 3.6% (2.9% per charge + .7% for billing) and $.30, whereas we’re 3.55%.
We’re not really trying to compete on cost. But we certainly aren’t more expensive once you include the cost of Stripe Billing.
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 :(
Funny thing about the site: we deliberately tried to keep it single-page because we spent all of the past year building / testing the billing engine, data model, and SDK.
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 to know in order to integrate them.
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
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.
Polar prohibits: Human services (custom development, design and consultancy).
Is this the case with Flowglad? We have a SaaS with a monthly team seat fee + usage fees, but we also offer a bespoke service where we may bill per hour or bill per project (for work done and delivered inside of the SaaS). So these would be higher ticket.
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.
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.
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.
Their website says fully opensource and since it’s a Stripe wrapper, this seems to be an opensource alternative to Stripe Elements. It does require a Flowgrad account and key so it will provide value if other payment processors started using it.
Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
Ah that is another benefit, using Stripe Elements and Stripe directly, you have to save the subscription ID and other fields in your database. Flowgrad seems to handle this on their side.
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 feels more like a "wrapper" than Vercel is that we haven't yet built out our own onboarding and KYC flow. We wanted to first deliver an amazing developer experience - something we're still working towards.
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 Stripe key to steer API requests on your behalf).
We know that makes us look a bit like a fish with legs while we grow towards where we want to be.
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.
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
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 ticket could be closed.
This is the default. I have a few teams like this under my charge, currently.
I ask them to protect themselves by logging what data they will need to troubleshoot a new feature.
Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs.
It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit.
Days long anxiety-filled shit storms for absolutely no reason.
I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...
Webhooks are not a struggle conceptually. They are a struggle operationally IMO.
In amy case why does a dev need to understand a (yet another) poor DX complex API (stripe) in addition to the other 20 they need to deal with. What is wrong with taking something off the plate. It is like daying dont use high level languages, use Rust, don't use a library to make http calls roll your own etc.
I think Stipe is one of the best designed APIs I ever had to work with.
But to reply to your point, there is no way out of this. You either understand the tools you work with, or you end up vendor locked to tools like vercel/next (the target audience of OPs tool, as it seems), which promise simplification, but end up being their own monsters.
I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.
To the contrary, I feel the distinction to be very arbitrary and especially in the context of web applications so muddy it’s almost useless. Who is responsible for websockets? CSP? JavaScript chunk caching? Web worker edge deployment? File uploads? HTTP/2 stream usage?
The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.
There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and started putting “full-stack” on their CVs even when their experience only covered a slice of the stack. Bootcamps and junior developers adopted the term too, and hiring managers kept accepting it because the candidates were otherwise solid.
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
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.
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.
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.
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 soon as we could. That's why we very deliberately built our own billing engine from scratch. We could have gotten to market faster by just mapping onto Stripe Billing, but we would have foregone valuable experience mapping processor lifecycle events to our data model. For a while that's going to be much of the work on our plate, standardizing how we map their lifecycle to ours.
We took the past year basically studying the prior art and developing / testing a data model that we feel is well on its way to describing the general case. I was frankly surprised how long it took to really hammer out the primitives.
> 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.
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.
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.
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.
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.
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?
This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together.
Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU
Today our ideal customer is someone starting a project on day one who wants an easy pathway to 1) get stood up ASAP, and 2) start iterating on pricing as they learn what customers really care about. What we found when talking with dozens of builders was that the DX is indeed much better than e.g. Adyen, Braintree, etc. But their DX is far from the counterpart best in class devtools in auth, hosting, or databases.
To be clear, what Stripe has built is a towering accomplishment. But a lot of why innovation in payments DX has been slower than other parts of the stack is that since Stripe, there haven't really been many others who have attempted to tackle the *entire* job to be done.
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.
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
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.
100% This. I remember joining a billing team that assumed calls to Braintree succeed or fail, so everything was just calling the API as though it was a local function call.
It was great fun debugging the twice annual incidents where the API returned a HTTP500 but charged the customer and created the recurring subscription anyway.
Not to forget we had to scream at them for 6 months to implement 3DS2 on top of their Subscriptions API. Turns out we were the only users of it!
It scans that way right now because Stripe is more visibly involved in the onboarding process. Maybe another way to parse it is "Shopify for software", where we combine the movement of money and subsequent state transitions involved in unlocking value. But instead of shipping physical items, it's granting entitlements.
Either way, thank you for the feedback. We're still refining how we explain it.
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
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.
Very helpful callouts - both areas we want to build more robust product coverage.
Handling tax and VAT edge cases are coming up on our roadmap. We want to offer a merchant of record service soon, and eventually make it so that you can steer the funds flow at a per-transaction level.
We monitor our uptime closely[0], but we're also working on giving more options to self-host the source of truth component of our offering for people who want to be more in control of their certainty.
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.
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.
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 standard, we could standardize on that (like how cloud providers standardized on S3).
I think India has implemented something to this effect.
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 get something that approximates this with a PCI vault or a payments orchestrator, but it's really hard -- maybe impossible -- to fully abstract away all the differences.
It won't work, the feature set offered by different payment processors differs too much to capture in one consistent API. Even Stripe itself already offers 3 or 4 different ways to integrate with them.
What you want already exists though, and it's called a payment orchestrator. They integrate with different payment providers and provide you one API. You pay for that by getting a much smaller feature set.
How do you guys handle past due / grace period if there are no webhooks? Like, do you notify the end-user that their card failed and they need to update their card? Or do you let Stripe send emails?
What's your approach to 3DS and related race-conditions for subscriptions? In my experience 3DS is by far the biggest problem for subscription integrations - not the webhooks.
Grace periods and past due - our current default behavior is:
- when the first charge fails, we block access
- when the n+1th charge fails, we continue grant access until you cancel their subscription
There's a lot of work to do to make that behavior more configurable, because every merchant has a different policy.
For 3DS we're working on getting more explicit coverage for. Not quite 3DS but related: we currently have it set up so that if your customer successfully adds a payment method but the first charge fails, we also won't grant entitlements in that case.
Lots of weird payments edge cases to work through still.
This is a needed abstraction! Love the idea of bringing a reactive DX to payments. I'm keen to know: Is Flowglad the source of truth for feature/credit state, and how do you achieve low latency for real-time feature gating?
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.
You should be able to access it via the “Set Up” tab in your navigation bar. It’s step 3 “verify and enable live payments” - we’ll clear up that copy, thank you for flagging!
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.
Currently it feels more like a Stripe wrapper because we haven't yet fully in-housed the onboarding experience. But you don't bring your Stripe API key, you setup a Stripe Connect platform account.
Recharge Payments looks cool, also seems more focused on Shopify stores?
Totally. When you look at the history of payments processing usually new entrants start with a significant technical improvement and then quickly graduate into learning how to pricing new types of risk
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
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?
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.
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.
We're working on getting there. What got us out of our seats to build this was realizing that LLMs still struggled with the fairly basic data modeling and distributed systems problems that existing payments providers pose. Any solution they came up with was only ever narrowly correct, brittle, and a nightmare to maintain
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.
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)
Stripe Billing handles subscriptions and usage based billing now. Most software products fall in one of those two categories, or sometimes both. As a result, most software companies are paying more than 2.9% + $0.30 for Stripe, closer to 3.6% + $.30.
To only pay Stripe 2.9% + $.30 they'd need to only use Stripe just for charges, and either build their own billing engine (usually poor use of time) or use a 3rd party SaaS.
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).
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
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.
I'm not saying they shouldn't be doing that. It's actually the opposite—they got the VC money, they might as well do something actually useful with it.
That's definitely the gameplan. We believe very sincerely that developers deserve more choice when it comes to payments than they currently have. It's a central reason why we started building this.
It just takes longer to make progress on that problem because of all the institutions involved.
Visa and Mastercard don't want you to integrate with them. They want you to go through an intermediary that they can have more contractural control over and that they can rate limit and monitor.
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.
Yeah this very true.
We have a plan to allow you to store more of this data on the merchant's side and still benefit from the work we've done to refine our data model, and make the SDK super usable. Even if you do hit Stripe's APIs, you will need to maintain mappings of price ids to your plans, your plans to what features you grant for each, stripe customer ids to your customer ids, etc. That's the kind of grunt work and maintenance burden we'd like to eliminate.
Plus, Stripe is explicitly designed to be a write-optimized system, and discourages[0] using them as a realtime read layer. We're super early in the journey but that's the problem we want to solve: how can we give software devs the same unified money movement + value movement experience that Shopify has availed to DTC brands for nearly 20 years?
[0] https://docs.stripe.com/rate-limits
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.
Appreciate the response. I suppose the follow up is, why not make the library framework agnostic initially or work towards that, rather than have to maintain support for x number of frameworks into the future?
That’s a devilish engineering question. If you are truly framework agnostic you limit how much work you can do for your users, because a lot of the work happens inside of the framework. We decided we’d commit to doing the work so our customers didn’t have to.
E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.
How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
The reason webhooks are popular is because they are easy, reliable and they work.
Now I might have to spin up a whole area of infrastructure I may not yet have to track eg usage, subscription tier, cancellations etc
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains.
In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify has webhooks but they are not the primary load bearing site of payment integration for most storefronts.
Payments webhooks were, from what I can tell in the history, a hack for side stepping gnarly problems in domain modeling and read optimization.
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.
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.
With Flowglad you’d pay ever so slightly less than you would with a vanilla Stripe integration which usually includes Stripe Billing. That total cost is 3.6% (2.9% per charge + .7% for billing) and $.30, whereas we’re 3.55%.
We’re not really trying to compete on cost. But we certainly aren’t more expensive once you include the cost of Stripe Billing.
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 :(
I liked it too, reminds me of zed.dev...
Thank you, Zed's is so beautiful. Our team's blushing
Thank you, that's very kind of you.
Funny thing about the site: we deliberately tried to keep it single-page because we spent all of the past year building / testing the billing engine, data model, and SDK.
> 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 to know in order to integrate them.
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
You setup a payment flow and it took you less than a day, and you are upset? I don't understand.
Were you using it in the same way?
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.
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
I was wondering what the catch was, seemed pretty lightweight to be a payment processor. My first thought reading the setup guide was "what no HSMs?"
how much fee do you take
Only stripe?
Polar prohibits: Human services (custom development, design and consultancy).
Is this the case with Flowglad? We have a SaaS with a monthly team seat fee + usage fees, but we also offer a bespoke service where we may bill per hour or bill per project (for work done and delivered inside of the SaaS). So these would be higher ticket.
Would you support this?
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.
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.
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.
Their website says fully opensource and since it’s a Stripe wrapper, this seems to be an opensource alternative to Stripe Elements. It does require a Flowgrad account and key so it will provide value if other payment processors started using it.
Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
I thought the whole post was about the benefits, namely that Stripe has too many webhooks and doesn’t handle enough of the tax computation.
Did I misunderstand something? Or is this about a different angle?
Ah that is another benefit, using Stripe Elements and Stripe directly, you have to save the subscription ID and other fields in your database. Flowgrad seems to handle this on their side.
>However, if enough people start using this then they might become the new gatekeepers
Stripe would likely change their ToS and then revoke their API keys before they could get anywhere near that level of dominance.
They hide it because you won't choose them if you were aware that it's Yet Another Wrapper around someone else's service.
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 feels more like a "wrapper" than Vercel is that we haven't yet built out our own onboarding and KYC flow. We wanted to first deliver an amazing developer experience - something we're still working towards.
All good. You know HN feedback is straight and brutal but we are all trying to be helpful.
It’s not very well hidden, it took me around 15s to figure it out from the main page. They are also trying to diversify (obviously).
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 Stripe key to steer API requests on your behalf).
We know that makes us look a bit like a fish with legs while we grow towards where we want to be.
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.
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
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 ticket could be closed.
This is much more common than you might think.
Your example is hilarious; it sounds like the team understands analytics just fine if they're solely working towards one metric.
That describes more than just one POS (Point of Sale) company I know of.
This is the default. I have a few teams like this under my charge, currently.
I ask them to protect themselves by logging what data they will need to troubleshoot a new feature.
Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs.
It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit.
Days long anxiety-filled shit storms for absolutely no reason.
I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...
Webhooks are not a struggle conceptually. They are a struggle operationally IMO.
In amy case why does a dev need to understand a (yet another) poor DX complex API (stripe) in addition to the other 20 they need to deal with. What is wrong with taking something off the plate. It is like daying dont use high level languages, use Rust, don't use a library to make http calls roll your own etc.
I think Stipe is one of the best designed APIs I ever had to work with.
But to reply to your point, there is no way out of this. You either understand the tools you work with, or you end up vendor locked to tools like vercel/next (the target audience of OPs tool, as it seems), which promise simplification, but end up being their own monsters.
Even the best developer in the world can struggle when there are like 250 webhook events on a platform (as is the case for Stripe).
There's a lot of React devs out there who have never touched a server-side anything.
I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.
To the contrary, I feel the distinction to be very arbitrary and especially in the context of web applications so muddy it’s almost useless. Who is responsible for websockets? CSP? JavaScript chunk caching? Web worker edge deployment? File uploads? HTTP/2 stream usage?
The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.
There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and started putting “full-stack” on their CVs even when their experience only covered a slice of the stack. Bootcamps and junior developers adopted the term too, and hiring managers kept accepting it because the candidates were otherwise solid.
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
It’s a sad world.
-- actual (retired) full-stack engineer
If I claimed to be a generalist, would HR understand what I mean?
It's really not hard to be good at both. Or at least to understand enough to be fluent in both.
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.
Literally describes one company I work for periodically.
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.
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.
> 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 soon as we could. That's why we very deliberately built our own billing engine from scratch. We could have gotten to market faster by just mapping onto Stripe Billing, but we would have foregone valuable experience mapping processor lifecycle events to our data model. For a while that's going to be much of the work on our plate, standardizing how we map their lifecycle to ours.
We took the past year basically studying the prior art and developing / testing a data model that we feel is well on its way to describing the general case. I was frankly surprised how long it took to really hammer out the primitives.
> 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.
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.
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.
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.
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.
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?
> The DX of Stripe is already great
This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together.
Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU
Today our ideal customer is someone starting a project on day one who wants an easy pathway to 1) get stood up ASAP, and 2) start iterating on pricing as they learn what customers really care about. What we found when talking with dozens of builders was that the DX is indeed much better than e.g. Adyen, Braintree, etc. But their DX is far from the counterpart best in class devtools in auth, hosting, or databases.
To be clear, what Stripe has built is a towering accomplishment. But a lot of why innovation in payments DX has been slower than other parts of the stack is that since Stripe, there haven't really been many others who have attempted to tackle the *entire* job to be done.
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.
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
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.
100% This. I remember joining a billing team that assumed calls to Braintree succeed or fail, so everything was just calling the API as though it was a local function call.
It was great fun debugging the twice annual incidents where the API returned a HTTP500 but charged the customer and created the recurring subscription anyway.
Not to forget we had to scream at them for 6 months to implement 3DS2 on top of their Subscriptions API. Turns out we were the only users of it!
Stripe became dominant by improving developer experience, which cuts implementation costs.
I care about my own developer experience. If i can save a headache and some time integrating payments, I'm all for it.
“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.
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.)
It scans that way right now because Stripe is more visibly involved in the onboarding process. Maybe another way to parse it is "Shopify for software", where we combine the movement of money and subsequent state transitions involved in unlocking value. But instead of shipping physical items, it's granting entitlements.
Either way, thank you for the feedback. We're still refining how we explain it.
So, this is somehow similar to Polar (https://polar.sh/)
Is it using Stripe under the hood? Who is the actual payment gateway provider?
Yes, it looks like its using Stripe Connect under the hood. So these guys are just middle men.
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 ;)
Very cool guys. Curious about a few things if you’re open to sharing:
- How are you handling tax/VAT and edge cases? Like usage backfills or retroactive credit grants, etc. etc.
- What’s the failure mode if your service is down?
Either way, refreshing to see someone go after this with the opinionated DX!
Very helpful callouts - both areas we want to build more robust product coverage.
Handling tax and VAT edge cases are coming up on our roadmap. We want to offer a merchant of record service soon, and eventually make it so that you can steer the funds flow at a per-transaction level.
We monitor our uptime closely[0], but we're also working on giving more options to self-host the source of truth component of our offering for people who want to be more in control of their certainty.
[0] https://status.flowglad.com
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.
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!
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.
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 standard, we could standardize on that (like how cloud providers standardized on S3).
I think India has implemented something to this effect.
Thoughts?
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 get something that approximates this with a PCI vault or a payments orchestrator, but it's really hard -- maybe impossible -- to fully abstract away all the differences.
It won't work, the feature set offered by different payment processors differs too much to capture in one consistent API. Even Stripe itself already offers 3 or 4 different ways to integrate with them.
What you want already exists though, and it's called a payment orchestrator. They integrate with different payment providers and provide you one API. You pay for that by getting a much smaller feature set.
How do you guys handle past due / grace period if there are no webhooks? Like, do you notify the end-user that their card failed and they need to update their card? Or do you let Stripe send emails?
What's your approach to 3DS and related race-conditions for subscriptions? In my experience 3DS is by far the biggest problem for subscription integrations - not the webhooks.
Grace periods and past due - our current default behavior is: - when the first charge fails, we block access - when the n+1th charge fails, we continue grant access until you cancel their subscription
There's a lot of work to do to make that behavior more configurable, because every merchant has a different policy.
For 3DS we're working on getting more explicit coverage for. Not quite 3DS but related: we currently have it set up so that if your customer successfully adds a payment method but the first charge fails, we also won't grant entitlements in that case.
Lots of weird payments edge cases to work through still.
This is a needed abstraction! Love the idea of bringing a reactive DX to payments. I'm keen to know: Is Flowglad the source of truth for feature/credit state, and how do you achieve low latency for real-time feature gating?
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?
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.
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?
You should be able to access it via the “Set Up” tab in your navigation bar. It’s step 3 “verify and enable live payments” - we’ll clear up that copy, thank you for flagging!
Zero webhooks is a bit optimistic over the longer term, surely?
Payments are getting slightly more asynchronous, not less.
How does the actual payment processing work? Do you need a Stripe token or Braintree or some other fixed provider?
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.
They say they use stripe for now
Any plans on building the Stripe Connect features?
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
I've been an early user. Big fan of what Agree and team have managed to build here.
This is like a Stripe wrapper? Similar to Recharge Payments… the flow looks identical, well almost.
Currently it feels more like a Stripe wrapper because we haven't yet fully in-housed the onboarding experience. But you don't bring your Stripe API key, you setup a Stripe Connect platform account.
Recharge Payments looks cool, also seems more focused on Shopify stores?
so stoked for this! excited to build on top of flowglad
Payment processing is not a technical problem. It is a problem of risk. That is why we have providers and things like banks.
Totally. When you look at the history of payments processing usually new entrants start with a significant technical improvement and then quickly graduate into learning how to pricing new types of risk
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
thanks for heads up, fixing
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
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?
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.
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.
I hadnt seen those, and went ahead and edited my comment to remove that.
i do wish i could vibe code payments. stripe is good but LLMs need help.
We're working on getting there. What got us out of our seats to build this was realizing that LLMs still struggled with the fairly basic data modeling and distributed systems problems that existing payments providers pose. Any solution they came up with was only ever narrowly correct, brittle, and a nightmare to maintain
give the product a go and lmk how vibe coding payments performs
> 2.9% + 30¢
Very expensive!
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.
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)
> pretty much every Stripe integration uses Stripe Billing
Isn't Stripe Billing only for subscriptions?
Stripe Billing handles subscriptions and usage based billing now. Most software products fall in one of those two categories, or sometimes both. As a result, most software companies are paying more than 2.9% + $0.30 for Stripe, closer to 3.6% + $.30.
To only pay Stripe 2.9% + $.30 they'd need to only use Stripe just for charges, and either build their own billing engine (usually poor use of time) or use a 3rd party SaaS.
That's Stripe's transaction fee, not theirs
Don't think there is a cheaper alternative to stripe. Polar and Dodo is 4% + 40¢
Braintree says it is 2.89% + $0.29 USD. Specifically priced at one bip and one cent cheaper lol
Name "Braintree" is much worse than "Stripe" so them being one bip and one cent cheaper is completely cancelled out.
Standard.
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).
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
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.
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.
"It's hard so you shouldn't try doing it"
thank you, very productive reply
I'm not saying they shouldn't be doing that. It's actually the opposite—they got the VC money, they might as well do something actually useful with it.
That's definitely the gameplan. We believe very sincerely that developers deserve more choice when it comes to payments than they currently have. It's a central reason why we started building this.
It just takes longer to make progress on that problem because of all the institutions involved.
Yep! I would love for somebody to actually solve that problem.
Visa and Mastercard don't want you to integrate with them. They want you to go through an intermediary that they can have more contractural control over and that they can rate limit and monitor.