La Retention Messaging API de Apple pone tus palabras en la pantalla de cancelación, pero las solicitudes de reembolso nunca pasan por ella

A los suscriptores que tocan Cancelar en un iPhone ahora se les puede mostrar un mensaje que tú elegiste, un plan más barato o un descuento, antes de que confirmen. Eso es la Retention Messaging API de Apple, y es la primera vez que un desarrollador tiene voz en la propia pantalla de cancelación de Apple. Sigue siendo una versión preliminar a la que hay que pedir acceso. Además tiene un límite claro que importa si te preocupan los reembolsos: habla con quienes están a punto de dejar de pagar, no con quienes piden que les devuelvan el dinero. Esas solicitudes llegan a Apple por otro camino.

Qué hace la Retention Messaging API de Apple

La Retention Messaging API es un servicio de servidor a servidor. Subes con antelación textos e imágenes a Apple, Apple los revisa y después eliges qué mensaje aprobado ve un suscriptor cuando está a punto de cancelar una suscripción con renovación automática. La documentación de Apple enumera cuatro tipos de mensaje:

• Un mensaje de texto, que puede incluir viñetas.
• Un mensaje de texto con imagen.
• Un mensaje de cambio de plan, que sugiere otra suscripción del mismo grupo de suscripciones.
• Un mensaje de oferta promocional, que ofrece un precio con descuento en el mismo nivel o en otro, usando una oferta promocional que configuras en App Store Connect y firmas en tu servidor.

El mensaje aparece después de que el cliente toca Cancel Subscription en una página de detalles de suscripción. Luego Apple muestra una página Confirm Cancellation (Confirmar cancelación). El cliente aún puede cancelar, tocar Keep Subscription (Mantener suscripción) o aceptar la oferta o el plan que sugeriste. No puedes ocultar la salida, y Apple indica a los desarrolladores que no suban contenido engañoso o inexacto.

Mensajes predeterminados y flujo en tiempo real

Hay dos formas de usarla. La sencilla son los mensajes predeterminados: texto, con o sin imagen o viñetas, asignado a cada producto e idioma. La más completa es el flujo en tiempo real, en el que Apple llama a un endpoint Get Retention Message de tu servidor y tú respondes con un ID de mensaje. Solo el flujo en tiempo real puede mostrar mensajes de cambio de plan y de oferta promocional.

En la práctica, los predeterminados no son opcionales. Apple los usa como respaldo cada vez que falla una llamada en tiempo real, y no muestra ningún mensaje de retención para un producto en un idioma que no tenga uno predeterminado.

Qué le dice Apple a tu servidor en la llamada en tiempo real

La solicitud es un JWS firmado por el App Store. Una vez decodificado, contiene originalTransactionId, appAppleId, productId, userLocale, un requestIdentifier UUID, el entorno y signedDate. Apple te pide que compruebes que appAppleId coincide con tu app y que no respondas si no coincide. Lo útil es originalTransactionId, porque te permite consultar qué hizo realmente este suscriptor en tu app antes de decidir qué decirle.

Dónde aparece el mensaje de retención y dónde no

Apple coloca el mensaje en una sola pantalla, el paso Confirm Cancellation después de que el cliente toca Cancel Subscription, por ejemplo desde Apple Account > Subscriptions o desde la página de una suscripción en el App Store. Esa pantalla decide si habrá una próxima renovación. No toca el dinero ya cobrado.

Una solicitud de reembolso es un acto distinto. La página de soporte de Apple envía a los clientes a reportaproblem.apple.com, donde eligen “Request a refund” (Solicitar un reembolso), escogen un motivo y un artículo, y esperan de 24 a 48 horas una actualización. Dentro de tu app, beginRefundRequest de StoreKit abre la hoja de reembolso de Apple, y Apple indica que el App Store tarda hasta 48 horas en aprobar o denegar. Ninguno de los dos caminos pasa por la pantalla Confirm Cancellation.

¿Puede un mensaje de retención detener una solicitud de reembolso?

No. La solicitud de reembolso nunca llega a la pantalla donde vive el mensaje. Hay un detalle en la documentación de notificaciones de Apple que lo hace concreto. Cuando un cliente solicita un reembolso desde tu app con la API de solicitud de reembolso, Apple desactiva la renovación automática por su cuenta y envía DID_CHANGE_RENEWAL_STATUS con el subtipo AUTO_RENEW_DISABLED. Un cliente que cancela desde la página de ajustes de Suscripciones produce el mismo tipo y subtipo. Tu servidor ve una sola notificación para dos clientes muy distintos, y solo uno de ellos vio tu mensaje de retención.

Si la solicitud de reembolso sigue adelante, el canal para aportar pruebas es el CONSUMPTION_REQUEST. Apple lo envía para solicitudes de reembolso de cualquier tipo de producto, y tienes 12 horas para responder con Send Consumption Information. Solo puedes responder si el cliente dio su consentimiento. Después, la decisión de Apple llega como una notificación REFUND, o como REFUND_DECLINED si Apple rechaza un reembolso que el cliente inició en tu app.

¿Tiene Google Play una API de mensajes de cancelación?

No en la documentación del ciclo de vida de suscripciones de Google. Un suscriptor de Google Play cancela desde el centro de suscripciones de Play, mantiene el acceso hasta el final del ciclo de facturación actual y puede tocar Resubscribe (Volver a suscribirse) para deshacerlo antes de esa fecha, lo que Google llama una restauración. Te enteras después mediante una notificación SUBSCRIPTION_CANCELED, y el campo userInitiatedCancellation del recurso de suscripción te dice por qué se fue el usuario. La pausa, que según Google está activada por defecto en todas las suscripciones, es su principal herramienta integrada para reducir las bajas voluntarias.

En cuanto a los reembolsos, Google Play tiene su propio canal de pruebas. Llega una PendingRefundReviewNotification cuando un contracargo necesita la revisión del desarrollador, y tienes 24 horas para responder mediante orders.reviewrefund. Para los pedidos realizados después del 3 de agosto de 2026, cuando un contracargo prospera, Google traslada al desarrollador el precio de compra, menos la comisión de servicio de Play, más las comisiones de contracargo del banco.

Lo que te cuesta en dinero la pantalla de cancelación

Los mensajes de retención parecen gratis. No lo son, y las facturas llegan por tres lados.

Cómputo en cada visita a la página

Apple llama a tu endpoint cuando un suscriptor activo abre una página de detalles de suscripción con un botón Cancelar, no solo cuando cancela. Cada visita es una solicitud que tu servidor tiene que autenticar, consultar y responder en 700 ms, o Apple recurre al mensaje predeterminado. Eso descarta una función con arranque en frío que a veces tarda dos segundos. Pagas capacidad que se mantiene siempre activa, más las lecturas de base de datos y las llamadas de pago a APIs de terceros que tu lógica de decisión haga en cada solicitud.

El descuento son ingresos que decidiste no cobrar

Una oferta promocional que retiene a un suscriptor es dinero real conservado. Una que va a alguien que se habría quedado de todos modos es puro descuento. Esto es una ilustración, no una referencia. Un plan mensual de $9.99 ofrecido a mitad de precio durante tres meses cede $14.99 por cada oferta aceptada. Si uno de cada tres que aceptan se habría quedado pagando el precio completo, mil aceptaciones cuestan unos $5000 en descuentos entregados a personas que nunca los necesitaron. El otro lado del balance son los suscriptores que de verdad se iban.

El reembolso que provoca una salida incómoda

Apple mantiene el botón Cancel Subscription en la página, así que no puedes atrapar a nadie, pero sí puedes resultar molesto. Un cliente que se siente presionado tiene otra opción: pedirle a Apple que le devuelva el último cargo. Cuando llega un reembolso, el dinero se devuelve, y el cómputo, el almacenamiento, las llamadas a APIs y los pagos a afiliados ligados a ese suscriptor ya están gastados. Son costes que ningún mensaje de retención recupera.

Cómo usar los mensajes de retención sin subir tu tasa de reembolsos

Trata la pantalla de cancelación como un lugar para ser preciso, no ingenioso. Unas pocas reglas la mantienen del lado correcto de la línea de reembolsos:

• Decide por suscriptor. Usa el originalTransactionId de la solicitud de Apple para consultar el uso reciente. Ofrece un descuento o un plan más barato a quienes usan el producto. Da un mensaje breve y honesto a quienes no lo abren desde hace semanas.
• Responde rápido. Calcula la decisión de antemano cuando cambien tus datos de uso, para que la solicitud en sí sea una única consulta que quepa holgadamente en 700 ms.
• Escribe un mensaje predeterminado para cada producto e idioma. Sin él, una llamada fallida significa que no hay ningún mensaje.
• Vigila de cerca AUTO_RENEW_DISABLED. Si después llega un CONSUMPTION_REQUEST para el mismo originalTransactionId, estás ante una solicitud de reembolso, no una cancelación, y el reloj de 12 horas ya corre.
• Responde a cada CONSUMPTION_REQUEST que tengas permitido. RefundHalt envía a Apple datos de consumo precisos dentro del plazo de 12 horas y responde a la revisión de contracargos de Google Play en menos de 24 horas, porque son los únicos dos momentos en que alguna de las tiendas pide tu versión.

¿Vale la pena pedirle acceso a Apple?

Si vendes suscripciones con renovación automática y ya gestionas App Store Server Notifications V2, probablemente sí. La pantalla de cancelación es el último lugar donde puedes llegar a un suscriptor antes de que se vaya, y un cambio de plan te cuesta menos que perderlo del todo. Eso sí, presupuesta un endpoint que responda en cada visita a una página de suscripción, y mantén tus defensas contra reembolsos donde los reembolsos realmente ocurren.