Los motivos de cancelación de una suscripción suelen llegarte antes que la solicitud de reembolso, y Google Play te da muchos más que Apple

La mayoría de los suscriptores que acaban recibiendo un reembolso cancelan primero. Esa cancelación lleva un motivo, y las dos tiendas te dan cantidades muy distintas de información. Google Play hace una breve encuesta y envía la respuesta a tu servidor, texto libre incluido. Apple envía un código numérico que indica cómo terminó la suscripción, no por qué el cliente quería irse. Si lees bien ambos, verás venir las solicitudes de reembolso cuando todavía puedes hacer algo al respecto.

Lo que Google Play te dice sobre los motivos de cancelación

Cuando un usuario cancela en el centro de suscripciones de Play, Google le pregunta por qué. La respuesta aparece en el recurso de suscripción que obtienes con purchases.subscriptionsv2.get, dentro de canceledStateContext. Ese objeto solo existe mientras la suscripción está cancelada o vencida, e indica quién la terminó: el usuario, el sistema de Google, tú o un reemplazo, como un cambio de plan.

Cuando fue el usuario, el objeto userInitiatedCancellation contiene dos campos. cancelTime indica cuándo canceló. cancelSurveyResult contiene la respuesta de la encuesta.

La columna de la derecha es nuestra interpretación, no la de Google. Las dos primeras columnas salen directamente de la referencia de la API.

La notificación no incluye el motivo

Una suscripción cancelada dispara una notificación en tiempo real para desarrolladores SUBSCRIPTION_CANCELED, de type 3. Google deja claro que estas notificaciones solo avisan de que cambió el estado de la compra. El payload te da un token de compra y nada más útil, así que tu handler tiene que llamar a purchases.subscriptionsv2.get para leer la respuesta de la encuesta.

La vista de Play Console

No necesitas código para ver los totales. Los informes de suscripciones de Play Console incluyen una tarjeta de cancelaciones que divide la pérdida de suscriptores en voluntaria, involuntaria y otra, y una tarjeta de respuestas a la encuesta de cancelación para los usuarios que decidieron contestar. Las respuestas de texto libre de quienes eligieron otro se pueden descargar como CSV desde la tarjeta de otras respuestas. Esa descarga requiere el permiso View financial data, el mismo que darías a una herramienta que lee tus pedidos.

Lo que Apple te dice y lo que se calla

Apple no tiene ninguna encuesta de cancelación que informe a los desarrolladores. El campo más cercano es expirationIntent, en la información de renovación firmada, y describe cómo terminó una suscripción, no lo que pensaba el cliente.

El código 1 es el único que describe una decisión del cliente, y no dice nada sobre el motivo. Un cliente que se fue porque la app no paraba de cerrarse y otro que simplemente terminó un proyecto se ven exactamente igual.

La señal escondida en AUTO_RENEW_DISABLED

Hay una notificación de Apple que merece una mirada más atenta. DID_CHANGE_RENEWAL_STATUS con el subtipo AUTO_RENEW_DISABLED suele significar que el cliente desactivó la renovación automática. La documentación de Apple añade un segundo caso: el App Store también desactiva la renovación automática después de que el cliente pida un reembolso.

Así que en iOS, un evento de renovación desactivada puede ser el primer rastro de una solicitud de reembolso. Si la compra es un consumible o una suscripción con renovación automática, puede llegar después un CONSUMPTION_REQUEST, y desde ese momento tienes 12 horas para enviar los datos de consumo. Si llega un evento de renovación desactivada sin ninguna acción visible en tu app, conviene tomarlo como un aviso para tener listos los datos de uso de esa cuenta.

Apple y Google, cara a cara

Dónde una cancelación se convierte en reembolso

Una cancelación detiene el próximo cobro. No devuelve el último. Que el dinero vuelva o no depende del flujo de reembolso al que llegue el cliente después, y la mayoría de esos flujos funcionan sin ti.

• En Google Play, un comprador puede obtener por su cuenta un reembolso dentro de las 48 horas posteriores a la compra, y lo decide Google.
• Los reembolsos a través del soporte de Google o de Apple los decide la tienda.
• El CONSUMPTION_REQUEST de Apple pide tus datos de consumo, con un plazo de 12 horas.
• La revisión de contracargos de Google Play pide pruebas mediante orders.reviewrefund, con un plazo de 24 horas. La decisión del banco sobre un contracargo es definitiva.

Un motivo de cancelación no cambia ninguna de esas reglas. Lo que cambia es lo pronto que sabes qué cliente está descontento, y si tus pruebas están listas cuando llega uno de los dos flujos que las piden.

Lo que te cuesta cada motivo

La respuesta de la encuesta también es una guía aproximada de lo que ya te ha costado atender una cuenta, que es el dinero que te queda en las manos cuando hay un reembolso.

Problemas técnicos

Este es el caro. El cliente usó el producto lo suficiente para encontrarse con problemas, así que ya pagaste el cómputo de sus sesiones, las llamadas a la API del modelo que generaron sus peticiones, el almacenamiento de lo que creó y cualquier pago debido a un creador cuyo contenido usó. Si luego obtiene un reembolso, el precio se devuelve y esos costes se quedan contigo. Si acude a su banco en Google Play, un pedido realizado después del August 3, 2026 te cuesta el precio de compra menos la comisión de servicio de Play, más las comisiones del banco.

Motivos de precio

Una queja por el precio te cuesta menos de lo que parece, salvo que esconda una renovación inesperada. Esa es la historia clásica de un contracargo, así que comprueba si la cancelación llegó justo después de un cobro de renovación y si se enviaron tus recordatorios de renovación.

Uso insuficiente

Poco uso significa costes de servicio bajos, así que aquí un reembolso devuelve sobre todo dinero que no te costó mucho ganar. También es el motivo en el que unos datos de consumo honestos, si Apple los pide, muestran exactamente qué usó el cliente y qué no.

Encontró una app mejor

Estos clientes rara vez disputan nada. Se fueron con un competidor. El motivo sirve para decisiones de producto y casi nunca para defenderte de un reembolso.

Una rutina para leer los motivos de cancelación

• Con cada SUBSCRIPTION_CANCELED de Google Play, llama a purchases.subscriptionsv2.get y guarda canceledStateContext junto con el token de compra y cancelTime.
• Guarda reasonUserInput tal cual cuando el motivo sea otro. Es el único texto libre que te da cualquiera de las dos tiendas.
• Con cada DID_CHANGE_RENEWAL_STATUS de Apple con AUTO_RENEW_DISABLED, registra el evento y recupera el uso de esa cuenta, por si llega un CONSUMPTION_REQUEST.
• Con cada notificación EXPIRED de Apple, registra el subtipo y expirationIntent para que la baja voluntaria y los fallos de facturación no se mezclen.
• En las cancelaciones de Google Play por problemas técnicos, revisa tus registros de errores de esa cuenta y contacta con el cliente antes de que él contacte con su banco.
• Mantén registros de uso por cuenta, para que un CONSUMPTION_REQUEST tenga respuesta en menos de 12 horas y una revisión de contracargo en menos de 24.