> ## 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 # Configura gli acquisti RevenueCat Crea un progetto RevenueCat, collega i tuoi prodotti App Store e Play, e cabla le chiavi SDK più i segreti server che verificano gli acquisti. ## Procedura dettagliata per principianti Perché esiste: Apple e Google richiedono che gli acquisti digitali dentro un'app passino per la loro fatturazione — mai per Stripe Checkout — e il kit fa rispettare quel confine. RevenueCat sta sopra entrambi gli store così un'unica integrazione copre iOS e Android: traccia ricevute, abbonamenti e ripristini, e il tuo server chiede a RevenueCat se un workspace ha pagato. Prerequisiti: gli account Apple Developer Program (99 $ all'anno) e Google Play Console (25 $ una tantum) della guida agli account mobile — i prodotti dello store devono esistere prima che RevenueCat possa collegarli — più un development build EAS per testare davvero, perché Expo Go non può proprio eseguire il modulo nativo degli acquisti. Il piano gratuito di RevenueCat copre i test; niente di tutto questo ti addebita prima che i prodotti siano in produzione. Terminologia rapida: un progetto RevenueCat contiene le tue app collegate agli store. I prodotti sono gli articoli dello store rispecchiati dentro RevenueCat. Un entitlement è il flag che RevenueCat concede mentre un abbonamento è attivo — `pro` di default. Un offering raggruppa i prodotti nel paywall che l'app presenta. Le chiavi SDK pubbliche vanno nell'env mobile; una secret API key e l'autorizzazione del webhook restano lato server. Cosa crei: un progetto, due app collegate agli store, prodotti, un entitlement, un offering — circa un'ora, per lo più ad aspettare la configurazione dei prodotti dello store. [Crea gli account mobile](https://supastack.dev/it/docs/mobile/external-accounts.md) [Compila un client di sviluppo](https://supastack.dev/it/docs/mobile/eas-setup.md) ## Creare l'account e il progetto RevenueCat 1. Apri [app.revenuecat.com](https://app.revenuecat.com) → Sign up e crea un progetto con il nome del tuo prodotto. Atteso: una dashboard di progetto vuota con tab per Apps, Products, Entitlements, Offerings e API keys — le prossime sezioni le riempiono in ordine. ## Creare i prodotti dello store, poi collegare entrambe le app I prodotti lato store devono esistere prima che RevenueCat possa referenziarli. iOS: [appstoreconnect.apple.com](https://appstoreconnect.apple.com) → My Apps → crea la scheda dell'app con il tuo `ios.bundleIdentifier` → In-App Purchases o Subscriptions → crea i prodotti in abbonamento che pensi di vendere (possono restare in bozza mentre testi). Android: [play.google.com/console](https://play.google.com/console) → crea l'app → Monetize → Products → Subscriptions (o prodotti in-app). Poi collegale entrambe dentro RevenueCat: Apps → New app. Per iOS scegli App Store, inserisci il bundle id e fornisci le credenziali App Store Connect che il modulo chiede — rimanda alla documentazione di configurazione di RevenueCat per ogni campo. Per Android scegli Play Store, inserisci il package name e carica il JSON del service account Play — la documentazione collegata guida alla sua creazione in Google Cloud. Atteso: entrambe le app elencate sotto il progetto, e le console degli store mostrano i tuoi prodotti esistenti — lo stato di bozza va bene a questo punto. ## Prodotti, entitlement, offering 1. Products → New: crea un prodotto RevenueCat per ogni prodotto dello store e allega l'id di prodotto App Store o Play corrispondente — gli id devono corrispondere esattamente a quelli delle console. 2. Entitlements → New: chiamalo per corrispondere a `REVENUECAT_ENTITLEMENT_ID` — il default del kit è `pro` — e allega i prodotti che lo concedono. 3. Offerings → New: crea un offering, aggiungi package che puntano ai tuoi prodotti e segnalo come Current — l'app legge `offerings.current` quando renderizza il paywall. Lascia `REVENUECAT_ENTITLEMENT_KEY` al suo default `ai.reference-task`: è la chiave di registro interna del kit — la stessa chiave che concedono i piani web inclusi — e l'accesso RevenueCat viene scritto sotto di essa. Rinominala solo quando cambia la chiave di piano del tuo prodotto. ## Copiare le chiavi e registrare il webhook Project → API keys elenca i tre tipi qui sotto. Le chiavi SDK pubbliche per piattaforma (`appl_…` per iOS, `goog_…` per Android) vanno in `apps/mobile/.env.local` — identificano l'app, non portano alcuna autorità di spesa, e il prefisso `EXPO_PUBLIC_` è corretto per loro. La secret API key (`sk_…`, la chiave v1) e l'autorizzazione del webhook restano lato server in `apps/web/.env.local` — mai `EXPO_PUBLIC_`, mai committate. Il server chiama la subscriber API di RevenueCat con la chiave segreta per verificare lo stato d'acquisto di ogni workspace. Webhook: RevenueCat → Integrations → Webhooks → imposta l'URL `{APP_URL}/api/billing/webhook/revenuecat` e un valore di header Authorization — qualsiasi lunga stringa casuale che inventi — poi metti esattamente la stessa stringa in `REVENUECAT_WEBHOOK_AUTHORIZATION`. Il kit confronta l'header alla lettera e rifiuta qualsiasi altra cosa, così rinnovi, cancellazioni e rimborsi raggiungono il server senza aspettare il prossimo avvio dell'app. Gli acquisti sandbox vengono accettati automaticamente fuori dalla produzione; `REVENUECAT_ALLOW_SANDBOX=true` in un env di produzione viene rifiutato all'avvio, quindi lascialo non impostato una volta in produzione. ``` # 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 ``` ## Verificare con un acquisto sandbox Gli acquisti girano solo dentro un build di sviluppo o di produzione — ad Expo Go manca del tutto il modulo nativo, quindi questo passo assume che `eas build --profile development` abbia prodotto un dev client (la guida EAS lo compila). 1. Installa il dev build su un dispositivo o simulatore collegato a un account sandbox: App Store Connect → Users and Access → Sandbox Testers per iOS; Play Console → license testing per Android. 2. Nell'app apri il paywall e compra con l'account sandbox. Atteso: l'acquisto si completa in sandbox — nessun addebito reale — Restore purchases funziona, e l'entitlement del workspace risulta attivo, registrato lato server sotto la chiave `ai.reference-task`. Fallimenti comuni: un paywall vuoto significa che l'offering non è Current o i prodotti non sono collegati; un acquisto su dispositivo che fallisce significa che il prodotto dello store è ancora in bozza o è collegato l'account sandbox sbagliato; un entitlement che non scatta mai significa che `MOBILE_PURCHASES_PROVIDER`/`EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER` sono spenti o che l'Authorization del webhook non corrisponde — la dashboard di RevenueCat elenca lo stato di ogni consegna del webhook. [Compila e verifica sui dispositivi](https://supastack.dev/it/docs/mobile/builds.md) [Il checkout web usa Stripe invece](https://supastack.dev/it/docs/web/stripe-payments.md) Per continuare la configurazione, leggi [Build e verifica su dispositivo](https://supastack.dev/it/docs/mobile/builds.md). ## Successivo [Build e verifica su dispositivo](https://supastack.dev/it/docs/mobile/builds.md)