Comment by codegeek
4 days ago
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?
1 reply →
The benefit is that our hooks get entitlement data directly to your frontend. Stripe Elements just focus on payments forms. But what about how payments state impacts what features or usage credits you grant? Stripe doesn’t handle that; they leave that as a concern for your business logic to figure out. The result is glue code you need to write to keep your application database up to date with the ground truth in your processor. Usually through brittle, messy webhooks code.
With Flowglad’s hooks and server SDK, we get that data to your frontend and backend. So you can read it from us wherever you need it.
>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.
2 replies →