Pregunta a la mayoría de los equipos si hacen seguimiento de los reembolsos de Apple y te dirán que sí. Pregúntales qué almacenan y resulta que es una fila por reembolso, escrita después del hecho, con una fecha y un monto.
Eso es un registro, no seguimiento. Te dice que hubo un reembolso. No te dirá si Apple te preguntó algo en el camino, si alguien respondió, si la respuesta se procesó o si el acceso de ese cliente coincide con la realidad.
La brecha importa porque partes de este proceso expiran. Apple da una ventana de 12 horas para un paso, y una vez que pasa no hay forma de reabrirla. Si buscas la perspectiva general en lugar de la mecánica del seguimiento, nuestra guía sobre cómo gestionar los reembolsos del App Store sin perder ingresos de tu app móvil cubre ese tema. Esta trata de qué registrar y cuándo actuar.
Puntos clave
• Apple toma la decisión final sobre el reembolso. Los desarrolladores no aprueban ni rechazan solicitudes.
• Una solicitud de reembolso pasa por varios estados distintos. Almacenar solo el último pierde la mayor parte de la información útil.
• Algunos flujos de reembolso te dan la oportunidad de enviar información de consumo, con consentimiento, dentro de 12 horas.
• Enviar una respuesta y que sea aceptada son cosas distintas. Registra el resultado, no el intento.
• El resultado del reembolso tiene que llegar a tu lógica de entitlements y a tus registros de ingresos, o el seguimiento no ha terminado.
• La automatización sobre todo evita eventos perdidos y ventanas vencidas. No tiene ninguna influencia en lo que Apple decide.
¿Qué es el seguimiento de solicitudes de reembolso de Apple?
El seguimiento de solicitudes de reembolso de Apple consiste en seguir una solicitud de reembolso por cada estado que atraviesa de tu lado, desde la primera notificación hasta la actualización del entitlement que la cierra. No es un registro de reembolsos. Es un registro de un proceso.
Esos estados importan porque son eventos genuinamente distintos, y los equipos suelen fundirlos en uno solo:
Estado | Qué te indica |
Solicitud recibida | Existe una solicitud de reembolso y Apple te lo ha comunicado |
Oportunidad de respuesta abierta | Apple está pidiendo información y el reloj está corriendo |
Respuesta enviada | Devolviste algo |
Respuesta aceptada | Apple realmente la aceptó — no es lo mismo que enviarla |
Reembolso aprobado | Apple concedió el reembolso |
Reembolso rechazado | Apple no lo concedió |
Reembolso revertido | Apple deshizo un reembolso que había concedido antes |
Entitlement actualizado | Tu app ahora refleja el resultado |
Solo la última fila trata de tu producto. Todo lo anterior determina si esa fila queda bien. Un equipo que almacena únicamente “reembolso aprobado” no puede explicar por qué un cliente sigue teniendo acceso, ni si alguien respondió cuando Apple preguntó.
¿Cómo hacen seguimiento los desarrolladores a las solicitudes de reembolso de Apple?
Los desarrolladores hacen seguimiento de la actividad de reembolsos de Apple a través del sistema de notificaciones del lado del servidor de Apple y de sus propios registros de transacciones. La ruta exacta depende del tipo de evento y de si Apple pide información. Los eventos llegan a una URL que configuras mediante App Store Server Notifications, como payloads firmados que tu backend verifica y procesa.
Hay dos tipos de eventos relacionados con reembolsos que vale la pena separar en tu handler. Uno te pide algo. Los otros te cuentan qué pasó.
El que pide es una notificación CONSUMPTION_REQUEST de Apple. Significa que Apple quiere información sobre una compra mientras evalúa una solicitud de reembolso. No es un reembolso, y conviene escribir el handler de modo que no asuma que siempre llega una.
Los que cuentan cubren los resultados: REFUND cuando se concede, REFUND_DECLINED cuando no, y REFUND_REVERSED cuando Apple deshace un reembolso que había concedido antes. El tercero es el que la mayoría de los handlers olvida.
Debajo de ambos está tu propio almacén de transacciones, que es lo que hace legible todo lo anterior. Las notificaciones hacen referencia a los identificadores de Apple, así que sin un registro de compra con el que cruzarlas, tienes un evento que no puedes vincular a nada.
¿Qué información deberían registrar los desarrolladores?
Divídela según de dónde proviene la información, porque solo uno de los lados es autoritativo.
De Apple, en el payload de la transacción: el identificador de la transacción y el identificador de la transacción original, el identificador del producto, la fecha de compra y, en transacciones reembolsadas, una fecha de revocación y un motivo de revocación. Ese campo de motivo distingue los reembolsos emitidos por un problema en la app de los emitidos por otras razones, lo cual es más útil de lo que parece.
El token de cuenta queda en el medio. Tú lo generas y lo adjuntas al momento de la compra, y Apple lo devuelve en el payload, que es lo que te permite ir de una transacción a un usuario identificado.
Todo lo demás lo mantienes tú: el identificador interno del usuario, el tipo de notificación y cuándo llegó, si se requería una respuesta, qué enviaste y qué recibiste, el estado de la suscripción en ese momento, el estado del entitlement después del procesamiento y el período de reporte en el que cayó el reembolso.
Las dos marcas de tiempo son, discretamente, los campos más útiles del conjunto. La distancia entre el evento de Apple y tu acción es la única medida honesta de si tu seguimiento funciona.
Cómo hacer seguimiento de los reembolsos del App Store paso a paso
1. Recibe el evento relacionado con el reembolso
Los eventos llegan al endpoint del servidor que configuraste. Si está mal configurado o falla, los reembolsos siguen su curso y tú simplemente nunca te enteras, sin ningún error de tu lado.
2. Valida la notificación
Verifica la firma contra la cadena de certificados de Apple y confirma el bundle ID antes de actuar sobre el payload. Un endpoint que confía en todo lo que recibe es uno en el que cualquier otro puede escribir.
3. Identifica la transacción relacionada
Cruza los identificadores del payload decodificado con tus registros de compra y luego resuélvelos a una cuenta de usuario. Si adjuntaste un token de cuenta al momento de la compra, esto es una búsqueda y no una investigación.
4. Comprueba si Apple está pidiendo información
Ramifica según el tipo de notificación. Una solicitud de consumo necesita una ruta de respuesta. Una notificación de resultado necesita una actualización de estado. Tratarlas igual es como se pierden las ventanas de respuesta.
5. Reúne la información de consumo admitida
Extrae los valores de tus propios registros: si la compra fue entregada, si se proporcionó contenido de muestra, cuánto se consumió. La documentación de Send Consumption Information de Apple establece los campos y sus valores válidos. Antes de cualquier cosa, verifica el consentimiento — Apple exige un consentimiento válido del cliente para compartir los datos, obtenerlo es responsabilidad del desarrollador y las solicitudes sin él se rechazan de plano.
6. Envía dentro de la ventana documentada
La documentación actual de Apple pide una respuesta dentro de las 12 horas posteriores a la notificación. Envía valores precisos y confirma que la llamada tuvo éxito en lugar de asumirlo.
7. Registra el resultado final
Registra qué notificación de resultado llegó y cuándo. Si tu pipeline perdió eventos durante una caída, la API de servidor de Apple expone el historial de reembolsos que puedes usar para recuperar lo que te faltó — conviene ejecutarlo como una conciliación periódica en lugar de confiar solo en las notificaciones.
8. Actualiza el entitlement y el acceso
Revoca cuando se concede un reembolso, restaura cuando hay una reversión y maneja el caso prorrateado en el que solo se revoca parte de una transacción. Impúlsalo desde eventos del lado del servidor para que el estado sea correcto sin importar si el cliente vuelve a abrir la app o no.
9. Concilia con los registros de ingresos
Vincula el reembolso al período y al producto correctos. Sin esto, ingeniería y finanzas terminan con versiones distintas del mismo mes.
Cómo responder a las solicitudes de reembolso de Apple
Respondes enviando información de consumo cuando Apple la pide, con consentimiento, dentro de la ventana. No respondes aprobando ni rechazando nada, porque eso no está disponible para los desarrolladores. Apple toma la decisión.
Lo que envíes debe describir lo que realmente ocurrió con la compra, extraído de tus registros. No una estimación, ni una cifra inclinada hacia el resultado que preferirías — además de ser deshonesto, son datos que obtuviste consentimiento para compartir con precisión.
Aquí está el punto operativo que la mayoría de las configuraciones de seguimiento pasan por alto. Enviar una respuesta y que sea aceptada son dos estados distintos. La llamada puede fallar la validación y devolver un error, y si nadie revisa el resultado, un envío fallido se ve exactamente igual que uno exitoso en tus logs. Almacena el estado de la respuesta, no solo el hecho de que lo intentaste.
¿Qué pasa después de que Apple decide sobre un reembolso?
Apple envía el resultado como una notificación y revierte el cargo de su lado. Luego el trabajo pasa a ti.
La distinción que vale la pena retener: un reembolso aprobado por Apple es un evento, y que tus sistemas lo reflejen correctamente es otro. La mitad de Apple se completa sin importar lo que hagas. La tuya se completa solo si la notificación llegó, coincidió con una transacción, se resolvió a una cuenta y actualizó el acceso de esa cuenta.
Cuando esas dos divergen, obtienes clientes que fueron reembolsados y aún conservan todo lo que pagaron. Nadie lo reporta, porque desde su lado nada está mal. Aparece en la conciliación meses después, si es que aparece.
Las suscripciones necesitan especial cuidado, ya que un período reembolsado normalmente termina la suscripción en lugar de dejarla activa, y tu estado debería reflejarlo. Soporte también necesita el registro, para que un agente pueda ver qué pasó sin pedirle a alguien que revise un dashboard.
Por qué el seguimiento manual de reembolsos de Apple se vuelve difícil
No por descuido. El trabajo simplemente no coincide con la disponibilidad de las personas.
Las solicitudes de reembolso llegan cuando los clientes las envían, y cualquier ventana de respuesta sigue corriendo de noche y los fines de semana. Cada evento necesita una búsqueda, una coincidencia de cuenta, una verificación de consentimiento, una cifra de uso, un envío y una actualización de entitlement. Tareas pequeñas, pero con tiempo limitado y repetitivas, e invisibles cuando salen bien.
Luego la escala cambia su forma. Varias apps, datos de transacciones en un sistema y datos de cuentas en otro. Los datos históricos de reembolsos se quedan escasos porque nadie los completó retroactivamente, los desajustes de entitlements se acumulan sin señalarse, y finanzas saca a la luz la discrepancia en el cierre de trimestre — mucho después del punto en que una ventana de respuesta importaba.
¿Se puede automatizar el seguimiento de reembolsos de Apple?
Sí, y la mayor parte debería automatizarse, porque casi todos los pasos son determinísticos.
La automatización puede monitorear y verificar eventos de reembolso, registrar cada solicitud a medida que llega, resolver transacciones a cuentas, ramificar según el tipo de notificación, ensamblar los datos de consumo desde tus registros, controlar las ventanas de respuesta y los resultados de los envíos, actualizar el estado de los entitlements y mantener el historial de reembolsos consultable.
Lo que no puede hacer es influir en Apple. La automatización no hará que los reembolsos sean menos probables ni puede inclinar una decisión en ningún sentido. Lo que cambia es si tu parte del proceso ocurre de forma consistente, y dentro de la ventana.
Cómo ayuda RefundSensor con la gestión de reembolsos de Apple
La gestión de reembolsos del App Store es la categoría a la que pertenece este trabajo, y RefundSensor está construido para el lado del desarrollador: monitorear los flujos de reembolso de Apple, automatizar los pasos de respuesta admitidos y mantener los eventos, resultados y registros de reembolsos en un solo lugar en vez de repartidos entre dashboards.
En la práctica, la respuesta ocurre dentro de la ventana de la tienda sin que alguien vigile las notificaciones, y el registro de reembolsos se mantiene preciso a medida que crece el volumen.
No cambiará las decisiones de Apple, y ningún software de gestión de reembolsos de Apple puede hacerlo. Lo que cambia es cuánto trabajo manual deja detrás cada solicitud.
Dónde están documentadas estas reglas
Tres fuentes de Apple respaldan las afirmaciones técnicas anteriores. Léelas directamente y vuelve a consultarlas periódicamente — esta área ha cambiado más de una vez.
Solicitar un reembolso de apps o contenido — el proceso de cara al cliente. Útil para entender dónde se originan las solicitudes, la actualización de 24 a 48 horas que se les indica esperar a los clientes y la nota de Apple de que la elegibilidad varía según el país o la región.
Send Consumption Information — el flujo de respuesta del desarrollador: el requisito de consentimiento, la ventana de 12 horas y los campos de la solicitud. Léelo antes de construir cualquier manejo de respuestas.
App Store Server Notifications — cómo llegan los eventos de reembolso a tu backend, el formato del payload firmado y los tipos de notificación, incluidos CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED y REFUND_REVERSED.
Si los eventos de reembolso todavía se vigilan a mano
El seguimiento manual aguanta hasta el día en que una notificación llega a las 2 a.m. y la ventana se cierra antes de que alguien abra un dashboard. La falla es silenciosa, y eso es lo que la hace costosa.
Si eso describe tu configuración, RefundSensor se encarga del lado del desarrollador en los flujos de reembolso de Apple monitoreando los eventos, manteniendo las respuestas dentro de la ventana y asegurando que los resultados lleguen a tus registros y a tu lógica de entitlements.
Preguntas frecuentes
A través de App Store Server Notifications y de tus propios registros de transacciones. Los eventos llegan a un endpoint del servidor configurado como payloads firmados. Los verificas, resuelves la transacción a un cliente, registras el evento, respondes si Apple ha pedido información y almacenas el resultado cuando llega.
Seguir una solicitud de reembolso por cada estado que atraviesa del lado del desarrollador: solicitud recibida, oportunidad de respuesta, respuesta enviada y aceptada, resultado de Apple y la actualización del entitlement que la cierra. Almacenar solo el resultado final pierde la información que necesitas para explicar qué pasó.
Sí. Apple envía el resultado como una notificación de servidor. REFUND significa que se concedió, REFUNDDECLINED significa que no, y REFUNDREVERSED significa que se deshizo un reembolso concedido anteriormente. Las transacciones reembolsadas también incluyen una fecha de revocación y un código de motivo en el payload de la transacción.
Enviando información de consumo cuando Apple la solicita, siempre que exista un consentimiento válido del cliente, con valores precisos tomados de tus propios registros. No puedes aprobar ni rechazar un reembolso. Tu respuesta es una entrada más en la revisión de Apple, y deberías confirmar que el envío tuvo éxito en lugar de asumirlo.
Una App Store Server Notification que le indica a tu servidor que Apple quiere información sobre una compra mientras evalúa una solicitud de reembolso. No es una notificación de reembolso ni una decisión. Responder requiere el consentimiento del cliente, y Apple pide la respuesta dentro de 12 horas.
La documentación actual de Apple pide una respuesta dentro de las 12 horas posteriores a la notificación. Las solicitudes llegan a cualquier hora, así que este es el paso que mejor se presta a la automatización. Confirma el requisito vigente en la página de Apple en lugar de confiar en una integración antigua.
Nada, a menos que tú lo cambies. Que Apple revierta el cargo no altera tu base de datos. Tu backend debería revocar el entitlement cuando se concede un reembolso, restaurarlo si Apple revierte el reembolso y manejar el caso en que solo se revoca parte de una transacción.
Las partes mecánicas sí. Verificar notificaciones, cruzar transacciones con cuentas, controlar ventanas de respuesta y resultados de envío, actualizar entitlements y mantener el historial de reembolsos son tareas determinísticas. Lo que sigue siendo humano es diseñar el flujo de consentimiento e interpretar lo que los patrones de reembolso dicen sobre el producto.
