Apple y Google te permiten extender la fecha de renovación de una suscripción tras una caída, y sus límites no se parecen en nada

Una caída le da a cada suscriptor el argumento de reembolso más limpio que existe, y no puedes impedir que lo use. Lo que sí puedes hacer es devolver los días perdidos antes de que nadie los pida. Las dos tiendas de apps te permiten extender la fecha de renovación de una suscripción para que el cliente reciba tiempo gratis en lugar de dinero. Apple limita cada extensión a 90 días y permite dos al año. Google te deja aplazar la facturación hasta un año por llamada. El papeleo, las notificaciones y la factura de fondo son lo bastante distintos como para que un solo plan ante caídas no sirva para ambas.

Qué hace una caída con tu exposición a reembolsos

Los reembolsos los deciden las tiendas, no tú. En la App Store, el cliente se lo pide a Apple y Apple decide. Puedes recibir una notificación CONSUMPTION_REQUEST y tener 12 horas para enviar datos de consumo mediante Send Consumption Information. Esa es toda tu voz en el asunto.

En Google Play, un comprador puede obtener un reembolso dentro de las 48 horas posteriores a la compra sin que nadie te pregunte. Después de eso, las solicitudes te llegan a ti. El único flujo de Google que pide tus pruebas es un contracargo marcado para revisión del desarrollador, que respondes mediante orders.reviewrefund en un plazo de 24 horas. La decisión del banco sobre un contracargo es definitiva.

Así que ninguna tienda te da forma de bloquear un reembolso. Lo que controlas es si un suscriptor sigue sintiéndose estafado cuando el servicio vuelve. Tiempo extra en la suscripción, concedido rápido y anunciado con claridad, es la herramienta que ambas tiendas crearon justo para eso.

Cómo extender la fecha de renovación de una suscripción en la App Store

La App Store Server API tiene dos endpoints para esto. Extend a Subscription Renewal Date actúa sobre una suscripción, que identificas por su originalTransactionId. Extend Subscription Renewal Dates for All Active Subscribers actúa sobre todos los suscriptores elegibles de un productId, y puedes limitarlo con storefrontCountryCodes cuando la caída solo afectó a algunas regiones.

Cada solicitud lleva tres cosas: extendByDays, un número de 1 a 90; un extendReasonCode; y un requestIdentifier que generas tú. El código de motivo 3 significa un problema o caída del servicio. El código 1 es satisfacción del cliente, el código 2 es otros motivos y el código 0 es no declarado.

Qué suscripciones extiende Apple

Solo califican las suscripciones autorrenovables activas con al menos un periodo pagado previo. Apple omite estas:

• Suscripciones en un periodo de oferta gratuita, como una prueba gratuita.
• Suscripciones inactivas en estado de reintento de facturación.
• Suscripciones en un periodo de gracia de facturación cuya fecha de vencimiento ya pasó.
• Suscripciones que ya recibieron dos extensiones de la fecha de renovación en los últimos 365 días.
• Suscripciones vencidas.

En Familia viene incluido sin coste. Cuando Apple extiende una suscripción comprada que admite En Familia, las suscripciones de los miembros de la familia también se extienden. No puedes apuntar directamente a la suscripción de un miembro de la familia.

La solicitud masiva es lenta, así que vigila las notificaciones

Apple dice que una solicitud para extender a todos los suscriptores activos puede tardar horas, o incluso días, según cuántos suscriptores tengas. Una respuesta 200 solo significa que Apple la está procesando. App Store Server Notifications V2 te dice cómo fue:

Por cada FAILURE, toma el originalTransactionId de la transacción firmada en el payload y reinténtalo con el endpoint de suscripción individual. Si prefieres consultar, Get Status of Subscription Renewal Date Extensions indica si la solicitud terminó y cuántas extensiones tuvieron éxito o fallaron.

Cómo funciona el aplazamiento de facturación de Google Play

La versión de Google es purchases.subscriptionsv2.defer, que se llama una vez por token de compra. El cuerpo de la solicitud contiene un deferralContext con tres campos. El etag viene de purchases.subscriptionsv2.get, y la llamada falla si no coincide con el etag más reciente de la suscripción. El deferDuration indica cuánto mover la fecha. Y validateOnly, cuando es true, ejecuta la solicitud como prueba sin tocar la suscripción.

La guía de facturación de Google fija el rango entre un día y un año por llamada a la API. Para ir más allá, vuelve a llamar antes de que llegue la nueva fecha de vencimiento. En una suscripción con renovación automática, el aplazamiento mueve la siguiente fecha de renovación. En un plan prepago, mueve la hora de vencimiento. En una suscripción con complementos, todos los elementos se aplazan la misma duración. La respuesta lista el nuevo expiryTime de cada elemento.

Durante el aplazamiento el usuario sigue suscrito con acceso completo y no se le cobra el tiempo extra. Google envía una notificación para desarrolladores en tiempo real SUBSCRIPTION_DEFERRED. El antiguo purchases.subscriptions.defer está obsoleto, así que el código nuevo debe usar el método v2.

Google no avisa a tu cliente, así que tienes que hacerlo tú

Apple envía un email al cliente tras cada extensión correcta. La guía de facturación de Google no describe ningún mensaje al usuario. Si el objetivo es adelantarte a las solicitudes de reembolso, el suscriptor tiene que saber que existe ese tiempo extra. Avísale tú, en la app y por email, y di cuántos días y por qué.

Apple y Google, lado a lado

Lo que cuesta una extensión frente a un reembolso

Un reembolso y una extensión sacan el dinero de lugares distintos. Un reembolso devuelve lo que el cliente pagó por el periodo. Todo lo que ya gastaste en atender a ese cliente queda gastado: cómputo por cada sesión, llamadas a la API del modelo, almacenamiento y cualquier pago a un creador cuyo contenido usó.

Una extensión conserva el pago. Lo que cuesta es el servicio que prestas sin una renovación que lo pague. Cada día añadido, un suscriptor activo sigue generando las mismas facturas. Para un usuario ligero eso es casi nada. Para un usuario intensivo de una función de IA, 30 días extra pueden significar 30 días de llamadas al modelo sin ingresos que los compensen. Ajusta la extensión a la caída, no a la disculpa que te gustaría ofrecer.

El coste de comisión en Apple

Apple paga el 70% de cada renovación durante el primer año de servicio pagado de un suscriptor y el 85% a partir de entonces. La página de suscripciones de Apple dice que los días de extensión de renovación se excluyen de los días de servicio pagado. Así que una extensión de 30 días retrasa 30 días el paso de ese suscriptor al 85%. Si estás en el App Store Small Business Program, ya recibes el 85% y este coste no se aplica.

El coste de los contracargos en Google Play

Para pedidos realizados después del 3 de agosto de 2026, un contracargo que gana el titular de la tarjeta le cuesta a un desarrollador de Google Play el precio de compra menos la comisión de servicio de Play, más las comisiones del banco. Una caída es justo el tipo de evento que lleva a un cliente molesto a su banco. Un aplazamiento que le llegue primero sale más barato que una disputa que no puedes revertir.

Cuándo una extensión no es la herramienta adecuada

La compra no era una suscripción

Las extensiones de la fecha de renovación solo se aplican a suscripciones. Si una caída rompió un consumible o un desbloqueo único, vuelve a entregar el artículo. Si Apple envía un CONSUMPTION_REQUEST por él, informa de lo que pasó. El campo deliveryStatus de Apple tiene un valor para esto, UNDELIVERED_SERVER_OUTAGE, y Apple dice que cualquier estado distinto de DELIVERED debe ir con consumptionPercentage en 0.

El cliente ya usó las dos extensiones de Apple

El límite de Apple es de dos extensiones por cliente en 365 días. Dos caídas en un año las agotan, y una tercera te deja sin nada que ofrecer a través de la tienda. Lleva la cuenta de cuántas extensiones ha usado cada originalTransactionId, para que las notificaciones FAILURE de la solicitud masiva no te pillen por sorpresa.

El cliente está en una prueba gratuita

Apple no extiende una suscripción en un periodo de oferta gratuita. Un usuario de prueba perdió días gratis, no pagados, así que el riesgo de reembolso es bajo. Si quieres compensarlo, un mensaje dentro de la app cuesta menos que cualquier llamada a la API.

Una lista de verificación para la próxima caída

• Registra cuándo empezó y terminó la caída, y qué productos y regiones afectó.
• Elige un número de días que cubra el tiempo perdido. En Apple, usa el código de motivo 3 y quédate entre 1 y 90.
• En Apple, envía una solicitud masiva por productId, limitada con storefrontCountryCodes cuando solo se vieron afectadas algunas regiones.
• Escucha las notificaciones RENEWAL_EXTENSION FAILURE y reintenta cada una con el endpoint de suscripción individual.
• En Google Play, recorre los tokens de compra activos, lee cada etag, ejecuta primero con validateOnly y luego aplaza de verdad.
• Avisa tú mismo a los suscriptores de Google Play del tiempo extra, ya que Google no lo hará.
• Actualiza el vencimiento de los derechos de acceso a partir de RENEWAL_EXTENDED y SUBSCRIPTION_DEFERRED, no de tus propios cálculos de fechas.
• Guarda registros de uso por cuenta, para que si aun así llega una solicitud de reembolso o un contracargo, tus pruebas estén listas en menos de 12 horas para Apple y 24 horas para Google.