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.

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.

(Apologies if I am misreading the site.)

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

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.

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

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.