Hacker News Reader

Comment by nkmnz | Hacker News Reader

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.

View on HN

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.

My bank is an acquiring bank. They are also local so I far prefer having a direct face to face relationship with them.

They use Clover’s platform to provide devices and APIs (you could in theory use another vendor’s devices if you really wanted to).

In general, I don’t want someone else to be my payments provider since we do a lot of subscriptions, which would leave me completely locked in to a provider. Already been there done that with PayPal.

If you want to have a direct relationship with your acquiring bank then yours would is a pretty optimal flow.

For folks who just want to get set up and get going quickly and don't mind working with a payfac to do so, we feel they should have more options, especially when it comes to DX.

I'd actually be an ideal customer of yours.

I want to have a consistent developer experience and a flexible platform regardless of which payment provider I'm using. I might also be offering a service to other people who want to "plug in" their own choice of payment providers.

Right now, I have to build all the subscription stuff myself.

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

Reply on news.ycombinator.com