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 /es/docs/mobile/revenuecat.md (or send Accept: text/markdown).
Configurar las compras de RevenueCat
Crea un proyecto de RevenueCat, vincula tus productos de App Store y Play, y conecta las claves SDK más los secretos de servidor que verifican las compras.
Guía paso a paso para principiantes
Por qué existe esto: Apple y Google exigen que las compras digitales dentro de una app pasen por su propia facturación — nunca por Stripe Checkout — y el kit hace cumplir ese límite. RevenueCat se sitúa sobre ambas tiendas para que una sola integración cubra iOS y Android: sigue recibos, suscripciones y restauraciones, y tu servidor le pregunta a RevenueCat si un workspace pagó.
Prerrequisitos: las cuentas de Apple Developer Program (99 $ al año) y Google Play Console (25 $ una vez) de la guía de cuentas móviles — los productos de tienda deben existir antes de que RevenueCat pueda vincularlos — más un build de desarrollo de EAS para probar de verdad, porque Expo Go no puede ejecutar en absoluto el módulo nativo de compras. El nivel gratuito de RevenueCat cubre las pruebas; nada de esto te cobra antes de que los productos estén en vivo.
Términos rápidos: un proyecto de RevenueCat contiene tus apps vinculadas a tiendas. Los productos son los artículos de tienda reflejados dentro de RevenueCat. Un entitlement es el flag que RevenueCat concede mientras una suscripción está activa — pro por defecto. Un offering agrupa productos en el paywall que la app presenta. Las claves SDK públicas van en el env móvil; una secret API key y la autorización del webhook quedan en el servidor.
Lo que creas: un proyecto, dos apps vinculadas a tiendas, productos, un entitlement, un offering — alrededor de una hora, en su mayoría esperando la configuración de los productos de tienda.
Crear la cuenta y el proyecto de RevenueCat
1. Abre app.revenuecat.com → Sign up y crea un proyecto con el nombre de tu producto.
Esperado: un panel de proyecto vacío con pestañas para Apps, Products, Entitlements, Offerings y API keys — las siguientes secciones las rellenan en orden.
Crear los productos de tienda y luego vincular ambas apps
Los productos del lado de la tienda deben existir antes de que RevenueCat pueda referenciarlos. iOS: appstoreconnect.apple.com → My Apps → crea el registro de la app con tu ios.bundleIdentifier → In-App Purchases o Subscriptions → crea los productos de suscripción que piensas vender (pueden quedar en borrador mientras pruebas). Android: play.google.com/console → crea la app → Monetize → Products → Subscriptions (o productos in-app).
Luego vincula ambas dentro de RevenueCat: Apps → New app. Para iOS elige App Store, introduce el bundle id y suministra las credenciales de App Store Connect que pide el formulario — enlaza la documentación de configuración propia de RevenueCat para cada campo. Para Android elige Play Store, introduce el package name y sube el JSON de cuenta de servicio de Play — la documentación enlazada explica cómo crearlo en Google Cloud.
Esperado: ambas apps listadas bajo el proyecto, y las consolas de las tiendas muestran tus productos existentes — el estado de borrador está bien en esta fase.
Productos, entitlement, offering
1. Products → New: crea un producto de RevenueCat por producto de tienda y adjunta el id de producto de App Store o Play correspondiente — los ids deben coincidir exactamente con los de las consolas.
2. Entitlements → New: nómbralo para que coincida con REVENUECAT_ENTITLEMENT_ID — el predeterminado del kit es pro — y adjunta los productos que lo conceden.
3. Offerings → New: crea un offering, añade packages que apunten a tus productos y márcalo como Current — la app lee offerings.current al renderizar el paywall.
Deja REVENUECAT_ENTITLEMENT_KEY en su valor por defecto ai.reference-task: esa es la clave de libro mayor interna del kit — la misma clave que conceden los planes web incluidos — y el acceso de RevenueCat se escribe bajo ella. Renómbrala solo cuando cambie la clave de plan de tu producto.
Copiar las claves y registrar el webhook
Project → API keys lista los tres tipos de abajo. Las claves SDK públicas por plataforma (appl_… para iOS, goog_… para Android) van en apps/mobile/.env.local — identifican la app, no llevan autoridad de gasto, y el prefijo EXPO_PUBLIC_ es correcto para ellas.
La secret API key (sk_…, la clave v1) y la autorización del webhook son solo de servidor en apps/web/.env.local — nunca EXPO_PUBLIC_, nunca commiteadas. El servidor llama a la API de suscriptores de RevenueCat con la clave secreta para verificar el estado de compra de cada workspace.
Webhook: RevenueCat → Integrations → Webhooks → pon la URL {APP_URL}/api/billing/webhook/revenuecat y un valor de cabecera Authorization — cualquier cadena aleatoria larga que inventes — y luego pon exactamente la misma cadena en REVENUECAT_WEBHOOK_AUTHORIZATION. El kit compara la cabecera literalmente y rechaza cualquier otra cosa, así que las renovaciones, cancelaciones y reembolsos llegan al servidor sin esperar al próximo arranque de la app.
Las compras sandbox se aceptan automáticamente fuera de producción; REVENUECAT_ALLOW_SANDBOX=true en un env de producción se rechaza al arrancar, así que déjalo sin configurar una vez en vivo.
# 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-taskVerificar con una compra sandbox
Las compras solo corren dentro de un build de desarrollo o de producción — a Expo Go le falta por completo el módulo nativo, así que este paso asume que eas build --profile development produjo un dev client (la guía de EAS lo compila).
1. Instala el dev build en un dispositivo o simulador con sesión iniciada en una cuenta sandbox: App Store Connect → Users and Access → Sandbox Testers para iOS; Play Console → license testing para Android.
2. En la app abre el paywall y compra con la cuenta sandbox. Esperado: la compra se completa en sandbox — sin cargo real — Restore purchases funciona, y el entitlement del workspace aparece activo, registrado en el servidor bajo la clave ai.reference-task.
Fallos comunes: un paywall vacío significa que el offering no es Current o los productos están sin vincular; una compra en dispositivo que falla significa que el producto de tienda sigue en borrador o hay una cuenta sandbox equivocada con la sesión iniciada; un entitlement que nunca cambia significa que MOBILE_PURCHASES_PROVIDER/EXPO_PUBLIC_MOBILE_PURCHASES_PROVIDER están apagados o que el Authorization del webhook no coincide — el panel de RevenueCat lista el estado de cada entrega de webhook.
Si quieres continuar la configuración, lee Compilación y verificación en dispositivos.