| ▲ | codegeek 7 hours 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. |
|
| ▲ | amelius 7 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | theturtletalks 5 hours ago | parent | next [-] | | 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? | | |
| ▲ | fn-mote 5 hours ago | parent [-] | | 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? | | |
| ▲ | theturtletalks 5 hours ago | parent [-] | | Ah that is another benefit, using Stripe Elements and Stripe directly, you have to save the subscription ID and other fields in your database. Flowgrad seems to handle this on their side. |
|
| |
| ▲ | bossyTeacher 4 hours ago | parent | prev [-] | | >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. |
|
|
| ▲ | agreeahmed 3 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | codegeek 3 hours ago | parent [-] | | All good. You know HN feedback is straight and brutal but we are all trying to be helpful. |
|
|
| ▲ | Scubabear68 5 hours ago | parent | prev | next [-] |
| They hide it because you won't choose them if you were aware that it's Yet Another Wrapper around someone else's service. |
|
| ▲ | frizlab 5 hours ago | parent | prev [-] |
| 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). |
| |
| ▲ | codegeek 4 hours ago | parent [-] | | The landing also doesn't clearly answer if they use their own stripe or we need to connect our own stripe account. | | |
| ▲ | agreeahmed 3 hours ago | parent [-] | | 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. | | |
|
|
