Aller au contenu
supastack
Parcourir la documentation
WebNext.js

For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/mobile/revenuecat.md (or send Accept: text/markdown).

Configurer les achats RevenueCat

Créez un projet RevenueCat, liez vos produits App Store et Play, et branchez les clés SDK plus les secrets serveur qui vérifient les achats.

Poser une question sur ce guide
Ouvrir dans

Parcours pas à pas pour débuter

Pourquoi cela existe : Apple et Google exigent que les achats numériques dans une app passent par leur propre facturation — jamais par Stripe Checkout — et le kit fait respecter cette limite. RevenueCat se place au-dessus des deux stores pour qu'une seule intégration couvre iOS et Android : il suit les reçus, les abonnements et les restaurations, et votre serveur demande à RevenueCat si un workspace a payé.

Prérequis : les comptes Apple Developer Program (99 $ par an) et Google Play Console (25 $ une fois) du guide des comptes mobiles — les produits de store doivent exister avant que RevenueCat puisse les lier — plus un build de développement EAS pour tester réellement, car Expo Go ne peut pas exécuter du tout le module natif d'achats. Le niveau gratuit de RevenueCat couvre les tests ; rien de tout cela ne vous facture avant que les produits soient en production.

Quelques termes : un projet RevenueCat contient vos apps liées aux stores. Les produits sont les articles de store reflétés dans RevenueCat. Un entitlement est le flag que RevenueCat accorde tant qu'un abonnement est actif — pro par défaut. Un offering regroupe des produits dans le paywall que l'app présente. Les clés SDK publiques vont dans l'env mobile ; une secret API key et l'autorisation du webhook restent côté serveur.

Ce que vous créez : un projet, deux apps liées aux stores, des produits, un entitlement, un offering — environ une heure, surtout à attendre la configuration des produits de store.

Créer le compte et le projet RevenueCat

1. Ouvrez app.revenuecat.com → Sign up et créez un projet portant le nom de votre produit.

Attendu : un tableau de bord de projet vide avec des onglets pour Apps, Products, Entitlements, Offerings et API keys — les sections suivantes les remplissent dans l'ordre.

Créer les produits de store, puis lier les deux apps

Les produits côté store doivent exister avant que RevenueCat puisse les référencer. iOS : appstoreconnect.apple.com → My Apps → créez la fiche de l'app avec votre ios.bundleIdentifier → In-App Purchases ou Subscriptions → créez les produits d'abonnement que vous comptez vendre (ils peuvent rester en brouillon pendant vos tests). Android : play.google.com/console → créez l'app → Monetize → Products → Subscriptions (ou produits in-app).

Puis liez les deux dans RevenueCat : Apps → New app. Pour iOS, choisissez App Store, saisissez le bundle id et fournissez les identifiants App Store Connect que le formulaire demande — il lie la documentation de configuration de RevenueCat pour chaque champ. Pour Android, choisissez Play Store, saisissez le package name et uploadez le JSON de compte de service Play — la documentation liée guide sa création dans Google Cloud.

Attendu : les deux apps listées sous le projet, et les consoles des stores montrent vos produits existants — l'état de brouillon convient à ce stade.

Produits, entitlement, offering

1. Products → New : créez un produit RevenueCat par produit de store et attachez l'id de produit App Store ou Play correspondant — les ids doivent correspondre exactement à ceux des consoles.

2. Entitlements → New : nommez-le pour correspondre à REVENUECAT_ENTITLEMENT_ID — le défaut du kit est pro — et attachez les produits qui l'accordent.

3. Offerings → New : créez un offering, ajoutez des packages qui pointent vers vos produits et marquez-le Current — l'app lit offerings.current quand elle rend le paywall.

Laissez REVENUECAT_ENTITLEMENT_KEY à sa valeur par défaut ai.reference-task : c'est la clé de registre interne du kit — la même clé qu'accordent les plans web livrés — et l'accès RevenueCat est écrit sous elle. Ne la renommez que lorsque la clé de plan de votre produit change.

Copier les clés et enregistrer le webhook

Project → API keys liste les trois types ci-dessous. Les clés SDK publiques par plateforme (appl_… pour iOS, goog_… pour Android) vont dans apps/mobile/.env.local — elles identifient l'app, ne portent aucun pouvoir de dépense, et le préfixe EXPO_PUBLIC_ est correct pour elles.

La secret API key (sk_…, la clé v1) et l'autorisation du webhook restent côté serveur dans apps/web/.env.local — jamais EXPO_PUBLIC_, jamais commitées. Le serveur appelle l'API subscriber de RevenueCat avec la clé secrète pour vérifier l'état d'achat de chaque workspace.

Webhook : RevenueCat → Integrations → Webhooks → définissez l'URL {APP_URL}/api/billing/webhook/revenuecat et une valeur d'en-tête Authorization — n'importe quelle longue chaîne aléatoire que vous inventez — puis mettez exactement la même chaîne dans REVENUECAT_WEBHOOK_AUTHORIZATION. Le kit compare l'en-tête à la lettre et rejette toute autre chose, afin que les renouvellements, résiliations et remboursements atteignent le serveur sans attendre le prochain lancement de l'app.

Les achats sandbox sont acceptés automatiquement hors production ; REVENUECAT_ALLOW_SANDBOX=true dans un env de production est rejeté au démarrage, donc laissez-le non défini une fois en production.

# apps/mobile/.env.local
EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER=revenuecat
EXPO_PUBLIC_REVENUECAT_IOS_API_KEY=appl_…
EXPO_PUBLIC_REVENUECAT_ANDROID_API_KEY=goog_…

# apps/web/.env.local — server side
MOBILE_PURCHASES_PROVIDER=revenuecat
REVENUECAT_SECRET_API_KEY=sk_…
REVENUECAT_WEBHOOK_AUTHORIZATION=<the exact Authorization value set on the webhook>
REVENUECAT_ENTITLEMENT_ID=pro
REVENUECAT_ENTITLEMENT_KEY=ai.reference-task

Vérifier avec un achat sandbox

Les achats ne tournent que dans un build de développement ou de production — Expo Go n'a pas du tout le module natif, donc cette étape suppose que eas build --profile development a produit un dev client (le guide EAS le construit).

1. Installez le dev build sur un appareil ou un simulateur connecté à un compte sandbox : App Store Connect → Users and Access → Sandbox Testers pour iOS ; Play Console → license testing pour Android.

2. Dans l'app, ouvrez le paywall et achetez avec le compte sandbox. Attendu : l'achat se termine en sandbox — sans débit réel — Restore purchases fonctionne, et l'entitlement du workspace s'affiche actif, enregistré côté serveur sous la clé ai.reference-task.

Échecs fréquents : un paywall vide signifie que l'offering n'est pas Current ou que des produits ne sont pas liés ; un achat sur appareil qui échoue signifie que le produit de store est encore en brouillon ou que le mauvais compte sandbox est connecté ; un entitlement qui ne bascule jamais signifie que MOBILE_PURCHASES_PROVIDER/EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER sont désactivés ou que l'Authorization du webhook ne correspond pas — le tableau de bord de RevenueCat liste le statut de chaque livraison de webhook.

Questions fréquentes

14 questions

Qu'est-ce que supastack ?

supastack est une fondation modulaire pour construire des produits SaaS avec IA. Elle réunit l'infrastructure commune pour que vous puissiez vous concentrer sur les fonctionnalités propres à votre produit.

Prend-il en charge le web et le mobile ?

Oui. supastack inclut des applications Next.js et Expo comme points de départ pour des expériences web et mobile.

Quelle authentification est incluse ?

Better Auth couvre e-mail/mot de passe, OTP et connexion sociale. Les espaces de travail personnels sont provisionnés avec le compte pour que les enregistrements restent délimités dès le premier jour.

Comment l'IA est-elle prise en charge ?

supastack inclut une IA multi-fournisseurs configurable, le suivi d'usage, des budgets, et la prise en charge chiffrée de vos propres clés (BYOK).

Comment les abonnements sont-ils gérés ?

Pour les produits construits sur le kit, la facturation Stripe, les abonnements et les droits d'accès forment la base de l'accès payant. Les secrets fournisseur restent côté serveur.

Où vit le code propre à mon produit ?

Les fonctionnalités propres au produit restent dans un codebase séparé, tandis que le produit configure et intègre les modules de la fondation supastack.

Comment fonctionne la tarification de supastack ?

Le kit est un achat unique avec mises à jour à vie : Un framework à 249 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 349 $) ou Tous les frameworks (Next.js, iOS, Android) à 499 $ (prix de lancement temporaire — 100 $ de réduction par rapport au prix habituel de 599 $), plus 75 $ par siège développeur supplémentaire. Pas d'abonnement au kit. Le paiement sur ce site livre votre clé de licence par e-mail, avec accès au dépôt via invitation GitHub.

Comment les espaces de travail délimitent mes données ?

Les enregistrements appartenant aux utilisateurs sont délimités par workspaceId. Identité, droits d'accès, usage IA, événements de facturation et entrées d'audit restent dans le périmètre de l'espace personnel.

Comment fonctionnent les jobs en arrière-plan ?

Trigger.dev est le runtime de jobs explicite. Le contrat JobRunner ne promet que enqueue, status et cancel — la sémantique de workflow reste propre à Trigger.dev et explicite.

En quoi l'e-mail diffère-t-il de la prospection ?

L'e-mail transactionnel couvre les flux produit comme les avis de fin de tâche. La prospection à froid et les campagnes relèvent du produit, hors du module e-mail de ce kit.

Comment fonctionnent les achats sur mobile ?

Le mobile inclut les achats natifs et leur restauration via RevenueCat, avec un accès vérifié par votre serveur. Configurez les comptes des boutiques et terminez les tests sur appareil avant publication. La facturation web reste séparée.

Où vivent les clés des fournisseurs IA ?

Les identifiants BYOK sont chiffrés et restent côté serveur. Les clés sont masquées dans les journaux ; l'usage et les budgets restent visibles au niveau de l'espace de travail.

Quels moyens de paiement le checkout accepte-t-il ?

Le checkout hébergé par Stripe accepte les cartes et peut aussi proposer Alipay et WeChat Pay une fois ces portefeuilles activés sur le compte Stripe — pratique pour les acheteurs en Chine. Les autorisations de portefeuille se confirment de manière asynchrone : la page de licence se met à jour dès que le paiement est validé.

Puis-je obtenir un remboursement ?

Une fois que vous avez accès au dépôt, supastack vous appartient pour toujours et ne peut donc pas être remboursé. Mais rassurez-vous : vous obtenez le code source complet avec des mises à jour à vie pour créer et déployer un nombre illimité de produits pour vous ou vos clients. Vous ne pouvez simplement pas revendre le code ni redistribuer le dépôt sous forme de kit de démarrage ou de modèle.

FR
Thème