Comment by baobabKoodaa
4 days ago
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.
4 days ago
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.
Pretty much my 1st question when I see a new billing product. Thank you for answering that. I don't understand why products like these hide that fact or keep it hidden. A great product that requires connecting a payment processor can still be a great product but it is not an actual payment processor and that part needs to be clear immediately on your landing page.
It's probably because "we built our castle inside Stripe's kingdom" doesn't sound very cool.
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.
Their website says fully opensource and since it’s a Stripe wrapper, this seems to be an opensource alternative to Stripe Elements. It does require a Flowgrad account and key so it will provide value if other payment processors started using it.
Is there any benefit to using Flowgrad’s react components and hooks over Stripe elements directly?
3 replies →
>However, if enough people start using this then they might become the new gatekeepers
Stripe would likely change their ToS and then revoke their API keys before they could get anywhere near that level of dominance.
They hide it because you won't choose them if you were aware that it's Yet Another Wrapper around someone else's service.
This is great feedback. We aren't trying to keep it hidden at all. But we could be clearer in how we communicate it.
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.
All good. You know HN feedback is straight and brutal but we are all trying to be helpful.
It’s not very well hidden, it took me around 15s to figure it out from the main page. They are also trying to diversify (obviously).
The landing also doesn't clearly answer if they use their own stripe or we need to connect our own stripe account.
3 replies →
I’ve been in software long enough to know that there’s a market for products that make things slightly easier for devs and their managers who think even common APIs like stripe are too hard. The number of devs who are struggling with web hooks and simultaneously have some budget to spend is probably bigger than you think.
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.
Definitely - it's the nature of software that it tends towards higher order abstractions that make the tools easier and easier to use. The final frontier is English as a programming language. The tools that are easiest to program in English (via a coding agent that "compiles down" your prompt into code) tend to have the tersest APIs, with the least amount of reasoning about state across service boundaries.
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
Literally describes one company I work for periodically.
I'm sorry, but seeing the words "dev" and "struggling with webhooks" in the same sentence makes me cringe.
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.
I had the pleasure of working with teams that couldn’t even figure out how to use analytics in their product. They had zero idea who was using it and how many people were using it. They ignored the thousands of DB deadlock messages in the logs; well, they just ignored the logs completely, actually. All they cared about was shipping the next feature and getting the one QA guy to agree it was working correctly so the ticket could be closed.
This is much more common than you might think.
3 replies →
There's a lot of React devs out there who have never touched a server-side anything.
6 replies →
Even the best developer in the world can struggle when there are like 250 webhook events on a platform (as is the case for Stripe).
Webhooks are not a struggle conceptually. They are a struggle operationally IMO.
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.
1 reply →
For now, yes. The game plan over time is to get deeper into the actual card rails side of things. But first we really want to nail the developer experience.
You can't standardize the developer experience across different processors. I'm not trying to be negative here, just practical.
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.
> 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.
5 replies →
That's fine, but it does mean that your current submission title is factually incorrect. You didn't build a payment processor, you build a payment gateway.
You intend to restrict this to a single market? There's some sibling comments that do point out that.
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.
100% agree - this is not a space to tread into lightly.
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.
The DX of Stripe is already great—it sounds like you want to give Stripe reasonable defaults. Not a bad idea, but if you know what you're doing, you can have AI read the Stripe docs and implement something based on established patterns. Who is your ICP?
> The DX of Stripe is already great
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
Today our ideal customer is someone starting a project on day one who wants an easy pathway to 1) get stood up ASAP, and 2) start iterating on pricing as they learn what customers really care about. What we found when talking with dozens of builders was that the DX is indeed much better than e.g. Adyen, Braintree, etc. But their DX is far from the counterpart best in class devtools in auth, hosting, or databases.
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.
Who cares about developer experience? Genuinely asking, because I’m a developer too and I certainly don’t care. What we care about is solving the actual problem of payments with the downstream companies.
DX = developers not shooting themselves in the foot and making it impossible to cancel my free trial because my account got deleted but the autopay didn't
fewers bugs = happier customers not getting charged for shit they didn't agree to be charged for
2 replies →
Stripe became dominant by improving developer experience, which cuts implementation costs.
“Well your payments platform doesn’t actually do payments, but the developer experience of doing nothing was flawless!”
Sorry for the snark, but been in payments a long time, and seen too much of this nonsense.
1 reply →
It looks like this is more akin to a React-only Chargebee where entitlements etc. are stored with the billing provider.
(Apologies if I am misreading the site.)
It scans that way right now because Stripe is more visibly involved in the onboarding process. Maybe another way to parse it is "Shopify for software", where we combine the movement of money and subsequent state transitions involved in unlocking value. But instead of shipping physical items, it's granting entitlements.
Either way, thank you for the feedback. We're still refining how we explain it.
> we combine the movement of money and subsequent state transitions involved in unlocking value
> it's granting entitlements
This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space.
1 - https://www.chargebee.com/entitlement-management/
1 reply →
So, this is somehow similar to Polar (https://polar.sh/)