Comment by nkmnz
3 days ago
I don't get why you're calling it A) a "payment processor", even though you don't process any payment yourselves, and B) "open source", even though it's running everything through your SaaS and presumably also storing data in your databases (not speaking about telemetry but real business data). I struggle a lot with building a more flexible system for feature gates, usage credits, payment schemes etc., so I 100% understand the pain point you're addressing, but I don't feel like you're delivering much on your headline.
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.
Oh I did not realize the whole „SaaS“ is open source, too! To be honest, the „payment processor“ part primed me in a way that I didn’t even investigate about the backend, I assumed it to be closed source due to that. Thank you for the clarification!
About the „processor“: IANAL, but I would assume that a payment processor has liabilities and regulations similar to that of a bank - line it’s the case for PayPal or Stripe. On the other hand, no one would raise a concern of you were forwarding transactions to Visa or some huge bank, so this is probably just a communication issue that you might want to tackle upfront.
Yes, we have similar compliance things we consider to Stripe and PayPal. We believe the best experience will only need one onboarding, which would mean we need to process the payments (even if we use Stripe under the hood to do so for now). That’s why we decided not to build a BYOK flow.
This thread has been eye opening for revealing how much more clearly we could be explaining the funds flow story. Thank you for your feedback!
Could you elaborate on how hard it is to use a different payments provider? I use Clover API with my bank being the acquirer, which is much cheaper than Stripe.
Very interesting. How do you handle billing with that setup? Are there billing SaaSes that will integrate with that set up, or did you have to build your own?
Since we’re the payments provider (using Stripe under the hood), we’re not currently able to support “bring your own provider” unfortunately.
2 replies →
The license file states MIT and AGPL licences
For the library that links to their SaaS, not for their entire product.
The SaaS is open source too, it’s AGPLv3.
Pasting the full root license file below: — Flowglad is fully open source.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3