151–160 of 230 posts
Earlier quoted context omitted.
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
how much fee do you take
Earlier quoted context omitted.
> pretty much every Stripe integration uses Stripe Billing Isn't Stripe Billing only for subscriptions?
Stripe Billing handles subscriptions and usage based billing now. Most software products fall in one of those two categories, or sometimes both. As a result, most software companies are paying more than 2.9% + $0.30 for Stripe, closer to 3.6% + $.30. To only pay Stripe 2.9% + $.30 they'd need to only use Stripe just for charges, and either build their own billing engine (usually poor use of time) or use a 3rd party S…
As we approach Black Friday in the US, I'm thinking of the giant volume of e-commerce transactions that are not subscriptions (or usage-based), and of which Stripe gets a cut. It sounds like you are not angling for that part of the market?
Earlier quoted context omitted.
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.
> it's granting entitlements
This is what Chargebee is doing[1]. I believe Zuora is another big company operating in the space.
Earlier quoted context omitted.
Stripe Billing handles subscriptions and usage based billing now. Most software products fall in one of those two categories, or sometimes both. As a result, most software companies are paying more than 2.9% + $0.30 for Stripe, closer to 3.6% + $.30. To only pay Stripe 2.9% + $.30 they'd need to only use Stripe just for charges, and either build their own billing engine (usually poor use of time) or use a 3rd party S…
Ahhh so this is mainly for subscription software companies? That also did not come across. As we approach Black Friday in the US, I'm thinking of the giant volume of e-commerce transactions that are not subscriptions (or usage-based), and of which Stripe gets a cut. It sounds like you are not angling for that part of the market?
[see https://news.ycombinator.com/item?id=45988611 for explanation]
Earlier quoted context omitted.
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/
We’re focused on making the best DX for managing entitlements as possible. A lot of that comes down to details: cloning pricing models across environments, React hooks to manage your state. We want to build something you pick to build with on Day 1 - rather than something your boss tells you that you have to use.
Earlier quoted context omitted.
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?
With Flowglad’s hooks and server SDK, we get that data to your frontend and backend. So you can read it from us wherever you need it.
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
Webhooks are absolutely the right tool for async / background jobs, or events driven domains. I’m not sure payments, and its flip side of entitlements, is best modeled as an events-driven domains. 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…
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?
When we begin our merchant of record offering, you will not be able to use it to sell human services. That’s not a Stripe regulation but has to do with the merchant of record offering and the compliance posture you need to build for that service.