Show HN: We built an open source, zero webhooks payment processor (github.com)
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!
56 comments
[ 5.1 ms ] story [ 65.3 ms ] threadYou don’t need to listen for all event types if you aren’t using _every_ Stripe feature.
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.
Very expensive!
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.
It makes it very clear, and easy to understand.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3
What differentiates you from competitors like Lago and Autumn?
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.
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.
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?
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.
- 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!
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.
Recharge Payments looks cool, also seems more focused on Shopify stores?
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’)
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
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!
How can any of this work without dealing with credit card payment processors
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?