191–200 of 230 posts
Earlier quoted context omitted.
Cards don't really need webhooks (unless you get into 3ds). Other payment types may need webhooks because they are fundamentally async.
3DS is a big deal in Europe, and card payments can be disputed. So I'd argue that credit cards are async, too, at least on some edges that can be expensive to ignore.
Copy pasting the front page:
> We provide a payment system that makes privacy-friendly online transactions fast and
> Payments without registration
> Data protection by default
> Fraud eliminated by design
> Not a new currency!
> Empowers communities to run their own payment infrastructure
> Free Software
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% unde…
It looks like this does make some things easier , but I'm not sure if it's actually better . 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 ca…
Yeah this very true. We have a plan to allow you to store more of this data on the merchant's side and still benefit from the work we've done to refine our data model, and make the SDK super usable. Even if you do hit Stripe's APIs, you will need to maintain mappings of price ids to your plans, your plans to what features you grant for each, stripe customer ids to your customer ids, etc. That's the kind of grunt work…
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% unde…
The license file states MIT and AGPL licences
Earlier quoted context omitted.
The license file states MIT and AGPL licences
For the library that links to their SaaS, not for their entire product.
Pasting the full root license file below: — Flowglad is fully open source.
- ./packages: MIT
- ./playground: MIT
- ./platform: AGPLv3
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% unde…
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.
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% unde…
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…
Earlier quoted context omitted.
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…
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.
Since we’re the payments provider (using Stripe under the hood), we’re not currently able to support “bring your own provider” unfortunately.