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.

The license file states MIT and AGPL licences

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

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.

> 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.

I liked it too, reminds me of zed.dev...

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.

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.

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

[dead]

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

Only 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.

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.

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.

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.)

So, this is somehow similar to Polar (https://polar.sh/)

Yeah exactly, it's a very misleading title in every dimension.

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 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

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.

> 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.

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

> 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.

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.

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’)

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 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.

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

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?

Yes, it looks like its using Stripe Connect under the hood. So these guys are just middle men.

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.

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.

No that’s the total cost to you. This isn’t a BYOK setup, you create a Stripe account through us using Stripe Connect

thanks for heads up, fixing

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

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

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.

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¢

Standard.

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

Yep! I would love for somebody to actually solve that problem.

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