Perder notificaciones de reembolso puede costarte los únicos reembolsos que puedes impugnar, y ambas tiendas te permiten recuperarlas si miras a tiempo

Perder notificaciones de reembolso es la forma silenciosa en que un desarrollador pierde las dos únicas decisiones de reembolso en las que tiene voz. El CONSUMPTION_REQUEST de Apple y la revisión de contracargos de Google Play empiezan con una notificación, y ambos se cierran con un plazo corto: 12 horas en Apple, 24 horas en Google. Si tu servidor está caído, lento o mal configurado cuando llega ese mensaje, la tienda no te espera. Decide con lo que ya tiene.

La buena noticia es que ninguna de las dos tiendas descarta el mensaje al primer fallo. Apple reintenta y guarda un historial de 180 días que puedes consultar. Google publica a través de Pub/Sub, que conserva durante días los mensajes sin confirmar. La mala noticia es que los tiempos de reintento no encajan con las ventanas de respuesta, y uno de los dos flujos no tiene ninguna API de recuperación.

Cómo entrega cada tienda las notificaciones de reembolso

Apple envía las App Store Server Notifications directamente a una URL HTTPS que configuras en App Store Connect. Google no llama directamente a tu servidor. Publica las notificaciones en tiempo real para desarrolladores (Real-time developer notifications) en un tema de Google Cloud Pub/Sub, y tu suscripción a ese tema las envía a tu endpoint o espera a que tu servidor las extraiga.

Qué considera Apple un fallo

La documentación de Apple es concreta. Si devuelves cualquier estado de 200 a 206, la entrega termina. Si devuelves un 40x o un 50x, Apple reintenta. Apple también considera fallido cualquier otro código. Cada intento se registra con un sendAttemptResult, y los valores parecen una lista de caídas reales: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE y algunos más. Para TIMED_OUT, el propio consejo de Apple es comprobar que tu servidor no procesa los mensajes en línea.

Qué considera Google un fallo

En una suscripción push, un código de respuesta de éxito de tu endpoint es la confirmación. En una suscripción pull, tu servidor tiene que confirmar cada mensaje que extrae, o Pub/Sub lo vuelve a entregar. El plazo de confirmación por defecto es de 10 segundos y el máximo es de 600 segundos. La guía de RTDN de Google añade una regla que conviene repetir: una notificación solo dice que algo cambió, así que aun así debes llamar a la Google Play Developer API para obtener el estado completo de la compra.

Por qué el calendario de reintentos de Apple no encaja con la ventana de 12 horas

Los intervalos de reintento de Apple se miden desde el intento anterior, no desde el primero. Si los sumas, obtienes esta cronología para una sola notificación V2 que tu servidor sigue sin recibir.

Apple te pide responder en las 12 horas siguientes a recibir el CONSUMPTION_REQUEST. Si tu servidor está caído en la primera entrega y en el reintento de una hora después, el siguiente intento llega 13 horas después del primero. Apple no dice si una solicitud recibida por primera vez en un reintento obtiene 12 horas nuevas. La lectura prudente es tomar el primer intento como inicio del plazo, lo que significa que los reintentos por sí solos no salvarán una solicitud que perdiste por más de una hora.

¿Reintenta Apple después de un HTTP 400?

Sí, según la documentación. Apple indica los 40x y 50x como los códigos que activan un reintento. En marzo de 2026 un desarrollador informó en los foros de Apple de que los reintentos tras respuestas 400 parecían detenerse, luego dijo que las entregas se reanudaron un día o dos después, y Apple pidió un informe en Feedback Assistant. Toma el comportamiento documentado como la regla y tu propia monitorización como la prueba.

Recupera notificaciones perdidas del App Store con Get Notification History

Get Notification History devuelve las notificaciones de la versión 2 que Apple intentó enviar a tu servidor en el intervalo que elijas. Cada registro incluye el payload firmado completo, así que puedes pasarlo al mismo handler que una notificación en vivo. Cada registro incluye también un array sendAttempts de hasta seis entradas, una por el primer intento y una por cada uno de los cinco reintentos.

• startDate y endDate son obligatorios, y startDate debe estar dentro de los últimos 180 días en producción o de los últimos 30 días en sandbox.
• Pon onlyFailures en true para obtener solo las notificaciones que no han llegado a tu servidor, más las que Apple aún está reintentando.
• Filtra por un notificationType, como CONSUMPTION_REQUEST o REFUND, o por un transactionId para un solo cliente, pero no ambos en la misma solicitud.
• Cada llamada devuelve hasta 20 registros. Sigue llamando con el paginationToken mientras hasMore sea true, y envía el mismo cuerpo de solicitud cada vez.

Hay una salvedad importante para los reembolsos. Apple dice que los registros del historial reflejan el estado de una compra cuando se envió la notificación por primera vez, no el actual. Así que un REFUND recuperado es un hecho del pasado. Antes de revocar el acceso, comprueba el estado actual con los endpoints de transacción o de estado de suscripción.

Las notificaciones V1 no se pueden recuperar así

Get Notification History solo cubre la versión 2. Apple reintenta las notificaciones V1 tres veces, a las 6, 24 y 48 horas del intento anterior, y si todas fallan no hay historial que reproducir. Es un motivo más para pasar a V2 cualquier app que siga en V1.

Recupera notificaciones de reembolso perdidas de Google Play

La red de seguridad de Google es el propio Pub/Sub. Mientras exista tu suscripción, un mensaje que nadie confirmó se queda ahí durante el periodo de retención, 7 días por defecto y hasta 31 días si lo amplías. Cuando tu endpoint vuelve, la entrega se reanuda. Dos ajustes pueden anular eso sin hacer ruido.

• Un tema de mensajes fallidos (dead-letter) saca un mensaje de tu suscripción tras un número fijo de intentos de entrega fallidos. El valor por defecto es 5, y con la política de reintento por defecto de reenvío inmediato, cinco intentos pueden pasar rápido. Si usas uno, vigila ese tema como una segunda bandeja de entrada.
• Una suscripción sin actividad de suscriptores, como conexiones abiertas, pulls activos o pushes correctos, caduca tras 31 días por defecto. Un endpoint que sigue roto durante un mes puede perder la propia suscripción, junto con todo lo que esperaba en ella.

Los reembolsos anulados tienen un respaldo de 30 días

Para los reembolsos que ya ocurrieron, la Voided Purchases API es el respaldo por pull. Lista las compras anuladas de los últimos 30 días, hasta 1.000 por página, con una cuota de 6.000 consultas al día y 30 consultas en cualquier periodo de 30 segundos por app. Pasa type 1 para incluir suscripciones junto a los productos de compra única. Ejecutarla a diario detecta cualquier reembolso que tu canal de notificaciones haya perdido, lo que mantiene fiables los derechos de acceso y las cifras de ingresos.

Las revisiones de contracargos no lo tienen

Una PendingRefundReviewNotification es distinta. Lleva el pendingRefundToken que debes pasar a orders.reviewrefund, y tienes 24 horas desde que la recibes para enviar tu preferencia de reembolso y tus pruebas de uso. Google registra tu primera llamada e ignora el resto. La documentación de Google no describe ningún endpoint que liste las revisiones pendientes, así que si ese mensaje de Pub/Sub se pierde, tus pruebas para ese contracargo se pierden con él.

Lo que cuesta en dinero una notificación de reembolso perdida

Una notificación perdida de un reembolso que ya es definitivo te cuesta trabajo contable. La encuentras después en la Voided Purchases API o en Get Notification History, revocas el acceso si tu política lo exige y tus informes se ponen al día. Molesto, pero barato.

Una notificación perdida en uno de los dos flujos impugnables cuesta dinero de verdad, porque la tienda decide sin tus pruebas. En Apple, eso significa que la decisión de reembolso se toma sin tus datos de consumo. En Google Play, para pedidos realizados después del 3 de agosto de 2026, un contracargo perdido te cuesta el precio de compra menos la comisión de servicio de Play, más la comisión de contracargo que cobra el banco del comprador. Google solo cubre su propia comisión de servicio.

Y el dinero que gastaste en entregar la compra ya se había ido antes de que empezara la disputa.

• Cómputo: tiempo de GPU y de servidor detrás de cada generación, renderizado o respuesta de modelo que el comprador ya usó.
• Llamadas a API: solicitudes a terceros facturadas en el momento en que se hicieron, a menudo por llamada.
• Almacenamiento: archivos y contenido multimedia que creó el comprador, todavía en tu factura de hosting.
• Pagos: participaciones en ingresos ya pagadas a creadores, afiliados o socios por esa venta.

Nada de eso vuelve cuando se aprueba un reembolso. Las pruebas que envías en esas 12 o 24 horas son la única palanca que tienes, y una notificación perdida te la quita.

Una rutina de recuperación que aguanta

• Confirma primero. Guarda el payload en bruto, devuelve un código de éxito y luego procésalo en una cola.
• Consulta Get Notification History de Apple con onlyFailures cada pocos minutos para CONSUMPTION_REQUEST, de modo que una caída cueste minutos de la ventana de 12 horas.
• Ejecuta a diario un barrido de Get Notification History con onlyFailures sobre los últimos días para todos los tipos, y reproduce lo que encuentres.
• Ejecuta a diario una llamada a la Voided Purchases API con type 1 para cada app de Google Play, y concíliala con los reembolsos que ya registraste.
• En Pub/Sub, mantén la retención de mensajes en 7 días o más, configura alertas sobre el tema de mensajes fallidos si tienes uno, y alerta cuando se acumulen mensajes sin entregar.
• Prueba también todo el recorrido en producción. El sandbox de Apple envía cada notificación una sola vez y sin reintentos, y Request a Test Notification junto con Get Test Notification Status muestran exactamente cómo respondió tu servidor.

RefundHalt recibe por ti las notificaciones de ambas tiendas y responde automáticamente a los CONSUMPTION_REQUEST y a las revisiones de contracargos dentro de sus plazos, para que no seas tú quien vigila el reloj.