For those who are wondering, like me, what is this? Is this a new alternative to Stripe? The answer is: no. This is an added layer of abstraction on top of Stripe.
However, if enough people start using this then they might become the new gatekeepers because they could swap Stripe for any other payment processor without the need of the user knowing.
Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
Did I misunderstand something? Or is this about a different angle?
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.
Stripe would likely change their ToS and then revoke their API keys before they could get anywhere near that level of dominance.
Currently you set up a new Stripe Connect account to get started. We tried the "connect existing account" flow and discovered that, maybe due to regulations or Stripe policies, we weren't able to debit the existing accounts.
Our Stripe flow is different from the run of the mill billing SaaS because we're involved in the movement of money (rather than simply using your Stripe key to steer API requests on your behalf).
We know that makes us look a bit like a fish with legs while we grow towards where we want to be.
The processing happens through our Stripe Connect platform, through which you currently have to set up a Stripe account. Over time, these details will be more abstracted away, much like Vercel is reselling AWS under the hood but doesn't require you to hand over AWS keys.
Right now, the reason this feels more like a "wrapper" than Vercel is that we haven't yet built out our own onboarding and KYC flow. We wanted to first deliver an amazing developer experience - something we're still working towards.
Often these products are pitched and sold to non-technical managers, too. The sales team will learn that they can make some sales by promising a non-technical manager that buying this product will actually save them money because it’s easier to use.
I mean, I have nothing against higher level abstractions, but I'd be worried to ship (as a dev) and use (as a customer) a product that was built by someone who does not have deep understanding of what they are doing.
This is much more common than you might think.
I ask them to protect themselves by logging what data they will need to troubleshoot a new feature.
Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs.
It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit.
Days long anxiety-filled shit storms for absolutely no reason.
I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
It’s a sad world.
-- actual (retired) full-stack engineer
The web as a platform shouldn’t be constrained by two arbitrary, isolated boxes, because that’s not how it works. A software developer writing code necessarily has to get involved with stuff running on client and server devices and everything in between them out of sheer necessity, if they even want to understand how modern technology works in this space.
Imo you can trace a lot of how devtools, particularly webdev tools, have evolved to this. They are more React-brained. Specifically they try to take state management responsibilities off their users' plates.
In amy case why does a dev need to understand a (yet another) poor DX complex API (stripe) in addition to the other 20 they need to deal with. What is wrong with taking something off the plate. It is like daying dont use high level languages, use Rust, don't use a library to make http calls roll your own etc.
But to reply to your point, there is no way out of this. You either understand the tools you work with, or you end up vendor locked to tools like vercel/next (the target audience of OPs tool, as it seems), which promise simplification, but end up being their own monsters.
It's very likely at this point that the supermajority of future programmers will have almost no formal computer science education. They'll want tools that don't require a deep understanding of the prior generations' layer of abstraction. That's kinda the world we're preparing for - builders who don't need to be deeply technically involved in the details of their vendors in order to build successful software companies
Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
fewers bugs = happier customers not getting charged for shit they didn't agree to be charged for
It was great fun debugging the twice annual incidents where the API returned a HTTP500 but charged the customer and created the recurring subscription anyway.
Not to forget we had to scream at them for 6 months to implement 3DS2 on top of their Subscriptions API. Turns out we were the only users of it!
You are going to run into things like TSYS closing out batches every three days regardless of what happens.
The handling features for them and their customers thing is going to be a herculean task over even a couple different platforms. Not impossible, but it's big and you would do well to see what's out there before committing to a standard interface. Take a look at https://datacapsystems.com/ to see it done well.
Also, adding another layer like this, you better have an early plan to staff a support desk.
Oh, also, you are gateway, not a processor.
Technically right now we are a value-added payment acceptance reseller. Eventually we'd like to become a payfac. And maybe with the new regulations that came out in Georgia, a chartered merchant acquiring bank. But that's down the road.
You're totally right about standardizing the devex across processors. We want to go as "close to the metal" as we realistically could as soon as we could. That's why we very deliberately built our own billing engine from scratch. We could have gotten to market faster by just mapping onto Stripe Billing, but we would have foregone valuable experience mapping processor lifecycle events to our data model. For a while that's going to be much of the work on our plate, standardizing how we map their lifecycle to ours.
We took the past year basically studying the prior art and developing / testing a data model that we feel is well on its way to describing the general case. I was frankly surprised how long it took to really hammer out the primitives.
Doesn't exactly roll off the tongue, but that's the most precise way to describe us right now. And not necessarily where we will stay.
All of the value in payments is on the top (acquiring payfac side)...all of the value on the issuing side is only made via extremely high volume and requires a ton of tech that just schleps data (no fun). I'd recommend getting this idea out of your head.
Issuing side (the side that "issues" the cards) is usually the one that people describe as "all of the value", while acquiring (the side that "acquires" merchants) usually is that one that needs to bring substantial volumes to market.
For context to anyone not familiar with payments, about 60-70% of the card revenue in a transaction goes to the customer's / issuing side because they are the side that assumes credit risk for the consumer. The merchant's / acquiring side has significantly tighter margins and usually needs substantial volume before it can become an interesting business. One way that entrants on the merchant side of the stack monetize is by bundling value-add software.
E.g. Stripe does this with Billing (+.7%) and Connect (+.25%).
Fwiw I agree that most people will find this tech extremely un-fun. But I'm a "payments rail guy" in the way that others might be "train guys". My inner child lights up at the thought of payment rails. My Substack, Vivid Leaves, is basically a bunch of essays about historical payment systems - some we worked with in Kenya, and others I studied from the USSR. I wrote all this before I had any idea I'd be starting a payments company: https://agree.substack.com
We know it's going to be a schlep, and we're going to have a blast schlepping through it.
* vocab fyis for anyone reading this not familiar with payments.
> Issuing side (the side that "issues" the cards) is usually the one that people describe as "all of the value"
In theory you could argue "all of the value" may be there, but that is locked up across issuing banks and the credit card companies themselves. You basically cannot compete there unless you have some novel way of creating a credit card that isn't Visa, MC or AMEX. There is also a reason banks haven't consolidated on the issuing side because it's an uninteresting business for them, otherwise they would. Hence the credit card side is all about volume and hence all of the value for software providers is on the acquiring side.
> The merchant's / acquiring side has significantly tighter margins and usually needs substantial volume before it can become an interesting business.
You're myopically looking at one part of the acquiring side. Controlling the merchant relationship means theoretically unlimited upside, versus the issuing side that is usually capped by regulated interchange fees or market pressure. There are thousands of providers that sit on top of Stripe (and other similar providers) and charge 4%~7% and capture the residuals (which is a higher BPS than Stripe itself), hence this is where the value is. Stripe et al compete on volume because they themselves get volume discounts on the underlying providers (e.g. if you have a high enough volume Stripe will charge you less than the rack rate...just like everyone else that provides a software gateway). I would argue the economic value created by providers sitting on top of Stripe is greater than the value Stripe generates for themselves.
> My inner child lights up at the thought of payment rails.
Payment rails for Visa/MC/AMEX is very different than your experience with moving money at banks in Kenya/Russia. I've actually seen the tech that runs the rails for payments in the US. If anyone thinks the Paypal dev experience is bad, wait until you see this shit.
This used to be the case back in 2015, but not anymore. The financial compliance is more strict now. You have to charge taxes. EU enforced SCA / 3DS in 2019. All of these are hard to implement (correctly) on their own - almost impossible together.
Source: I run (paid) Ruby on Rails library for Stripe subscriptions integrations. I also do billing audits. Here's an example audit where I pay $30, get ~$2000 https://www.youtube.com/watch?v=YuXp7V4nanU
To be clear, what Stripe has built is a towering accomplishment. But a lot of why innovation in payments DX has been slower than other parts of the stack is that since Stripe, there haven't really been many others who have attempted to tackle the *entire* job to be done.
Much "annoyances" when it comes to money is all those weird laws and rules from lower level companies in place, improving things for developers is a laudable goal but I do hope that you guys have some real world experience with these systems apart from frustrations as system users because doing a good DX right now feels like it could make you end up in a dead end.
We have some really knowledgeable payments people in our corner, including several veterans with many decades of payments industry experience as leaders at the big payments players. There's a lot that we've been able to learn from them as they help us navigate the financial services side of this business. We're conscious of how much work there is to do, and how the "good DX" is really just the visible tip of the iceberg.
Currently through Stripe we are able to onboard merchants wherever Stripe can serve them directly. Our upcoming merchant of record offering (which we hope to launch soon), will be available to merchants wherever Stripe can send payouts, which is a longer list of maybe 150+ countries.
The pathway to building deeper payment rails will indeed have to be country-by-country as each one requires new banking partners and compliance regimes.
(Apologies if I am misreading the site.)
Either way, thank you for the feedback. We're still refining how we explain it.
> it's granting entitlements
This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space.
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.