Vender suscripciones dentro de la app
Dentro de la app instalada desde una tienda, quien cobra es la tienda, no tu pasarela. Esta guía explica cómo ligar cada plan de tu app a un producto de la App Store o de Google Play, y por qué a veces el botón de suscribirse no aparece.
Por qué dentro de la app es distinto
En el sitio publicado, la suscripción pasa por la pasarela que conectaste (Stripe, Mercado Pago, Pagar.me). Dentro de la app instalada desde una tienda, eso es violación de la política de las dos tiendas para contenido digital, y el castigo es la retirada de la app.
Por eso la plataforma nunca cae en la pasarela dentro de la app. O existe compra por la tienda, configurada y lista, o la app muestra el estado mudo. Un botón que abre la tienda y falla es peor que ningún botón.
La tienda se queda con una comisión sobre cada venta, y los dos programas tienen tramos distintos según la facturación y el tiempo de suscripción. Consulta las páginas oficiales de Apple y de Google Play antes de fijar tu precio.
Qué tiene que estar listo
- la app nativa publicada, o al menos configurada en la pestaña Aplicación;
- la compra dentro de la app activada en el paso Funciones;
- los planes de tu app ya creados (lo que la pestaña Datos llama planes, y lo que la app vende);
- las credenciales de verificación: en iOS la clave de In-App Purchase, en Android la cuenta de servicio de Play;
- cada plan ligado a un producto de la tienda, que es de lo que trata el resto de esta guía.
Ligar cada plan a un producto de la tienda
En la pestaña Aplicación, la sección de suscripciones muestra los planes de tu app junto a lo que la tienda tiene de verdad, una tienda cada vez (Google Play y la App Store son catálogos separados: estar ligado en una no dice nada de la otra). Cada plan aparece con un estado:
| Estado | Qué quiere decir |
|---|---|
| sin producto | el plan no está ligado a nada en la tienda |
| no encontrado en la tienda | hay un identificador guardado aquí, pero la tienda no lo reconoce |
| creado, pero no vendible | el producto existe y todavía no se puede comprar (borrador, sin precio, sin revisión) |
| vendible | listo: la app puede vender ese plan |
Solo vendible permite la compra. Es una distinción que importa: en Google, la API responde con éxito mientras el plan base sigue en borrador, y la compra falla en el aparato con "artículo no disponible".
En Google Play
Dos acciones, y cuál usar depende de dónde empezaste:
- Crear en la tienda: la plataforma crea el producto y activa el plan base por ti. Antes de confirmar, comprueba el identificador que aparece en "Se creará como";
- Vincular a un producto existente: si ya montaste el catálogo en la Play Console, indica el id del producto y el del plan base. La plataforma comprueba y muestra las diferencias entre tu plan y lo que hay en la tienda (precio, periodo), sin decidir por ti.
En la App Store
Aquí la plataforma no crea la suscripción, y no es limitación nuestra: Apple exige que la primera suscripción se envíe junto a una versión de la app, dentro de un grupo de suscripciones, con precio por territorio y revisión.
El camino es crearla en App Store Connect y después vincularla aquí:
- en App Store Connect, abre la app y ve a Monetization → Subscriptions;
- crea un grupo de suscripciones (el grupo es lo que permite al cliente cambiar de plan dentro de él);
- crea la suscripción, con identificador, duración y precio;
- rellénalo todo hasta que el estado sea Ready to Submit;
- en la página de la versión de la app, en la sección de compras dentro de la app, marca la suscripción y envía las dos juntas a revisión;
- una vez aprobada, vuelve a la pestaña Aplicación y vincula el plan al identificador.
Esto vale para la primera suscripción. Cuando ya hay una aprobada en el grupo, las siguientes pueden enviarse solas.
Los identificadores son permanentes
En las dos tiendas, el identificador de un producto no se puede renombrar ni reutilizar una vez creado. En Google Play ni siquiera se puede borrar una suscripción, un plan base o una oferta: se quedan para siempre, para los informes.
Por eso la pantalla avisa antes de crear, y por eso se niega a inventar una variante cuando el identificador ya está ocupado: ahí lo correcto es vincular, no crear otro.
La clave de In-App Purchase (iOS)
Verificar una compra en iOS usa una clave distinta de la que envía los builds. Se genera en Users and Access → Integrations → In-App Purchase y se conecta en la propia sección de suscripciones.
Sin ella, la tienda cobraría en el aparato y la verificación lo rechazaría después: dinero movido, nada liberado, y el cliente con un recibo en la mano. Por eso, sin esa clave, la app se queda muda en lugar de vender.
El botón de suscribirse no aparece: por qué
El servidor decide eso en un único lugar, y siempre para estrechar, nunca para ampliar. Cada motivo es una configuración que falta, y todos tienen arreglo:
| Qué falta | Qué hacer |
|---|---|
| el cliente ya tiene una suscripción activa | nada: cobrar otra vez por otra vía sería un segundo cargo |
| la app no tiene versión nativa | configura la pestaña Aplicación |
| la compra dentro de la app no está activada | activa la función en el paso Funciones |
| la plataforma de ese aparato no está activada | activa iOS o Android en el paso Tiendas |
| falta la credencial de verificación | conecta la clave de In-App Purchase (iOS) o la cuenta de servicio (Android) |
| el plan no existe | revisa los planes de tu app en la pestaña Datos |
| el catálogo no está listo | liga el plan a un producto vendible en la tienda |
Cancelación y reembolsos
Quien cancela una suscripción de tienda es el cliente, en la tienda, no en tu app: es así en las dos y no se puede cambiar. Renovaciones, cancelaciones y reembolsos nos llegan por las notificaciones de la propia tienda, y el acceso del cliente se ajusta a partir de eso.
Una consecuencia práctica en Android: una compra que la app no confirma es reembolsada automáticamente por Google en tres días. La plataforma la confirma en cuanto pasa la verificación, así que el camino normal ya lo cubre; si un cliente informa de un reembolso sin motivo, es lo primero que hay que mirar.
El aparato nunca decide
Conviene saberlo, porque explica varias respuestas del sistema: el identificador de transacción que devuelve la app es una afirmación, no una prueba. Todo lo que mueve dinero (qué producto, de quién, hasta cuándo, sigue activo) se le pregunta a la tienda con la credencial del propio dueño de la app.
Es lo que impide que un recibo falsificado libere acceso de pago, y también el motivo de que una compra tarde unos segundos entre que la tienda la acepta y la app la libera.