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 SDK that works inside of that culture. So yeah, we hope to ship the best payments experience for React. But eventually also for Svelte and Vue. Because that's what you'd have to do to solve this problem.
And the problem goes substantially beyond billing UI. There's all the unseen tedium that devs need to implement in order to derive proper app behavior based on their customers' billing state. Most of this work is transposing billing state (and its derivatives) and then lugging it to the client where it will be used to show upgrade buttons, gate feature access, show outstanding usage balances, etc.
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.
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 billing and entitlement state for each of your customers from Flowglad:
Oh I see, you're still running a server, the open source bit is just your SDK. I thought your entire system was open source and didn't understand how you could trigger workflows without webhooks. Makes more sense now, thanks!
What are you using to manage your workflows on your backend?
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.
When we begin our merchant of record offering, you will not be able to use it to sell human services. That’s not a Stripe regulation but has to do with the merchant of record offering and the compliance posture you need to build for that service.
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 leave that as a concern for your business logic to figure out. The result is glue code you need to write to keep your application database up to date with the ground truth in your processor. Usually through brittle, messy webhooks code.
With Flowglad’s hooks and server SDK, we get that data to your frontend and backend. So you can read it from us wherever you need it.
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 hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify has webhooks but they are not the primary load bearing site of payment integration for most storefronts.
Payments webhooks were, from what I can tell in the history, a hack for side stepping gnarly problems in domain modeling and read optimization.
> I’m not sure payments [..] is best modeled as an events-driven domains.
But payments are event-driven in reality. Credit card charges can be disputed, some transactions only succeed after a delay, or transactions or refunds you thought were successful turn out to actually have failed. Some payment methods are more susceptible than others, but even credit cards are affected by some of this.
The point is, stuff will happen to your payments without you initiating the change, and out of your control. Like, you know, events. Now you will need to become aware of them, and either you keep polling updates for a lot of your payments to catch the one that changed, or you have the information pushed to you.
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.
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 really trying to compete on cost. But we certainly aren’t more expensive once you include the cost of Stripe Billing.
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 our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
You should look at using Preact (4kb alternative) and supply your frontend code as fully encapsulated with embedded preact. That way you client would only have to render your widget/app into an existing DOM element:
Appreciate the response. I suppose the follow up is, why not make the library framework agnostic initially or work towards that, rather than have to maintain support for x number of frameworks into the future?
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 customers didn’t have to.
E.g. most web apps have some endpoint that the client calls to initiate a checkout session by calling their payment processor’s server SDK.
How many times has the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration.
If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.
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.
May I suggest web components? For all their warts, they are perfect for a use case like this. Even React, the IE of frameworks, supports them properly in v19.
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
And the problem goes substantially beyond billing UI. There's all the unseen tedium that devs need to implement in order to derive proper app behavior based on their customers' billing state. Most of this work is transposing billing state (and its derivatives) and then lugging it to the client where it will be used to show upgrade buttons, gate feature access, show outstanding usage balances, etc.
reply