Configurer les achats RevenueCat

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 les comptes mobiles
• Builder un client de développement

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.

• Builder et vérifier sur des appareils
• Le checkout web utilise Stripe à la place