141–150 of 230 posts
As a relatively new developer, I'm curious why the dependancy on React?
Was there no way to get the UI you wanted without implementing a framework like React?
We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
Congratulations on the beta launch, an impressive product we will consider integrating. As a relatively new developer, I'm curious why the dependancy on React? Was there no way to get the UI you wanted without implementing a framework like React? We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
We started with React because that’s what we knew best and the community we were most embedded in.
We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
How does this work in terms of having a merchant bank? Surely you need something else besides this repo right?
You still need to have a payment provider / merchant account, so that part remains the same For all I could see this is no different than any other payment gateway service. Well, it is different in one important way: you'll pay a higher percentage per transaction, since the middle man needs to make money somehow.
We’re not really trying to compete on cost. But we certainly aren’t more expensive once you include the cost of Stripe Billing.
Congratulations on the beta launch, an impressive product we will consider integrating. As a relatively new developer, I'm curious why the dependancy on React? Was there no way to get the UI you wanted without implementing a framework like React? We are Svelte based, so it's frustrating for us to have to drag in React for libraries like this.
That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
Payments are getting slightly more asynchronous, not less.
But who actually processes payment? Is it stipe, bolt or some other payment processor? How can any of this work without dealing with credit card payment processors
Under the hood we are using Stripe to process the payments, but you set up a Stripe sub account through our platform using Stripe Connect
Now I might have to spin up a whole area of infrastructure I may not yet have to track eg usage, subscription tier, cancellations etc
Earlier quoted context omitted.
That’s a great point. We started with React because that’s what we knew best and the community we were most embedded in. We have no dogmatic attachment to React. We hope to support Svelte and Vue soon. We’ll start on that once we feel that our data model and flow are sufficiently nailed down that we feel comfortable committing to porting our SDK to other frontend frameworks.
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?
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 the following code been implemented because no payment processor ships a route handler and a React hook (pardon my React-brainedness)?
Someone has to do the work to get that checkout request from your frontend to your payment provider and then back so you can redirect. In a just world, that your processor’s SDK would handle that work. Otherwise it falls on your plate.
The reason webhooks are popular is because they are easy, reliable and they work. Now I might have to spin up a whole area of infrastructure I may not yet have to track eg usage, subscription tier, cancellations etc
In a perfect world money would trade hands and you’d just see what that meant for the features or value your customers could access accordingly. This is what happens in other domains of online commerce like Shopify. Shopify has webhooks but they are not the primary load bearing site of payment integration for most storefronts.
Payments webhooks were, from what I can tell in the history, a hack for side stepping gnarly problems in domain modeling and read optimization.
Polar prohibits: Human services (custom development, design and consultancy). Is this the case with Flowglad? We have a SaaS with a monthly team seat fee + usage fees, but we also offer a bespoke service where we may bill per hour or bill per project (for work done and delivered inside of the SaaS). So these would be higher ticket. Would you support this?