agreeahmed

7 ms·

1.
by agreeahmed 9mo ago
Builder of an open source payments provider [0]. You could dynamically switch payments providers based on the situation, but as of today: - you would have to integrate into multiple providers' APIs and then maintain mappings of their e
2.
by agreeahmed 10mo ago
We're using trigger.dev for processing workflows and we really love the product (and team)
3.
by agreeahmed 10mo ago
The "storing my source of truth externally" is super fair, and something we plan to address soon by giving you the ability to store this data on your side. So you'll still get all the benefits of our data model and full stack
4.
by agreeahmed 10mo ago
Appreciate the feedback. This work happens in all frontend "cultures" (a phrase I will be lovingly borrowing, thank you). But a payment provider can't really take this work off a developer's plate unless it provides an S
5.
by agreeahmed 10mo ago
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 shoul
6.
by agreeahmed 10mo ago
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).
7.
by agreeahmed 10mo ago
Exactly. If you’re too committed to framework agnosticism you end up leaving your users a bunch of last mile work that they have to do with every integration, and maintain through every pricing model change.
8.
by agreeahmed 10mo ago
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 curren
9.
by agreeahmed 10mo ago
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 fir
10.
by agreeahmed 10mo ago
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
11.
by agreeahmed 10mo ago
We eat all the webhook pain so you don’t have to. Much of our code is dealing with complex state transitions triggered webhooks. We just avail you the end result. Instead of having to implement all that yourself, you just read the latest bi
12.
by agreeahmed 10mo ago
This is why we committed to getting deeper into the payment processing side. Yes, we can service this with our current arrangement because we are not a merchant of record. When you process payments with us, you are the settlement merchant.
13.
by agreeahmed 10mo ago
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
14.
by agreeahmed 10mo ago
There are a few billing engines that have shipped entitlement management offerings. We’re focused on making the best DX for managing entitlements as possible. A lot of that comes down to details: cloning pricing models across environments,
15.
by agreeahmed 10mo ago
Not in the immediate term at least. Our initial focus is deliver an amazing experience for software builders.
16.
by agreeahmed 10mo ago
We built our own billing engine so the total cost to you is .65% (on top of the normal 2.9%). By comparison Stripe Billing costs .70%
17.
by agreeahmed 10mo ago
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains. In a perfect world money would trade h
18.
by agreeahmed 10mo ago
That’s a devilish engineering question. If you are truly framework agnostic you limit how much work you can do for your users, because a lot of the work happens inside of the framework. We decided we’d commit to doing the work so our cust
19.
by agreeahmed 10mo ago
With Flowglad you’d pay ever so slightly less than you would with a vanilla Stripe integration which usually includes Stripe Billing. That total cost is 3.6% (2.9% per charge + .7% for billing) and $.30, whereas we’re 3.55%. We’re not reall
20.
by agreeahmed 10mo ago
That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that
21.
by agreeahmed 10mo ago
Totally. When you look at the history of payments processing usually new entrants start with a significant technical improvement and then quickly graduate into learning how to pricing new types of risk
22.
by agreeahmed 10mo ago
You should be able to access it via the “Set Up” tab in your navigation bar. It’s step 3 “verify and enable live payments” - we’ll clear up that copy, thank you for flagging!
23.
by agreeahmed 10mo ago
Thank you! That’s exactly what we saw after speaking with a bunch of devs. They wanted to iterate on pricing as they all figure out how to price their AI products. It turns out that the architectural changes that make that easier also make
24.
by agreeahmed 10mo ago
Under the hood we are using Stripe to process the payments, but you set up a Stripe sub account through our platform using Stripe Connect
25.
by agreeahmed 10mo ago
No that’s the total cost to you. This isn’t a BYOK setup, you create a Stripe account through us using Stripe Connect
26.
by agreeahmed 10mo ago
This isn't quite a boilerplate to start your own payment processor - but an open source payments provider which you does the entire job to be done: handling the flow of both money and value inside your app. And yes, for now your coding
27.
by agreeahmed 10mo ago
Yes, while this is OSS, we haven't yet figured out how to self host an acquiring bank partnership... For now we're using Stripe Connect to set up a merchant account through our Stripe Connect platform. So as long as you are a lega
28.
by agreeahmed 10mo ago
Exactly. One of our advisors who previously an exec at one of the card networks says that currently we are technically a "value-added gateway reseller". Doesn't exactly roll off the tongue, but that's the most precise wa
29.
by agreeahmed 10mo ago
Unless I'm misunderstanding, I think you might have gotten sides mixed up? Issuing side ( the side that "issues" the cards) is usually the one that people describe as "all of the value", while acquiring ( the side t
30.
by agreeahmed 10mo ago
As the Javascript ecosystem has spilled out from just the frontend to also the backend, a lot of these React devs have found fullstack responsibilities on their shoulders. Imo you can trace a lot of how devtools, particularly webdev tools,

More ›