Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: We built an open source, zero webhooks payment processor

github.com

Post reply on HN
Print view View original

71–80 of 230 posts

Re: Show HN: We built an open source, zero webhooks payment processor

#71

Post by agreeahmed »

dperfect wrote: post #50

It looks like this does make some things easier , but I'm not sure if it's actually better . From what I can tell, any time you use this to check something like the customer's subscription state (or anything else payment-related) - either from the front end or the back end - it's going to perform an API request to Flowglad's servers. If you care about responsiveness, I'm not sure that's a good idea. Of course, you ca…

Yeah this very true.

We have a plan to allow you to store more of this data on the merchant's side and still benefit from the work we've done to refine our data model, and make the SDK super usable. Even if you do hit Stripe's APIs, you will need to maintain mappings of price ids to your plans, your plans to what features you grant for each, stripe customer ids to your customer ids, etc. That's the kind of grunt work and maintenance burden we'd like to eliminate.

Plus, Stripe is explicitly designed to be a write-optimized system, and discourages[0] using them as a realtime read layer. We're super early in the journey but that's the problem we want to solve: how can we give software devs the same unified money movement + value movement experience that Shopify has availed to DTC brands for nearly 20 years?

[0] https://docs.stripe.com/rate-limits

Re: Show HN: We built an open source, zero webhooks payment processor

#72

Post by brunosutic »

turnsout wrote: post #39
agreeahmed wrote: post #10

Earlier quoted context omitted.

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.

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

Re: Show HN: We built an open source, zero webhooks payment processor

#73

Post by theturtletalks »

amelius wrote: post #57
codegeek wrote: post #43

Earlier quoted context omitted.

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?

Re: Show HN: We built an open source, zero webhooks payment processor

#74

Post by agreeahmed »

jfyi wrote: post #35
agreeahmed wrote: post #10

Earlier quoted context omitted.

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 s…

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

Re: Show HN: We built an open source, zero webhooks payment processor

#75

Post by ForHackernews »

skwee357 wrote: post #49
Aurornis wrote: post #44

Earlier quoted context omitted.

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 le…

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.

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

Re: Show HN: We built an open source, zero webhooks payment processor

#76

Post by nrhrjrjrjtntbt »

skwee357 wrote: post #49
Aurornis wrote: post #44

Earlier quoted context omitted.

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 le…

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.

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.

Re: Show HN: We built an open source, zero webhooks payment processor

#77

Post by skwee357 »

ForHackernews wrote: post #75
skwee357 wrote: post #49

Earlier quoted context omitted.

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.

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

I feel like fullstack engineer was a BigTech manufactured title designed to save costs compared to hiring two experienced engineers, one in frontend and one in backend, but ended up leaving the fullstack engineers in a limbo state where they are neither good at frontend, nor good at backend, hence they require a bunch of (VC funded) tools to "simplify" their development life.

Re: Show HN: We built an open source, zero webhooks payment processor

#78

Post by agreeahmed »

turnsout wrote: post #39
agreeahmed wrote: post #10

Earlier quoted context omitted.

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.

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?

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.

Re: Show HN: We built an open source, zero webhooks payment processor

#79

Post by jfyi »

agreeahmed wrote: post #74
jfyi wrote: post #35

Earlier quoted context omitted.

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 s…

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

Technically you are a wrapper api, but you are acting as a gateway. Though, if you were to claim to be a gateway you'd need pa-dss/ssf validation and that would cost a good chunk of that yc money, so I understand.

Re: Show HN: We built an open source, zero webhooks payment processor

#80

Post by skwee357 »

nrhrjrjrjtntbt wrote: post #76
skwee357 wrote: post #49

Earlier quoted context omitted.

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.

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.

I think Stipe is one of the best designed APIs I ever had to work with.

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.

Post reply on HN