Si tu app sigue usando App Store Server Notifications V1, Apple nunca te consulta sobre los reembolsos de suscripciones

La versión 1 de App Store Server Notifications sigue entregando reembolsos, pero deja fuera la única notificación que te permite defender un reembolso de suscripción. Apple declaró V1 obsoleta el 5 de junio de 2023, junto con el endpoint verifyReceipt, y desde entonces ha añadido todas las funciones de reembolso solo a V2. Si la configuración de App Store Connect todavía dice Version 1, Apple puede decidir un reembolso de suscripción sin enviar nunca un CONSUMPTION_REQUEST a tu servidor. No pierdes una disputa. Nunca te invitan a ella.

Qué significa la obsolescencia de App Store Server Notifications V1 de Apple

Obsoleto no significa apagado. Un ingeniero de Apple escribió en los foros de desarrolladores en junio de 2023 que verifyReceipt y las notificaciones V1 seguirán funcionando hasta que se anuncie una fecha de retirada, que esa fecha aún no estaba fijada y que se avisará a los desarrolladores con antelación. Más de tres años después, App Store Connect todavía ofrece "Version 1 (deprecated)" como opción al configurar la URL del servidor.

Lo que sí significa la obsolescencia es una congelación. Todos los cambios en el registro de cambios de notificaciones de Apple desde junio de 2023 son cambios de V2: campos nuevos en la transacción firmada, tipos de notificación nuevos, los datos de compromiso de 12 meses añadidos en abril de 2026. Un servidor V1 no ve nada de eso.

Qué señales de reembolso nunca recibe un servidor V1

Así llegan los mismos eventos de reembolso a un servidor V1 y a un servidor V2, según la documentación de Apple para cada versión.

¿V1 sigue recibiendo CONSUMPTION_REQUEST?

Sí, para consumibles. La referencia de V1 de Apple describe CONSUMPTION_REQUEST como la notificación que se envía cuando un cliente inicia una solicitud de reembolso de una compra dentro de la app consumible. Un ingeniero de Apple confirmó en los foros en 2023 que las solicitudes de consumo de V1 se envían para los reembolsos que cumplen los requisitos. La carencia está en las suscripciones. El registro de cambios de Apple fecha las solicitudes de consumo de suscripciones el 11 de abril de 2024, en V2, y la documentación de Send Consumption Information indica que Apple envía la solicitud a tu endpoint V2.

Por qué CANCEL en V1 es fácil de malinterpretar

En V1, cuando Apple reembolsa una suscripción, el tipo de notificación es CANCEL, a menudo acompañado de DID_CHANGE_RENEWAL_STATUS. Muchos servidores tratan cualquier cancelación como un cliente que desactiva la renovación automática, lo que mantiene el acceso hasta que termina el periodo. V2 elimina la ambigüedad. Un reembolso llega como REFUND, y un cliente que desactiva la renovación llega como DID_CHANGE_RENEWAL_STATUS con el subtipo AUTO_RENEW_DISABLED.

Lo que cuesta en dinero quedarse en V1

Apple decide cada reembolso del App Store. El CONSUMPTION_REQUEST es el único momento en que tus datos de uso llegan a esa decisión, y Apple te pide que respondas en un plazo de 12 horas. En V1, los reembolsos de suscripciones se saltan ese paso.

Veamos un ejemplo con cifras ilustrativas. Supón que tu app vende una suscripción mensual de $9.99 que incluye generaciones de imágenes con IA. Un suscriptor hace 400 generaciones en un mes, y cada una te cuesta dinero real en inferencia del modelo. Luego pide un reembolso a Apple.

El pago que pierdes es tu parte, no el precio de venta. Apple paga el 70% del precio de una suscripción, menos los impuestos aplicables, durante el primer año de servicio de pago de un suscriptor, y el 85% después de ese año o para los miembros del App Store Small Business Program. La factura de cómputo no se reduce con él. La inferencia, las llamadas a API de terceros y el almacenamiento de archivos se pagaron cuando el cliente los usó.

Las dos notificaciones de resultado que faltan también cuestan dinero. Sin REFUND_REVERSED, un servidor que revocó el acceso por un reembolso nunca lo restaura cuando Apple revierte el reembolso, así que un cliente que paga se queda bloqueado y escribe a soporte. Sin REFUND_DECLINED, no puedes distinguir un reembolso que sigue pendiente de uno que Apple rechazó.

Cómo migrar de V1 a V2 sin perder ningún reembolso

Pasar a V2 es un cambio en el servidor más un ajuste. La propia guía de Apple en los foros, de un App Store Commerce Engineer en diciembre de 2025, explica qué ocurre el día que haces el cambio.

Crea el endpoint V2 antes de cambiar el ajuste

• Acepta un POST cuyo cuerpo lleve un signedPayload. Los payloads de V2 son JWS firmados por Apple, así que verifica la firma antes de confiar en nada de su contenido. La App Store Server Library de Apple lo hace por ti.
• Traslada el manejo de CANCEL a REFUND, y trata REFUND_DECLINED y REFUND_REVERSED como casos nuevos.
• Responde a CONSUMPTION_REQUEST para suscripciones con Send Consumption Information, y solo cuando el cliente haya dado su consentimiento para compartir datos con Apple. Apple indica que sin consentimiento no debes responder.
• Devuelve HTTP 200 a 206 si todo va bien. Cualquier 40x o 50x hace que Apple reintente.

Cambia el ajuste en App Store Connect

En App Store Connect, abre tu app, elige App Information en General, busca App Store Server Notifications y configura la Production Server URL con tu endpoint V2 y Version 2 seleccionada. Haz lo mismo primero con la URL de sandbox si quieres probar, y usa Request a Test Notification para confirmar que tu servidor responde.

Mantén activo el manejador V1 durante unos tres días

Tras el cambio, las notificaciones nuevas llegan en formato V2 de inmediato, para todas las suscripciones, antiguas o nuevas. Las notificaciones V1 que ya están en reintento siguen llegando en formato V1 hasta que se entregan o se agotan. Apple sitúa el último reintento V1 posible en unas 78 horas, que son 6 más 24 más 48. Deja el manejador antiguo funcionando más allá de ese plazo y después elimínalo.

Sustituye verifyReceipt de paso

verifyReceipt quedó obsoleto el mismo día. Sigue respondiendo, pero Apple dirige a los servidores a la App Store Server API. Get Transaction Info devuelve una transacción firmada, Get Transaction History devuelve el historial de un cliente y Get Refund History enumera todas las compras reembolsadas de un cliente. Junto con las notificaciones V2, cubren lo que la mayoría de los servidores hacía con los recibos, incluido el campo cancellation_date que antes marcaba un reembolso en un recibo.

RefundHalt se conecta a App Store Server Notifications V2 y responde a cada CONSUMPTION_REQUEST dentro del plazo de 12 horas, usando el uso que tu app ya registra. Si sigues en V1, el cambio es el paso que hace posible todo eso.