Show HN: We built an open source, zero webhooks payment processor
4 days ago (github.com)
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!
I don't get why you're calling it A) a "payment processor", even though you don't process any payment yourselves, and B) "open source", even though it's running everything through your SaaS and presumably also storing data in your databases (not speaking about telemetry but real business data). I struggle a lot with building a more flexible system for feature gates, usage credits, payment schemes etc., so I 100% understand the pain point you're addressing, but I don't feel like you're delivering much on your headline.
Glad to hear the pain points resonate with you, and we’d love to hear any thoughts you have on how we could address them better.
Re open source: the SaaS is under AGPLv3, and the rest is MIT.
Re “processor”: often when payment providers first get started they don’t fit into one of the established payment vendor categories because they need to piggyback off someone else’s infrastructure. We figured it would be better to make clear that we’re not a billing SaaS, but also providing payments processing - even if for now that’s through Stripe Connect.
Eg we are aligned with our merchants in worrying chargebacks in a way that “bring your Stripe key” billing SaaS is not, because our setup means their chargebacks are a concern for us similar to how they’re a concern for Stripe.
Oh I did not realize the whole „SaaS“ is open source, too! To be honest, the „payment processor“ part primed me in a way that I didn’t even investigate about the backend, I assumed it to be closed source due to that. Thank you for the clarification!
About the „processor“: IANAL, but I would assume that a payment processor has liabilities and regulations similar to that of a bank - line it’s the case for PayPal or Stripe. On the other hand, no one would raise a concern of you were forwarding transactions to Visa or some huge bank, so this is probably just a communication issue that you might want to tackle upfront.
1 reply →
Could you elaborate on how hard it is to use a different payments provider? I use Clover API with my bank being the acquirer, which is much cheaper than Stripe.
3 replies →
The license file states MIT and AGPL licences
For the library that links to their SaaS, not for their entire product.
1 reply →
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
> you will need to maintain mappings of price ids to your plans
I think you're overvaluing how much work this is. For years I just created the plans in Stripe and then manually copied them over into my database. If you're small and not changing your plans often, this is fine.
When eventually I got annoyed because I had a Stripe sandbox and my own staging environments I wanted to sync periodically, I banged out a 'sync' script in a couple hours. Could probably do it even less time with AIs these days.
> your plans to what features you grant for each
I don't understand how your service can even help with this. "Features" are necessarily part of my app, I have to define what the user is purchasing.
> stripe customer ids to your customer ids
It's one extra column.
Maybe you can call it 'grunt work' but how often are ya'all putting up new SaaS's?
Even if you can somehow keep your latency to a minimum, if you have even a second of down time, my app goes down with yours. I don't like that. Right now if Stripe goes down for a bit, nothing happens to my app. It keeps chugging along. Maybe some of my customers can't pay their monthly subscriptions for a bit but they're not locked out of the app.
This whole thing feels like a trap TBH. Feels like vendor lock-in. I am kind of locked into Stripe because it'd be a PITA to re-integrate with something else, but at least I own the data (sans credit card #s, which I don't want) and can move elsewhere if push comes to shove (well... OK, asking everyone to re-enter their card # would suck too).
1 reply →
That means you would need to expose your proprietary code and you will be left with no moat.
2 replies →
Congrats on getting to beta!
I very much relate to the problems you're trying to solve, so much so that I have created a Stripe integration library [0] that has very similar DX to flowgrad! (not nearly as feature rich however). I've also written a blog post as to why I built it[1].
Key difference is where the final billing information is stored, our library also ships db schemas and the webhook handlers write to that local db.
You should also check out our (open source, MIT) library[1] this is built on, it could be useful for you guys!
[0]: https://fragno.dev/docs/stripe/quickstart
[1]: https://fragno.dev/blog/split-brain-stripe
[2]: https://fragno.dev/docs/fragno
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.
Do you have any more details on how you designed the site? I see that it was in framer.
1 reply →
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.
You should look at using Preact (4kb alternative) and supply your frontend code as fully encapsulated with embedded preact. That way you client would only have to render your widget/app into an existing DOM element:
> customPreactRootRenderFunction(document.getElementById("outlet"))
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?
3 replies →
May I suggest web components? For all their warts, they are perfect for a use case like this. Even React, the IE of frameworks, supports them properly in v19.
1 reply →
> We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this
To be fair, chosing Svelte over React explicitly means that - if the React installed/userbase is 10-50x as big, you will be frustrated with this a lot. But in the end I don't get the frustration, in the end react is not a framework and you can render any component into a single HTML node that is part of your Svelte system. If the external library is encapsulated well, you shouldn't even notice that is react based.
Of course this means importing a ton of new libs and frontend code just to render billing. It's the same with the dependency on, say, Next. It's too many moving parts, could've been done without tying yourselves down to specific ‘cultures’. That said, it's a great endeavour and my hat is off.
1 reply →
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.
> I’m not sure payments [..] is best modeled as an events-driven domains.
But payments are event-driven in reality. Credit card charges can be disputed, some transactions only succeed after a delay, or transactions or refunds you thought were successful turn out to actually have failed. Some payment methods are more susceptible than others, but even credit cards are affected by some of this.
The point is, stuff will happen to your payments without you initiating the change, and out of your control. Like, you know, events. Now you will need to become aware of them, and either you keep polling updates for a lot of your payments to catch the one that changed, or you have the information pushed to you.
Webhooks are great for that.
(Edited because a word was missing.)
Cards don't really need webhooks (unless you get into 3ds). Other payment types may need webhooks because they are fundamentally async.
2 replies →
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.
> 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.
Yeah, this isn’t great today. We have been exploring Webhook bundles/groups for common integration shapes that make a bit easier to make the right choices based on what you’re doing and hope to have something out here to help soon.
1 reply →
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?
1 reply →
[dead]
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
Calling it a payment processor is a bit of an issue. The term "payment processor" has a very specific meaning in the world of online payments, and this isn't it.
This is a frontend for Stripe, so it's even a bit of a stretch to call it a Payment Service Provider. Payment gateway maybe, but really it's a Stripe frontend.
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
1 reply →
Only stripe?
I misunderstood this at first, it looks like the SDK & code is open source but all the billing data is sent to Flowglad servers so you don't 'own' your data?
Yeah exactly, it's a very misleading title in every dimension.
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.
5 replies →
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.
1 reply →
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).
4 replies →
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
Literally describes one company I work for periodically.
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.
14 replies →
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.
6 replies →
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.
1 reply →
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?
2 replies →
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.
6 replies →
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.
2 replies →
So, this is somehow similar to Polar (https://polar.sh/)
You can make it even easier
And serverless
Just have the client redirect to your checkout flow, and it redirects back with a signed payload. Like oauth. Done.
Make an HTTP interface that’s easy to curl, as well as a Javascript library to assemble the request and verify the result.
Client JS can handle own postbacks. Maybe not even to their own domain.
Or maybe client server will read that querystring in the resulting request and verify signature.
Totally up to the customer.
Finally, have the sdk also have an option to load an iframe (eg in a dialog) instead of redirect, and use postMessage for securely sending signed result. Just make sure to use Intersection Observer v2 in that case https://web.dev/articles/intersectionobserver-v2
DONE
PS: Hire me ;-)
While you do the banking side, I can integrate a ton of web3-enabled stuff for you including invoices across blockchains, recurring subscriptions, as well as contests and auctions for price discovery. See https://intercoin.org/applications
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
UX (from a dev standpoint) : I want to know if it works in France. I click on "which countries are supported". It reveals a link to the docs instead of a countries list. OK, I click the link. I'm in the "getting started" section with no obvious link to the countries list.
I gave up there and probably won't come back.
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.
or maybe you dont abstract it away, let each payment api behave the way their service supports, add some common functions on top that users can use and for specific functions they always look for specific classes. Ex class Gateway { abstract function send(), abtstract function receive() } class Visa extends Gateway { send()...receive()..., otherVisaSupportedFunctions() } class MasterCard extends Gateway { ....}
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.
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.
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.
We eat all the webhook pain so you don’t have to. Much of our code is dealing with complex state transitions triggered webhooks. We just avail you the end result.
Instead of having to implement all that yourself, you just read the latest billing and entitlement state for each of your customers from Flowglad:
const billing = flowglad(user.id).getBilling()
const hasFastGen = billing.checkFeatureAccess(‘fast_generations’)
Oh I see, you're still running a server, the open source bit is just your SDK. I thought your entire system was open source and didn't understand how you could trigger workflows without webhooks. Makes more sense now, thanks!
What are you using to manage your workflows on your backend?
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.
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?
This is why we committed to getting deeper into the payment processing side. Yes, we can service this with our current arrangement because we are not a merchant of record. When you process payments with us, you are the settlement merchant.
When we begin our merchant of record offering, you will not be able to use it to sell human services. That’s not a Stripe regulation but has to do with the merchant of record offering and the compliance posture you need to build for that service.
Polar is built on Stripe, and so is Flowglad so it's safe to assume that they prohibit exactly the same things.
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
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?
I've been an early user. Big fan of what Agree and team have managed to build here.
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.
Quick feedback from a Stripe and Braintree customer, who wrote their own subscription system so as not to use Stripe Billing. The things that caused me problems in the past:
* inflexible subscription system
* unreliable web component for gathering credit card information
* unreliable 3DSecure implementation
* incompetent support (these four are the main reasons why I switched from Braintree to Stripe)
* complex and untestable flows for non-mainstream payment types (e.g. SEPA direct debit, IDEAL, etc — Stripe makes you think they will just work, while you need to implement complex logic in your system to make them work)
* PCI compliance (Braintree hires SecureMetrics, they audit everyone even if you are below PCI thresholds, and the audits are idiotic; they complain about ssh version numbers on Ubuntu LTS systems which have all current security patches, etc)
* US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid)
* lack of B2B subscription billing using proforma invoices
Things that would worry me looking towards the future if I were to switch a payment processor now:
* pricing (this matters in spite of what HN often says)
* lock-in (Stripe Billing was free, then 0.5% of revenue, then 1% of revenue, what's next?)
* reliability of 3DSecure, as problems here are extremely difficult to debug and easy to blame on "customer's bank"
You might note that this list contains mostly non-technical items.
But overall I'm very happy to see competition in this field. Payment processing is in a sad state and there are not nearly enough companies doing this.
> US-centric thinking about invoicing, which makes invoicing unusable (I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid)
This sounds strange. I don't think there's anything US-centric about considering an invoice to be a payment request — which makes issuing them after payment nonsensical.
> invoice to be a payment request — which makes issuing them after payment nonsensical
Most EU countries use an accrual-based VAT system, where taxes are owed on any invoice issued, paid or unpaid.
This makes issuing them before payment nonsensical, because you will end up paying taxes on invoices that will never be paid, thus ruining your business.
A proforma invoice exists specifically for the purposes of quoting and requesting payment.
1 reply →
That doesn't match what I see. Shops don't issue an invoice until the product ships, well after payment.
Could you elaborate on inflexible subscription system and also what you would like to see from a 3DSecure implementation?
Full disclosure: I'm a dev at a fintech startup and we're currently working on these two things so I'm curious how our direction lines up with your thoughts
> inflexible subscription system
For example, Braintree can't switch from monthly to annual billing (or the other way around). You have to delete the subscription and recreate it with a different billing period.
I want my customers to be able to switch plans, billing periods, currency, and buy additional items (user slots), all with proration.
> what you would like to see from a 3DSecure implementation
I would like not to see anything, really. I want to forget 3DSecure even exists. Stripe largely gets this right. Braintree required me to do many rather bizarre things, pass additional data, and then rewrite the entire flow once every couple of years or so. With the last rewrite, I was told that in my case (SaaS subscriptions) I would need to drag the customer through 3DSecure TWICE and that there is no other way. So I switched to Stripe, because I value my customers' time.
Also, 3DSecure with braintree would fail every once in a while and I would get customers from various countries telling me they are unable to subscribe. Braintree support, after a week or two, would inquire and either tell me it's the customer's bank (not helpful), or tell me that I have to rewrite my integration to a New Way of Doing Things, which was usually so far off the mark for my use case it wasn't even funny. I just checked my E-mail archives quickly for "Braintree support", over the years I'm up to around ~400 E-mails exchanged.
> I issue invoices only after a successful payment, because I owe tax on all invoices including unpaid
(IANA I am not an accountant) but how is it legal? as a customer you want to pay against an invoice, and AFAIK it is required by law in most places.
You pay against a proforma invoice, or if your credit card gets charged automatically, there is no proforma and you just get an invoice that confirms the transaction.
But in general, this is why proforma invoices exist.
This feels like adding a skyscraper of abstraction layers between my app and the stripe api… maybe i got old but wow wtf
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 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
Definitely solving a real problem!
GNU Taler already exists and was built by actual experts.
https://www.taler.net/en/
Copy pasting the front page:
> We provide a payment system that makes privacy-friendly online transactions fast and
> Payments without registration
> Data protection by default
> Fraud eliminated by design
> Not a new currency!
> Empowers communities to run their own payment infrastructure
> Free Software
imho this is a non-starter for mass market payments.
let's say a customer has found your website and wants to buy something. they first have to install a third party wallet app, fund the wallet by buying coins thru an exchange, then use the app to make a payment to the merchant.
it's the same UX problem crypto has tried (and failed) to work around, but with extra friction since it still depends on local currencies and has an unnecessarily obtuse deposit fees formula that emulates physical coins.
Unless I'm missing something, this is a complete nonsense comment.
Obviously you have to install the app, that's true for any app. But you only have to do it the first time around.
Are you just saying that this payment app has the first time friction of downloading the app. That's the same for all apps. Are you just saying that friction exists, and is a barrier to entry?
1 reply →
Zero webhooks is a bit optimistic over the longer term, surely?
Payments are getting slightly more asynchronous, not less.
'Not writing a single line of code'... so the code cursor wrote doesn't count?
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?
1 reply →
I have created OpenSpend recently but still very early stages.
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
Any plans on building the Stripe Connect features?
Why would I use this when polar.sh exists?
Seems like just another entry into this space. Also, you should probably change the title of this post because this isn't a payment processor, you are not processing payments in any way at all. You're just a middleman with a UI, and a nice UI can be good, but it's not more than 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
LLM generated Javascript to process payments sounds insane. No need to create stuff just because it's possible.
give the product a go and lmk how vibe coding payments performs
so stoked for this! excited to build on top of flowglad
what would look like a Blazor integration?
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
> 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)
4 replies →
That's Stripe's transaction fee, not theirs
When Stripe entered, people stopped caring about the cost of payment processing. I don't work in the industry anymore, but Stripe became rather popular at the time where I worked on online payments. We looked at it, because the Stripe API and services are really nice, but the cost is just insane.
We where never even close to 2.9% on credit cards, and we'd certainly never consider paying 30¢. Part of that is working out of the EU, that caps your credit card fee, so around 1% and 0.10EUR per transaction is closer to the standard. Then you can start negotiating lower raters from there, depending on the number of transaction you make.
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
1 reply →
Standard.
so I can replace Stripe?
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.
4 replies →
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.
[under-the-rug stub]
[see https://news.ycombinator.com/item?id=45988611 for explanation]
I care about my own developer experience. If i can save a headache and some time integrating payments, I'm all for it.
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?
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?
3 replies →