Guía de monetización

Checklist de In-App Purchases y suscripciones

Código de pago y configuración Store forman un sistema. Un SDK correcto no arregla productos ausentes o una paywall engañosa.

LaunchLint Academy

17 min de lecturaRevisado editorialmente por el equipo de LaunchLint
Ilustración de un flujo revisado de compras y suscripciones
Las compras y suscripciones no suelen fallar por una sola llamada API. Configuración, estado del producto, paywall, transacción, restauración, cuenta y acceso del reviewer deben funcionar como un sistema coherente.
TL;DR

La respuesta breve

  • Las compras y suscripciones no suelen fallar por una sola llamada API. Configuración, estado del producto, paywall, transacción, restauración, cuenta y acceso del reviewer deben funcionar como un sistema coherente.
  • Esta guía ofrece un gate de lanzamiento para Expo y React Native, conectando Apple y Google con precios claros, entitlements robustos, pruebas de ciclo de vida y indicaciones para el equipo de revisión completas.
  • Para la aceptación final usa una matriz de entitlements y no solo una captura del paywall. Cada fila combina plataforma, producto, estado de tienda, cuenta de app y acceso esperado. Cubre compra nueva, restauración, pago pendiente, reembolso, caducidad y una cuenta de tienda ya vinculada a otra cuenta. Compara interfaz, backend y verdad de la tienda después de cada transición. El sistema solo está listo cuando las tres capas vuelven a coincidir. Define quién puede resolver webhooks contradictorios o caídas y ejecutar una reconciliación segura. Mientras se sincroniza, el acceso no debe parpadear, no pueden concederse beneficios dobles y soporte necesita una referencia trazable sin recibos sensibles. Repite la matriz en iOS y Android porque modelos parecidos tienen estados, tiempos y herramientas diferentes. Verifica también cada moneda e idioma en un dispositivo pequeño, con lector de pantalla y conexión lenta. Guarda fecha, build, productos, cuentas de prueba y resultado, y elimina después cualquier acceso de ensayo que pueda afectar métricas o revisiones futuras.
  • Después del lanzamiento, monitoriza compra completada, latencia del acceso, errores de restauración, reembolsos y soporte por plataforma y producto. Define alertas antes y prepara un runbook de reconciliación seguro. Una tasa de checkout saludable no basta si el usuario paga pero recibe acceso tarde o no puede restaurar en otro dispositivo. Compara métricas con eventos verificados del store y no con un único evento del cliente. Revisa los primeros casos manualmente y convierte cualquier patrón en una prueba automatizada para la siguiente versión.

Definir el modelo de producto

Clasifica cada beneficio como consumible, no consumible o suscripción. Documenta qué desbloquea, cuánto dura y si pertenece a cuenta, plataforma o identidad de tienda.

Producto, cliente, backend y tienda deben compartir ese contrato. Una lista informal de IDs provoca periodos incorrectos, duplicados o promesas distintas.

Contrato

  • Tipo y beneficio claros
  • Duración definida
  • Propiedad explicada
  • IDs centralizados
  • Responsable asignado

Alinear productos y estados

Completa IDs, nombres, descripciones, precios, impuestos, disponibilidad e idiomas. Apple requiere presentar la primera compra de un tipo con una nueva versión; comprueba su estado.

En Google Play las suscripciones combinan producto, planes base y ofertas. Revisa países, precios, activación y compatibilidad. Un ID en código no significa que el producto esté a la venta.

Tienda

  • Idiomas completos
  • Precios y países
  • Estado listo
  • Apple enviado correctamente
  • Planes Google activos

Diseñar un paywall claro

El paywall muestra precio, periodo, renovación, prueba y beneficio principal. Lee el precio localizado desde la tienda y no fijes moneda en código. Botón y titular no deben ocultar coste o fecha.

Enlaza privacidad y condiciones y deja visible la restauración. Prueba monedas y traducciones largas; periodos cortados y descuentos ambiguos elevan el riesgo.

Paywall

  • Precio localizado
  • Periodo visible
  • Prueba clara
  • Términos accesibles
  • Restore visible

Procesar compras y accesos

No trates el callback del cliente como verdad permanente. Verifica en servidor, asocia de forma idempotente y guarda el entitlement actual.

Una compra puede quedar pendiente, cancelarse, reembolsarse, revocarse o entregarse dos veces. Cada transición debe repetirse sin crédito duplicado ni pérdida de acceso. No registres secretos.

Pipeline

  • Verificación servidor
  • Idempotencia
  • Pendiente y cancelación
  • Refund actualiza acceso
  • Sin secretos cliente

Probar restauración y cambio de dispositivo

Compras no consumibles y abonos activos deben restaurarse tras reinstalación o cambio de dispositivo. Prueba misma cuenta de tienda, nuevo login y cuenta ya vinculada.

Ofrece mensajes para compra inexistente, propiedad de otra cuenta, tienda no disponible y verificación pendiente. Sin progreso visible, Restore parece roto.

Restore

  • Reinstalación
  • Nuevo dispositivo
  • Nuevo login
  • Conflicto de propiedad
  • Errores visibles

Gestionar cambios y cancelación

Facilita la gestión o cancelación en la tienda correcta. Muestra plan y estado y abre el destino adecuado sin afirmar que la app canceló el contrato.

Planifica upgrade, downgrade, gracia, reintento, caducidad y reembolso. Usa el entitlement verificado, no un boolean local, y trata límites temporales.

Ciclo

  • Enlace de gestión
  • Entitlement verificado
  • Upgrade y downgrade
  • Gracia y reintento
  • Caducidad y refund

Cubrir sandbox, tracks y errores

Prueba éxito, cancelación, pendiente, pérdida de red, entrega doble, ya comprado, restore, reembolso y caducidad. Sandbox y tracks aceleran tiempos, así que documenta ciclos esperados.

Usa un build distribuido por tienda cuando firma y asociación importen. Registra ID, plataforma, cuenta, build y estado sin guardar pagos o tokens.

Pruebas

  • Éxito, cancelación y pendiente
  • Entrega doble
  • Restore
  • Refund y caducidad
  • Pérdida de red

Preparar envío y indicaciones para el equipo de revisión

Antes del envío, los productos deben estar listos y vinculados a la versión. El reviewer necesita llegar al paywall, comprar y entender el beneficio bloqueado. Mantén backend y cuenta disponibles.

indicaciones para el equipo de revisión incluye navegación, login, producto, resultado, restauración y requisitos. Los pasos claros ayudan, pero no corrigen una compra rota.

Review

  • Productos vinculados
  • Backend disponible
  • Ruta exacta
  • Resultado descrito
  • Restore documentado

Preguntas frecuentes

¿La primera compra debe acompañar una versión?

Apple requiere presentar la primera compra de un tipo con una nueva versión; verifica App Store Connect.

¿Puedo fijar el precio?

Es mejor usar el precio localizado de la tienda para mantener moneda y cambios correctos.

¿Basta el callback del cliente?

No. Verifica y procesa de forma robusta antes de conceder acceso duradero.

¿Necesito Restore?

Las compras restaurables y suscripciones necesitan una ruta clara y probada.

¿Cómo ayudo al reviewer?

Proporciona cuenta, navegación, producto, resultado y mantén backend y productos disponibles.

Fuentes oficiales

Este artículo se basa en las siguientes fuentes primarias oficiales. Las reglas pueden cambiar; comprueba siempre la versión vigente antes de enviar.