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 event lifecycles to your app db's ground truth
- internal revenue reporting would also get annoying, as your revenue charts would be split across multiple processors. You could see them in one dashboard via your accounting software (usually clunky and user hostile ime) or you'd need to start tracking payments in your DB so you could include it in your metrics
What's frustrating is that right now when you use a payment provider, you get everything in a bundle: their flow of funds and their developer experience. Solving this is one of the big problems on our roadmap. Because yeah, you're absolutely right. You should be able to route payments flows dynamically based on what's best for the situation.
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 SDK, but aren't locked in to our hosting.
> I don't understand how your service can even help with this. "Features" are necessarily part of my app, I have to define what the user is purchasing.
We let you define features that you reference using slugs that you decide, and then group those features with products. So when someone subscribes to the product, they get the features you defined and associated with that product. So to see whether they can access a feature (boolean):
The problem we're trying to address is a bit broader than just storing price ids. You use your customers' payments state to derive billing state, and you use billing state to derive app behavior (what features they can access, what usage meters what balances and whether those are sufficient to continue consumption). You need this data on your backend and your frontend. So a substantial amount of most CRUD app code is just managing, transposing, and shuttling this kinda of data around between backend and frontend.
For fun I once mapped out a vanilla SaaS checkout flow and realized that it required a developer to coordinate 15 server-client boundary hops [0]. Each one is a liability that you have to maintain. And the flow as a whole is one of the most frustrating to test. If a developer came up with this flow on their own, we'd immediately say it smells. But it's the flow required by the current best-in-class vendors.
And it's not entirely the result of complexity intrinsic to the domain. Much of it is the result of decisions made over a decade ago that haven't really been revisited. At least in React-land, we've learned a lot in that time about how gracefully different patterns for state management age in a codebase. The last time the webhook-only pattern was the frontier of DX, Redux was the considered the best state management framework for React.
I haven't seen Redux in React code in a very long time, maybe 6 years. Not because Redux is terrible - in fact it represented the community's best understanding of state management at the time. But over time we realized the limitations of Redux as a framework, and engineered our way out of them with new frameworks. This process is natural and beautiful and part of what makes technology magical. In payments, this improvement loop is significantly rate limited. Because to build a truly better solution you have to commit to all of the uphill compliance and financial services work that people have very astutely pointed out in other comments.
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.
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.
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!
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.
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.
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.
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:
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.
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, React hooks to manage your state. We want to build something you pick to build with on Day 1 - rather than something your boss tells you that you have to use.
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.
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.
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.
What's frustrating is that right now when you use a payment provider, you get everything in a bundle: their flow of funds and their developer experience. Solving this is one of the big problems on our roadmap. Because yeah, you're absolutely right. You should be able to route payments flows dynamically based on what's best for the situation.
[0] https://flowglad.com