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?

>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.

All good. You know HN feedback is straight and brutal but we are all trying to be helpful.

The landing also doesn't clearly answer if they use their own stripe or we need to connect our own stripe account.

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.

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.

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).

There's a lot of React devs out there who have never touched a server-side anything.

> 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.

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

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.

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

Stripe became dominant by improving developer experience, which cuts implementation costs.

I care about my own developer experience. If i can save a headache and some time integrating payments, I'm all for it.

“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.