Revenipe Integration in Flutter: The Complete 2026 Guide

What happens after a user pays? For most Flutter apps, that is where the real bugs hide.

A subscriber upgrades from monthly to yearly, and your app still shows the old plan. Someone burns through their AI credits, but the paywall never fires. A trial expires on a Sunday, and nobody notices until Monday. Anyone who has shipped a monetized Flutter app knows this quiet panic. The feature work was the easy part. The billing layer is where the real time goes.

That is the exact gap Revenipe integration is built to close. Revenipe is a billing and entitlement platform that sits between your Flutter app and providers like Stripe and RevenueCat. You get subscriptions, one-time payments, trials, add-ons, and usage limits without rebuilding the same backend for the third time.

At CueBytes, we ship subscription Flutter apps for a living. So this guide is written from the builder's seat, not the brochure. Below you will find the full integration path, the SDK calls that matter, the dashboard setup, and the early-version quirks to watch for. Everything here is grounded in the official Revenipe documentation, checked live in June 2026.

Executive summary: what you will actually learn

This guide takes you from zero to a working Revenipe integration in a Flutter app. You will create an app, connect a billing provider, configure products, and read customer access through the SDK. No fluff, no guessing.

Here is what you walk away with. First, a clear model of how Revenipe layers between your app and Stripe or RevenueCat. Second, the exact Flutter SDK calls for configure, login, fetch products, start purchase, check entitlements, and track usage. Third, the dashboard side, including the restricted Stripe key and the RevenueCat webhook. Fourth, the three entitlement types and when each one fits. Fifth, the failure points we see most often, including the single mistake that silently leaks revenue.

One important note on scope. The Revenipe Flutter SDK is early. The published package sits at version 0.0.1 at the time of writing. Method signatures can shift between releases. We flag every spot where the live docs show more than one form, so you verify against the current pub.dev listing before you ship. Treat this as a working map, not a frozen spec.

If you would rather hand the whole thing off, our Revenipe integration service does exactly that. But you can absolutely do this yourself. Let us get into it.

What is Revenipe, and why does it matter for Flutter apps?

Revenipe is a billing and entitlement platform for app developers. It handles subscriptions, one-time payments, add-ons, trials, and usage limits, so your app checks access instead of rebuilding payment logic. Your Flutter app talks to the Revenipe SDK, and Revenipe talks to Stripe or RevenueCat behind the scenes.

Billing always looks simpler than it is. A real app has to handle plan changes, failed payments, cancellations, renewals, webhook events, and provider-specific edge cases. Build that once and you understand why teams dread touching it again.

Revenipe reduces that load by owning the access layer. You define products in a dashboard. Each product grants entitlements. Your app then asks one question: does this customer have access right now. That single shift, from tracking payment state to checking entitlements, is what makes the model clean.

For Flutter teams the appeal is sharper. One SDK covers both web-style payments through Stripe and native store purchases through RevenueCat. You stop writing two billing stacks. You can read how we approach monetized builds on our Flutter app development page.

How does Revenipe integration actually work?

Revenipe sits between your app and your billing providers. Your Flutter app uses the SDK to fetch products, start purchases, check entitlements, and track usage. Revenipe handles the backend logic and provider webhooks, then returns a clean customer access state your app can trust.

The flow is a simple chain. Your app calls the Revenipe SDK. The SDK talks to Revenipe Core. Revenipe Core talks to Stripe or RevenueCat. Events flow back up the same chain and land as entitlements your app reads.

Your app
   ↓
Revenipe SDK
   ↓
Revenipe Core
   ↓
Stripe / RevenueCat

Learn this vocabulary before you write any code. These five terms appear everywhere in the dashboard and the SDK.

Get these five clear in your head. The rest of the integration is wiring them together.

What do you need before you start a Revenipe integration?

Before you begin, you need a Revenipe account, a billing provider account such as Stripe, a Flutter app, and your Revenipe public key from the dashboard. To test real purchases, create at least one product, attach entitlements, and connect a provider first.

Skipping the setup checklist is where most first attempts stall. You try to fetch products and get an empty list, because none exist yet. You call login and nothing attaches, because no customer flow is ready.

So do the boring part first. Create your app in the Revenipe dashboard. Connect Stripe or RevenueCat. Create one product with one entitlement. Grab your public key. Now the SDK calls have something to return.

A word on keys that we will repeat, because it matters. Your Flutter app should only ever carry the public Revenipe key. Stripe restricted keys, RevenueCat private keys, and webhook secrets stay on the backend, always.

How do you connect Stripe to Revenipe?

Connect Stripe by creating a restricted Stripe API key with the permissions Revenipe needs, then pasting it into the Stripe integration screen in your Revenipe app. Use a test-mode key for sandbox and a live-mode key for production. A restricted key is safer than a full secret key.

Stripe is one of the providers Revenipe uses to process payments, subscriptions, trials, add-ons, and one-time purchases. The setup happens entirely in the dashboard, not in your app code.

Open your Stripe Dashboard and go to API keys. Create a new restricted key. Restricted keys usually start with rk_test_ in test mode and rk_live_ in live mode. You can paste a full secret key and it will work, but the restricted key is the recommended, safer path.

Grant Revenipe these permissions on the restricted key. Each one needs Write access, which also includes read for the same resource.

Copy the key value the moment Stripe shows it. Stripe reveals a restricted key only once. Paste it into the Stripe integration screen in Revenipe and click Connect. Then create a product, attach entitlements, and run a sandbox test purchase to confirm the connection.

One security rule, stated plainly. Never share Stripe keys in Discord, GitHub, screenshots, or support tickets. A leaked key is a real incident, not a minor slip.

How does Revenipe integration work with RevenueCat?

For App Store and Google Play purchases, RevenueCat handles the native flow. Revenipe listens to RevenueCat webhook events and turns them into entitlements. You start the purchase with the RevenueCat SDK, then refresh the Revenipe customer state to read the updated access.

This pairing is the heart of the migration story. Many Flutter teams already use RevenueCat for store purchases. Revenipe layers entitlements, credits, and usage limits on top, without ripping out what works.

The event chain runs like this.

App Store / Google Play
   ↓
RevenueCat purchase
   ↓
RevenueCat webhook
   ↓
Revenipe access + entitlements
   ↓
Flutter app

Setup is a webhook handshake. In the Revenipe dashboard, open App Settings, then Connect RevenueCat, and copy the webhook endpoint. In RevenueCat, go to Project settings, Integrations, then Webhooks, and paste that URL. Leave the optional authorization field empty, because the URL already carries the Revenipe webhook secret. Send a test event, return to Revenipe, and click Check Connection.

Match your product IDs carefully. Use the same App Store and Google Play identifiers in both RevenueCat and Revenipe. A mismatch here means purchases that never resolve into access.

How do you install the Revenipe Flutter SDK?

Add the Revenipe Flutter SDK by including revenipe_flutter in your pubspec dependencies, then run pub get. The current published version is 0.0.1. Import the package and you are ready to configure it with your public key.

You have two ways to add the package. The fast one uses the command line.

flutter pub add revenipe_flutter

Or you add it directly to your pubspec.yaml.

dependencies:
  revenipe_flutter: ^0.0.1

Then import it where your billing logic lives.

import 'package:revenipe_flutter/revenipe_flutter.dart';

That is the whole install. Because the package is at 0.0.1, pin your version and read the changelog before you bump it. Early SDKs move fast, and a minor jump can rename a method.

How do you configure Revenipe in your app?

Configure the SDK once, early in your app lifecycle, before any other Revenipe call. Pass your public key from the dashboard. Run it inside main after ensureInitialized, so the SDK is ready before your first login, product fetch, or entitlement check.

The dedicated configuration docs use a config object with your public app ID.

final revenipe = Revenipe.instance;

await revenipe.configure(
  config: const RevenipeConfig(
    appId: 'app_your_public_app_id',
  ),
);

Place it at startup so nothing runs before configuration finishes.

Future<void> main() async {
  WidgetsFlutterBinding.ensureInitialized();

  final revenipe = Revenipe.instance;

  await revenipe.configure(
    config: const RevenipeConfig(
      appId: 'app_your_public_app_id',
    ),
  );

  runApp(const MyApp());
}

Use your sandbox public key while building and testing. Switch to the production key only when products, providers, purchase flows, and entitlement checks are ready for real customers. Never mix sandbox and production keys in the same build.

Now the first quirk to flag honestly. The install guide shows a shorter form, Revenipe.configure(appKey: 'your_app_key'), while the dedicated configure page uses the RevenipeConfig object above. Both appear in the current docs. This is a classic early-SDK signal. Use whichever form your installed package exposes, and confirm against the version you pinned. Do not trust a blog post for this, including ours. Check the package.

How do you log in a customer?

Log in a customer before you fetch products, start purchases, or check access. For registered users, pass a stable ID from your own auth system. For guests, use anonymous login. Revenipe uses the ID to attach every purchase, trial, and entitlement to the right person.

Registered login takes one line.

await Revenipe.instance.login('customer_123');

For users without an account yet, use anonymous login. This suits guest usage, onboarding, and trials.

await Revenipe.instance.anonymLogin();

The most important decision is the ID you choose for registered users. Use a stable identifier from your own system. The docs are explicit about good and bad choices.

Use the same customer ID across sessions. If the ID changes, Revenipe treats the user as a different customer, and their purchases seem to vanish. That single mistake causes the dreaded "I paid but lost my subscription" ticket.

How do you create and fetch products?

Create products in the Revenipe dashboard with a product type and a stable unique identifier, then attach entitlements. In your app, call getProducts after login to fetch the active products for the current environment, and render them on your paywall.

Products are configured in the dashboard, not in code. A product connects billing configuration to customer access. Revenipe supports four product types.

Each product carries a display name, a unique identifier, an optional description, a billing model, pricing, and its entitlements. Use stable, readable identifiers like pro_monthly or 500_credits_pack, because your code may match on them later. Never rename an identifier after launch.

Fetching products in Flutter is one call after login.

final products = await Revenipe.instance.getProducts();

Then build your pricing UI from the response.

final response = await revenipe.getProducts();

for (final product in response.products) {
  print('${product.name}: ${product.productId}');
}

If a product does not appear in the SDK response, the problem is almost always configuration. Check that the product is active, belongs to the correct app, and has valid provider setup. Confirm the SDK uses the right public key and environment, and that the customer is logged in before the fetch. Empty paywall means dashboard, not code.

What are entitlements, and what types does Revenipe support?

Entitlements define what a customer can access or consume. Products grant entitlements, and your app checks them to unlock features. Revenipe supports three types: flag entitlements for on or off access, value entitlements for renewable limits, and limited value entitlements for fixed credits.

Entitlements separate billing from access logic. The provider handles payments. Revenipe turns provider state into access. Your app checks entitlements instead of reading Stripe or RevenueCat directly.

Flag entitlements answer a yes or no question, like premium_access, support_access, or remove_watermark. Value entitlements grant renewable amounts, like 100 credits every month through monthly_credits. Limited value entitlements cover one-time top-ups, like a 500_credits_pack that does not refill on its own.

A single Pro subscription can grant several entitlements at once, such as premium access, monthly credits, advanced exports, and support access. Your app reads each one through the SDK to decide what to unlock.

How do you start a purchase?

Call startPurchase with the product ID, the customer ID, and a purchase method. For hosted checkout, Revenipe returns a URL you open in a browser. For the payment sheet, it returns the data your app passes to flutter_stripe. For RevenueCat, the RevenueCat SDK handles the purchase.

Revenipe supports three purchase methods, depending on your product and provider.

Hosted checkout is the simplest path. Revenipe creates a session and returns a URL.

final response = await revenipe.startPurchase(
  options: MakePurchaseOptions(
    customerId: customer.customerId,
    productId: 'pro_monthly',
    method: RevenipePurchaseMethod.hostedCheckout,
    successUrl: 'myapp://billing/success',
    cancelUrl: 'myapp://billing/cancel',
  ),
);

final checkoutUrl = response.checkout!.checkoutUrl;

Open that URL with url_launcher or an in-app browser. After the customer returns, refresh their state before unlocking anything.

The payment sheet path keeps users inside your app, which usually converts better. Revenipe returns the payment data, and flutter_stripe presents the native sheet.

final response = await revenipe.startPurchase(
  options: MakePurchaseOptions(
    customerId: customer.customerId,
    productId: 'pro_monthly',
    method: RevenipePurchaseMethod.paymentSheet,
  ),
);

final paymentSheet = response.paymentSheet!;

await Stripe.instance.initPaymentSheet(
  paymentSheetParameters: SetupPaymentSheetParameters(
    merchantDisplayName: 'My App',
    customerId: paymentSheet.customerId,
    customerEphemeralKeySecret: paymentSheet.customerEphemeralKeySecret,
    paymentIntentClientSecret: paymentSheet.paymentIntentClientSecret,
  ),
);

await Stripe.instance.presentPaymentSheet();

For RevenueCat products, complete the purchase with the RevenueCat SDK first, then refresh the Revenipe customer state. One rule applies to all three flows. Never unlock a feature because a checkout screen opened. We return to that mistake below, because it matters that much.

How do you check entitlements and unlock features?

Use hasEntitlement for a simple yes or no check, and getEntitlement when you need details like remaining usage. Always refresh the customer state after a purchase before you check, so your app reads the latest access instead of stale data.

The simple check returns a boolean.

if (Revenipe.instance.hasEntitlement('premium_access')) {
  // Show premium feature
} else {
  // Show upgrade prompt
}

When you need numbers, like a credit balance, read the detail instead.

final entitlement = Revenipe.instance.getEntitlement('monthly_credits');

Refreshing is not optional after any state change. Do it before you check.

await Revenipe.instance.refreshEntitlements();

final hasPremium = Revenipe.instance.hasEntitlement('premium_access');

Note a second quirk. The refresh call appears mostly as refreshEntitlements(), but the RevenueCat docs also show refreshCustomer(). Same intent, different name. Check which one your installed version ships and standardize on it. Use stable entitlement IDs that match the dashboard exactly, because your whole feature-gating layer depends on these strings.

How do you track usage with credits and usage keys?

Call track with an entitlement ID or a usage key and the amount to consume. Revenipe returns the updated state. Only reduce usage after Revenipe confirms success, never optimistically. Use a usage key when credits come from several sources that should share one balance.

This is the call for anything metered, like AI generations, exports, or downloads.

final result = await Revenipe.instance.track(
  id: 'monthly_credits',
  value: 1,
);

if (result.success) {
  // Allow the action and update the UI.
} else {
  // Block the action or show an upgrade prompt.
}

The id can be a single entitlement ID or a usage key. Usage keys exist for one reason: a customer can collect credits from several limited value sources, and you want one shared balance. Picture a user who buys a small pack, a large pack, and gets a manual bonus. Without a usage key, your app checks each source separately. With one, it does not.

Now your app tracks against credits, and Revenipe resolves which source to consume.

final result = await Revenipe.instance.track(
  id: 'credits',
  value: 1,
);

Keep usage keys for limited value entitlements only. Do not use them for flag entitlements, renewable value entitlements, or subscription allowances. Name them short and lowercase, like credits, tokens, or ai_generations.

A third honest flag. The track method shows different argument shapes across the docs, including a positional form, id with value, and entitlementId with amount. This is the clearest sign the SDK is still settling. Trust your installed package over any single example, including this one.

What are the most common Revenipe integration mistakes?

The biggest mistake is unlocking access because a checkout screen opened, instead of after Revenipe confirms the access state. Others include unstable customer IDs, shipping secret keys in the client, forgetting to refresh before checking, and reducing usage locally before the server confirms it.

Let us name them plainly, because each one has bitten a real team.

• The revenue leak. A user taps buy, the checkout opens, and your code flips a flag to premium. Then the payment fails or the user backs out. Now you give away the paid tier. Always gate access on the refreshed Revenipe state, never on the act of opening a payment screen.
• The lost subscriber. You keyed the customer on an email or a device ID. The user changes their email or reinstalls, and their purchases disappear from their view. Use a stable internal ID from day one.
• The leaked secret. A Stripe restricted key or webhook secret ends up in the Flutter bundle, where anyone can extract it. Keep secrets on the backend and ship only the public key.
• The stale read. You check entitlements right after a purchase without refreshing. The app shows old access, nothing changes for the user, and a ticket arrives. Refresh first, then check.
• The optimistic credit. You decrement a credit in the local state before Revenipe confirms the track call. Now your balance and the server disagree. Only reduce usage after result.success comes back true.

If working through these feels like more than you want to own, a short conversation can save weeks. You can book a Revenipe integration consult and we will pressure-test your setup.

How long does a Revenipe integration take, and is it worth it over RevenueCat alone?

A basic Revenipe integration in a clean Flutter app can be wired in a few focused days, covering install, configure, login, products, one purchase flow, and entitlement checks. Production-grade work takes longer, because refunds, restores, trials, and cross-provider testing add up.

The happy path is genuinely quick. The SDK surface is small, and the dashboard does the heavy lifting. The real time goes into the unglamorous parts. Restore purchases. Refund handling. Trial-to-paid transitions. Sandbox testing of the RevenueCat webhook. Network failures mid-purchase. This is the gap between "works on my machine" and "works for ten thousand users."

On the question of RevenueCat alone, it is rarely either-or. RevenueCat stays excellent for native store purchases. Revenipe adds a single entitlement and usage layer across Stripe and RevenueCat together, so you ask one access question whether the money came from the web or the App Store.

That edge-case work is what our team does every week. If you want it done right the first time, our Revenipe integration partners handle the full path.

Frequently asked questions

Is Revenipe free to use?

Pricing sits with Revenipe and changes over time, so check their current plans directly. Your costs also include provider fees, like Stripe processing or App Store commission, which are separate from Revenipe itself.

Does Revenipe work with Flutter on both iOS and Android?

Yes. The Revenipe Flutter SDK is built for cross-platform apps. Stripe flows cover web-style billing, and the RevenueCat path covers native App Store and Google Play purchases on both platforms.

Can I use Revenipe with Stripe and RevenueCat at the same time?

Yes, and many apps do. Stripe handles web and card payments. RevenueCat handles native store purchases. Revenipe unifies both into one entitlement layer your app reads through a single SDK.

What is the difference between a product and an entitlement?

A product is what a customer buys, like a Pro subscription. An entitlement is the access that product grants, like premium features or 100 monthly credits. Products grant entitlements, and your app checks entitlements.

What are the three entitlement types?

Flag entitlements unlock a feature, on or off. Value entitlements grant renewable limits, like monthly credits. Limited value entitlements grant fixed amounts that do not renew, like a one-time credit pack.

When do I need a usage key?

Use a usage key when a customer can collect credits from several limited value sources, like multiple packs plus a bonus, and you want one shared balance. For a single credit source, tracking by entitlement ID is enough.

Why does my app show an empty product list?

Almost always, no active products exist for the current environment, or you fetched before login. Confirm the product is active, belongs to the right app, has provider setup, and that configure and login ran first.

How do I keep my integration secure?

Ship only the public Revenipe key. Keep Stripe restricted keys, RevenueCat private keys, and webhook secrets on your backend. Use a restricted Stripe key with only the required permissions, and gate features on refreshed Revenipe state.

Why is the SDK at version 0.0.1, and is it production ready?

The published Flutter SDK is early, so method signatures can change between releases. Pin your version, read the changelog, and test against your installed package. For production launches, build in extra testing time.

Where can I find the official Revenipe documentation?

The source of truth is the official docs at docs.revenipe.com. It covers getting started, the Flutter SDK, Stripe and RevenueCat connections, and core concepts. Always verify code samples there before shipping.

The bottom line on Revenipe integration

Remember that quiet billing panic from the start. The upgrade that did not register. The credits that never gated. The trial that expired unnoticed. A clean Revenipe integration is how those stop being your problem.

The model is the lesson worth keeping. Stop tracking payment state by hand. Define products, grant entitlements, and let your app ask one honest question about access. Connect Stripe for web, RevenueCat for stores, and read it all through one SDK. Refresh before you check, gate on confirmed state, and never trust an opened checkout screen.

The one caution we will repeat. The SDK is young at 0.0.1, so verify every signature against your installed version and the official docs. Build like the spec will move, because right now it will.

If you would rather ship features while someone else owns the billing layer, that is what we do at CueBytes. Our team builds and hardens Revenipe integrations for Flutter apps every week. Start with our Revenipe integration service, or talk to us about your stack on the contact page.