> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # RevenueCat-Käufe einrichten Erstellen Sie ein RevenueCat-Projekt, verknüpfen Sie Ihre App-Store- und Play-Produkte und verdrahten Sie die SDK-Keys plus Server-Secrets, die Käufe verifizieren. ## Schritt-für-Schritt für Einsteiger Warum es das gibt: Apple und Google verlangen, dass digitale Käufe in einer App über ihr eigenes Billing laufen — nie über Stripe Checkout — und das Kit erzwingt diese Grenze. RevenueCat sitzt über beiden Stores, sodass eine Integration iOS und Android abdeckt: Es verfolgt Belege, Abos und Wiederherstellungen, und Ihr Server fragt RevenueCat, ob ein Workspace bezahlt hat. Voraussetzungen: Die Konten Apple Developer Program (99 $ pro Jahr) und Google Play Console (25 $ einmalig) aus dem Mobile-Konten-Guide — Store-Produkte müssen existieren, bevor RevenueCat sie verknüpfen kann — plus ein EAS-Development-Build zum tatsächlichen Testen, denn Expo Go kann das native Kaufmodul gar nicht ausführen. RevenueCats Free Tier deckt das Testen ab; nichts davon kostet Geld, bevor Produkte live sind. Kurze Begriffe: Ein RevenueCat-Projekt hält Ihre store-verknüpften Apps. Produkte sind die Store-Artikel, die in RevenueCat gespiegelt werden. Ein Entitlement ist das Flag, das RevenueCat gewährt, solange ein Abo aktiv ist — standardmäßig `pro`. Ein Offering bündelt Produkte zur Paywall, die die App zeigt. Die öffentlichen SDK-Keys gehen in die Mobile-Env; ein Secret API Key und die Webhook-Authorization bleiben serverseitig. Was Sie erstellen: ein Projekt, zwei store-verknüpfte Apps, Produkte, ein Entitlement, ein Offering — etwa eine Stunde, größtenteils Warten auf das Store-Produkt-Setup. [Die Mobile-Konten erstellen](https://supastack.dev/de/docs/mobile/external-accounts.md) [Einen Development-Client bauen](https://supastack.dev/de/docs/mobile/eas-setup.md) ## Das RevenueCat-Konto und -Projekt erstellen 1. Öffnen Sie [app.revenuecat.com](https://app.revenuecat.com) → Sign up und erstellen Sie ein Projekt mit dem Namen Ihres Produkts. Erwartet: ein leeres Projekt-Dashboard mit Tabs für Apps, Products, Entitlements, Offerings und API keys — die nächsten Abschnitte füllen sie der Reihe nach. ## Die Store-Produkte erstellen, dann beide Apps verknüpfen Store-seitige Produkte müssen existieren, bevor RevenueCat sie referenzieren kann. iOS: [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → My Apps → den App-Eintrag mit Ihrem `ios.bundleIdentifier` erstellen → In-App Purchases oder Subscriptions → die Abo-Produkte anlegen, die Sie verkaufen wollen (sie dürfen während des Testens im Entwurf bleiben). Android: [play.google.com/console](https://play.google.com/console) → die App erstellen → Monetize → Products → Subscriptions (oder In-App-Produkte). Dann beide in RevenueCat verknüpfen: Apps → New app. Für iOS wählen Sie App Store, geben die Bundle-ID ein und liefern die App-Store-Connect-Credentials, die das Formular verlangt — es verlinkt RevenueCats eigene Setup-Doku für jedes Feld. Für Android wählen Sie Play Store, geben den Paketnamen ein und laden das Play-Service-Account-JSON hoch — die verlinkte Doku führt durchs Erstellen in Google Cloud. Erwartet: beide Apps unter dem Projekt gelistet, und die Store-Konsolen zeigen Ihre Produkte als existent — Entwurfsstatus ist in dieser Phase in Ordnung. ## Produkte, Entitlement, Offering 1. Products → New: Erstellen Sie ein RevenueCat-Produkt pro Store-Produkt und hängen Sie die passende App-Store- oder Play-Produkt-ID an — die IDs müssen exakt den Konsolen entsprechen. 2. Entitlements → New: Benennen Sie es passend zu `REVENUECAT_ENTITLEMENT_ID` — der Kit-Standard ist `pro` — und hängen Sie die Produkte an, die es gewähren. 3. Offerings → New: Erstellen Sie ein Offering, fügen Sie Packages hinzu, die auf Ihre Produkte zeigen, und markieren Sie es als Current — die App liest `offerings.current`, wenn sie die Paywall rendert. Lassen Sie `REVENUECAT_ENTITLEMENT_KEY` auf dem Standard `ai.reference-task`: Das ist der interne Ledger-Key des Kits — derselbe Key, den die mitgelieferten Web-Pläne gewähren — und RevenueCat-Zugang wird unter ihm geschrieben. Benennen Sie ihn nur um, wenn sich der Plan-Key Ihres Produkts ändert. ## Die Keys kopieren und den Webhook registrieren Project → API keys listet die drei Arten unten. Die öffentlichen SDK-Keys pro Plattform (`appl_…` für iOS, `goog_…` für Android) gehen in `apps/mobile/.env.local` — sie identifizieren die App, tragen keine Ausgaben-Vollmacht, und das `EXPO_PUBLIC_`-Prefix ist für sie korrekt. Der Secret API Key (`sk_…`, der v1-Key) und die Webhook-Authorization bleiben serverseitig in `apps/web/.env.local` — nie `EXPO_PUBLIC_`, nie committet. Der Server ruft RevenueCats Subscriber-API mit dem Secret Key auf, um den Kaufstatus jedes Workspace zu verifizieren. Webhook: RevenueCat → Integrations → Webhooks → setzen Sie die URL `{APP_URL}/api/billing/webhook/revenuecat` und einen Authorization-Header-Wert — irgendeine lange Zufallszeichenfolge, die Sie erfinden — dann kommt exakt dieselbe Zeichenfolge in `REVENUECAT_WEBHOOK_AUTHORIZATION`. Das Kit vergleicht den Header wörtlich und lehnt alles andere ab, damit Verlängerungen, Kündigungen und Erstattungen den Server erreichen, ohne auf den nächsten App-Start zu warten. Sandbox-Käufe werden außerhalb der Produktion automatisch akzeptiert; `REVENUECAT_ALLOW_SANDBOX=true` in einer Produktions-Env wird beim Start abgelehnt — lassen Sie es nach dem Livegang also ungesetzt. ``` # 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= REVENUECAT_ENTITLEMENT_ID=pro REVENUECAT_ENTITLEMENT_KEY=ai.reference-task ``` ## Mit einem Sandbox-Kauf prüfen Käufe laufen nur in einem Development- oder Production-Build — Expo Go fehlt das native Modul komplett; dieser Schritt setzt also voraus, dass `eas build --profile development` einen Dev-Client erzeugt hat (der EAS-Guide baut ihn). 1. Installieren Sie den Dev-Build auf einem Gerät oder Simulator, das bei einem Sandbox-Konto angemeldet ist: App Store Connect → Users and Access → Sandbox Testers für iOS; Play Console → License testing für Android. 2. Öffnen Sie in der App die Paywall und kaufen Sie mit dem Sandbox-Konto. Erwartet: Der Kauf läuft in Sandbox durch — keine echte Abbuchung — Restore purchases funktioniert, und das Entitlement des Workspace zeigt aktiv, serverseitig unter dem Key `ai.reference-task` gebucht. Typische Fehler: Eine leere Paywall heißt, das Offering ist nicht Current oder Produkte sind unverknüpft; ein scheiternder Geräte-Kauf heißt, das Store-Produkt ist noch im Entwurf oder das falsche Sandbox-Konto ist angemeldet; ein Entitlement, das nie umspringt, heißt, `MOBILE_PURCHASES_PROVIDER`/`EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER` sind aus oder die Webhook-Authorization stimmt nicht überein — RevenueCats Dashboard listet den Status jeder Webhook-Zustellung. [Auf Geräten bauen und prüfen](https://supastack.dev/de/docs/mobile/builds.md) [Web-Checkout nutzt stattdessen Stripe](https://supastack.dev/de/docs/web/stripe-payments.md) Wenn du die Einrichtung fortsetzen möchtest, lies [Build- und Geräteprüfung](https://supastack.dev/de/docs/mobile/builds.md). ## Weiter [Build- und Geräteprüfung](https://supastack.dev/de/docs/mobile/builds.md)