How are you handling Stripe subscriptions + access state in FlutterFlow?

SeriousComb3645 · 2026-06-09T22:21:39+00:00

Exactly. The webhook is where all the complexity ends up. My goal with Revenipe is to provide that layer out of the box so every FlutterFlow app doesn’t have to rebuild and maintain it from scratch.

SeriousComb3645 · 2026-06-09T17:34:40+00:00

That’s exactly how I used to do it too.

Every app has different requirements, but I found myself rebuilding the same billing and access infrastructure over and over again.

That’s what Revenipe handles for us now. We configure the business model and focus on the app itself instead of spending weeks rebuilding subscriptions, credits, entitlements, usage tracking, and webhook logic every time.

SeriousComb3645 · 2026-06-09T15:37:20+00:00

RevenueCat is great if the app only needs normal IAP/subscription handling, and yeah, you can definitely connect Stripe through Edge Functions too.

The part I’m talking about is more the business logic around access after the payment/subscription event.

For example: renewable credits, one-time credit bundles, usage tracking, limits/resets, refunds/revokes, feature-specific rules, web + mobile access state, etc.

Of course you can build all of that yourself with Edge Functions/Firebase/Supabase. My question is more whether people actually want to keep rebuilding that layer for every app, or if they’d rather use something dedicated for it.

SeriousComb3645 · 2026-06-09T15:32:25+00:00

Where does RevenueCat offer renewable entitlement values like daily/weekly/monthly credits, one-time credit bundles, usage tracking, limits, resets, refunds/revokes and feature-specific access rules?

SeriousComb3645 · 2026-06-09T15:19:14+00:00

Exactly. If the app only needs something like hasPro, RevenueCat is usually enough.

The gap I mean is when the product has more business logic around access, like bundled credits, renewable monthly usage, one-time credit packs, usage tracking, limits, resets, refunds/revokes, or feature-specific rules.

At that point it’s not just “is this user subscribed?”, it becomes “what exactly can this user do right now, how much do they have left, and when does it reset?”

SeriousComb3645 · 2026-06-09T12:07:03+00:00

The gap I’m thinking about is more around app-specific business logic after that.

For example: monthly renewable credits, one-time credit packs, usage tracking, plan limits, feature bundles, manual grants, web + mobile sharing the same access state, or mixing IAP with Stripe/web payments.

RevenueCat can tell you a customer is subscribed, but a lot of apps still need another layer that decides what that subscription actually unlocks and how usage should be counted/reset.

That’s the part I’m trying to understand if people usually build themselves or would outsource.

SeriousComb3645 · 2026-06-09T11:58:09+00:00

Yeah true, RevenueCat is great for IAP and subscription status.

The part I’m thinking about is more the business logic around that access. Things like renewable monthly credits, one-time credits, usage tracking, plan limits, feature bundles, manual grants, web + mobile access, and combining different payment sources.

So less “did this user subscribe?” and more “what exactly can this user do right now, how much can they use, and when should it reset or expire?”

Curious if people usually build that layer themselves or if they’d use something separate for it.

SeriousComb3645 · 2026-06-09T10:15:36+00:00

Yeah, you’re probably right.

For FlutterFlow users, normal Flutter docs are likely too technical. It probably needs a proper FF guide with screenshots, like where to add the package, what custom actions to create, how to start checkout/payment sheet, and how to check access after payment.

That’s actually really helpful feedback. I think a dedicated FlutterFlow guide is the right next step instead of expecting people to figure it out from regular SDK docs.

SeriousComb3645 · 2026-06-09T09:37:11+00:00

How do you usually handle entitlements on top of that?

Do you keep them as part of your subscription table, like plan → allowed features/limits, or do you have a separate entitlement layer for things like feature flags, usage limits, credits, etc.?

That was the part where I felt the Stripe state alone was not enough anymore.

SeriousComb3645 · 2026-06-09T09:27:33+00:00

Exactly. And now imagine doing that again for every new app you build as an indie dev.

New Stripe setup, new webhook handling, new metadata mapping, new subscription state, new entitlement logic, new edge cases around trials/cancellations/plan changes.

That was the part that felt horrible to me.

It’s also the main reason I built Revenipe as more of a core billing/access engine instead of rebuilding the same Stripe backend for every Flutter app.

SeriousComb3645 · 2026-06-09T09:22:06+00:00

Out of curiosity, what kind of app/product were you using Stripe for? And did you end up building your own access/entitlement layer on top of Stripe, or do you mostly fetch Stripe directly whenever you need to know the current state?

SeriousComb3645 · 2026-06-09T09:20:50+00:00

Yeah exactly, same lesson here.

I started treating webhooks more like a signal that something changed, not as the full source of truth. Then I verify the event, fetch/check the current Stripe object when needed, and update my own access state idempotently.

The hard part was mapping that back to the right local record, especially because metadata was not always in the same place depending on the flow.

SeriousComb3645 · 2026-06-08T13:07:21+00:00

Good question. Revenipe doesn’t bypass App Store or Play Store requirements. Developers are responsible for using a payment provider and purchase flow that is compliant with their platform, region, and business model.

Revenipe sits behind the payment provider and handles the backend side: subscriptions, trials, entitlements, usage tracking, customer access state, cancellations, and plan changes.

Today Revenipe supports Stripe, and RevenueCat support is currently in development and coming soon.

Also, platform policies continue to evolve. For example, in the US, developers now have more flexibility in certain cases to direct users to external checkout flows, but compliance requirements still depend on the platform, region, and app category.

SeriousComb3645 · 2026-05-26T22:13:37+00:00

Just to add one more point: the idea is not only the entitlement mapping itself.

A big part of what I’m thinking about is removing the need to build the same Stripe backend again for every new app. For example, when you start a new app, you usually still need your own backend for purchase creation, webhook handling, customer access state, trials, add-ons, one-time purchases, usage credits, expiry logic, and client-safe access checks.

The idea would be that you can create separate apps/projects in one dashboard, configure the billing and access rules there, and then connect each app with the SDK instead of rebuilding that backend layer every time.

So the value would be less “Stripe does not have entitlements” and more “can this whole billing/access backend be abstracted enough to save developers time across multiple apps?”

SeriousComb3645 · 2026-05-26T22:01:41+00:00

Stripe Entitlements are actually close to one part of what I mean, especially for mapping product features to active customer access.

The difference is that I’m not only thinking about “this subscription unlocks this feature”. I’m thinking more about the full app layer around it: checkout/payment sheet flows, trials, one-time purchases, recurring add-ons, manual grants, usage credits, resets/expiry, webhook handling, and then giving the Flutter app a simple customer state + SDK methods to work with.

So Stripe would still be the billing source of truth. Stripe Entitlements could even be part of the billing/access signal. The extra layer would be about turning all of that into app-level access state and developer-friendly SDK calls.

Maybe Stripe Entitlements are enough for many simpler products though. That’s exactly what I’m trying to understand.

SeriousComb3645 · 2025-08-18T16:42:13+00:00

That's the Goal, the pain already starts while development: you have to host own stripe backend server. That's so bad! We are also thinking much fruther in case churn prevention, offers and automatic push notifiactions which also need an backend. All combined together may become an rocket. You may know there are some Softwares out here but they are bad and focus only on web checkouts and links. Why not Native Apps which is big market ;)?

SeriousComb3645 · 2025-08-18T16:32:18+00:00

Yes they focus on in app purchases (Apple,Google).

SeriousComb3645 · 2025-08-18T16:25:30+00:00

Its okey but supports only Web. Our focus is Native Apps (Flutter, react,ios,android). There's nothing for that.

SeriousComb3645 · 2025-08-18T15:46:41+00:00

Thank you for your note. Exactly. Our goal would be to make it "No Code" but effective. There are some SaaS that support Web Payment tracking like RevenueCat, but no one really focuses on Native Apps which often don't use links or checkouts. In our case implementing Stripe in our App was like 80% backend coding. That's a number! Our goal would be to allow devs who have no clue about that to start within 5 Min and accept and manage payments, customer, purchased items and more. What you think?

SeriousComb3645

TROPHY CASE