I misunderstood this at first, it looks like the SDK & code is open source but all the billing data is sent to Flowglad servers so you don't 'own' your data?
Show HN: We built an open source, zero webhooks payment processor
201–210 of 230 posts
Re: Show HN: We built an open source, zero webhooks payment processor
#202Why would I use this when polar.sh exists?
Seems like just another entry into this space. Also, you should probably change the title of this post because this isn't a payment processor, you are not processing payments in any way at all. You're just a middleman with a UI, and a nice UI can be good, but it's not more than that.
Re: Show HN: We built an open source, zero webhooks payment processor
#203I misunderstood this at first, it looks like the SDK & code is open source but all the billing data is sent to Flowglad servers so you don't 'own' your data?
Yeah exactly, it's a very misleading title in every dimension.
Re: Show HN: We built an open source, zero webhooks payment processor
#204Earlier quoted context omitted.
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…
That means you would need to expose your proprietary code and you will be left with no moat.
All of the code seems to be MIT and AGPLv3. Where is this moat?
Re: Show HN: We built an open source, zero webhooks payment processor
#205Earlier quoted context omitted.
Appreciate the response. I suppose the follow up is, why not make the library framework agnostic initially or work towards that, rather than have to maintain support for x number of frameworks into the future?
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 t…
Yeah, I've run into this many times.
If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration.
If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.
Re: Show HN: We built an open source, zero webhooks payment processor
#206Earlier quoted context omitted.
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 t…
Yeah, I've run into this many times. If you can assume the framework someone is using, you can deliver a powerful, comprehensive integration. If you instead try to build a generic one that anyone can use, then it's both hard for you to build it, and hard for everyone to integrate with it because it's generalized.
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.
Re: Show HN: We built an open source, zero webhooks payment processor
#207I don't get why you're calling it A) a "payment processor", even though you don't process any payment yourselves, and B) "open source", even though it's running everything through your SaaS and presumably also storing data in your databases (not speaking about telemetry but real business data). I struggle a lot with building a more flexible system for feature gates, usage credits, payment schemes etc., so I 100% unde…
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…
Oh I did not realize the whole „SaaS“ is open source, too! To be honest, the „payment processor“ part primed me in a way that I didn’t even investigate about the backend, I assumed it to be closed source due to that. Thank you for the clarification!
About the „processor“: IANAL, but I would assume that a payment processor has liabilities and regulations similar to that of a bank - line it’s the case for PayPal or Stripe. On the other hand, no one would raise a concern of you were forwarding transactions to Visa or some huge bank, so this is probably just a communication issue that you might want to tackle upfront.
Re: Show HN: We built an open source, zero webhooks payment processor
#208GNU Taler already exists and was built by actual experts. https://www.taler.net/en/ Copy pasting the front page: > We provide a payment system that makes privacy-friendly online transactions fast and > Payments without registration > Data protection by default > Fraud eliminated by design > Not a new currency! > Empowers communities to run their own payment infrastructure > Free Software
imho this is a non-starter for mass market payments.
let's say a customer has found your website and wants to buy something. they first have to install a third party wallet app, fund the wallet by buying coins thru an exchange, then use the app to make a payment to the merchant.
it's the same UX problem crypto has tried (and failed) to work around, but with extra friction since it still depends on local currencies and has an unnecessarily obtuse deposit fees formula that emulates physical coins.
Re: Show HN: We built an open source, zero webhooks payment processor
#209Earlier quoted context omitted.
That means you would need to expose your proprietary code and you will be left with no moat.
All of the code seems to be MIT and AGPLv3. Where is this moat?
For any given good solution, there will be a core 20% of prospects with more money than patience and/or capacity who would rather you just do it for them. Their propensity to trust you to do so goes up if they understand how you're going about it.
Re: Show HN: We built an open source, zero webhooks payment processor
#210Earlier quoted context omitted.
> We want to go as "close to the metal" as we realistically could as soon as we could. 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.
Unless I'm misunderstanding, I think you might have gotten sides mixed up? 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…
Nope.
> 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.