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 /it/docs/mobile/revenuecat.md (or send Accept: text/markdown).
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.
Creare l'account e il progetto RevenueCat
1. Apri 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 → 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 → 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=<the exact Authorization value set on the webhook>
REVENUECAT_ENTITLEMENT_ID=pro
REVENUECAT_ENTITLEMENT_KEY=ai.reference-taskVerificare 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.
Per continuare la configurazione, leggi Build e verifica su dispositivo.