Respuesta rápida: Cuando un cliente le solicita a Apple un reembolso por una compra dentro de la app o una suscripción, el App Store envía a tu servidor una notificación CONSUMPTION_REQUEST y te da aproximadamente 12 horas para responder con datos de consumo a través del endpoint Send Consumption Information. Apple considera esos datos en su decisión. Si no respondes a tiempo, Apple decide sin tu aporte, y los reembolsos injustificados suelen otorgarse por defecto. Automatizar esta respuesta significa que cada solicitud se responde dentro de la ventana, todas las veces.
La versión resumida
Apple es dueño de los rieles de pago. Cuando alguien compra una suscripción o una compra dentro de la app, Apple cobra el dinero, se queda con su comisión y gestiona los reembolsos. Durante años, los desarrolladores no tuvieron ninguna voz en las decisiones de reembolso.
Eso cambió. Ahora Apple te permite enviar información de consumo, evidencia estructurada sobre cómo el cliente usó lo que compró, y la incorpora en la decisión de reembolso. No eres tú quien aprueba o rechaza el reembolso; Apple sigue teniendo la decisión final. Pero el silencio no le da a Apple nada con qué trabajar, y una respuesta bien elaborada le da contexto.
El problema está en el tiempo y la consistencia. La ventana de reembolso es corta, el tiempo de respuesta para reembolsos de Apple es limitado, se abre en horarios impredecibles, y hacerlo manualmente con cualquier volumen real es imposible. Ese es el problema que resuelve la automatización.
Cómo funciona en realidad el flujo de reembolsos de Apple
Esta es la secuencia, de principio a fin:
El cliente solicita un reembolso. Va a reportaproblem.apple.com, elige la compra, selecciona un motivo y envía la solicitud.
Apple notifica a tu servidor. Para las compras elegibles, el App Store envía una notificación CONSUMPTION_REQUEST a través de App Store Server Notifications V2. El payload contiene datos de transacción firmados que identifican la compra.
Tú respondes con datos de consumo. Llamas a Send Consumption Information con el ID de transacción original y un cuerpo ConsumptionRequest estructurado que describe la entrega, el uso, el consentimiento y tu preferencia de reembolso.
Apple decide. Su sistema de decisión de reembolsos considera tus datos junto con el historial del cliente y otros factores, y luego emite una decisión.
Se te notifica el resultado. Una notificación REFUND significa que el reembolso fue otorgado; una notificación REFUND_DECLINED (para solicitudes iniciadas mediante la API de StoreKit) significa que no lo fue.
Qué contiene un CONSUMPTION_REQUEST y qué envías de vuelta
La notificación en sí lleva información de transacción firmada y el motivo declarado por el cliente (consumptionRequestReason). Tu respuesta es donde ocurre el trabajo real. Apple define un ConsumptionRequest estructurado con campos que incluyen:
Aquí está la tabla reconstruida a partir de tu imagen:
Campo | Qué le indica a Apple |
customerConsented | Si el cliente aceptó compartir estos datos. Debe ser true o Apple rechaza el envío. |
consumptionStatus | Si el contenido comprado no se consumió, se consumió parcialmente o se consumió por completo. |
deliveryStatus | Si el valor o servicio dentro de la app realmente se entregó. |
accountTenure | Cuánto tiempo lleva el cliente con una cuenta contigo. |
playTime | Cuánto tiempo ha pasado el cliente en la app. |
lifetimeDollarsPurchased | El total que el cliente ha gastado en todas tus apps. |
lifetimeDollarsRefunded | El total reembolsado anteriormente al cliente. |
sampleContentProvided | Si el cliente pudo probar el contenido antes de comprar. |
userStatus | El estado actual de la cuenta del cliente (activa, suspendida, etc.). |
refundPreference | Tu recomendación a Apple: undeclared, prefer grant o prefer decline. |
Tu recomendación a Apple: undeclared, prefer grant o prefer decline.
Cada campo es una señal. Si se deja en blanco, es contexto que Apple nunca recibe. Analizamos cada campo y sus valores aceptados en What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown.
La ventana de 12 horas
Tienes alrededor de 12 horas para responder a un CONSUMPTION_REQUEST en producción. Este plazo de consumption_request es fundamental porque, si lo pierdes, renuncias a la oportunidad de dar tu aporte; Apple decide con lo que ya tiene.
El problema no es la duración de la ventana de respuesta para reembolsos de Apple, es el momento en que se abre. Las solicitudes de reembolso no esperan al horario laboral. La ventana de reembolso puede abrirse de madrugada, un fin de semana o durante un feriado, y una cola de revisión manual no puede cubrir eso sin alguien permanentemente de guardia. Esta es la razón más común por la que los desarrolladores pierden reembolsos que podrían haber contestado: no por una mala respuesta, sino por la ausencia de respuesta. Profundizamos en esto en The 12-Hour Window: Why Most Developers Lose Refunds by Default.
El requisito de consentimiento: no te lo saltes
Esta es la parte en la que casi todos se tropiezan, y es un tema legal, no solo técnico.
El CONSUMPTION_REQUEST de Apple no te indica si el cliente dio su consentimiento para compartir sus datos. Esto es intencional: Apple espera que tu app, no tu servidor, recopile y confirme el consentimiento antes de enviar cualquier dato de consumo. Debes establecer customerConsented como true en tu llamada a la API, y tú, como desarrollador, eres el único responsable de haber obtenido un consentimiento válido, porque eres quien comparte los datos que recopilaste del usuario.
Si te equivocas en esto, no solo arriesgas que se rechace el envío, también arriesgas un problema de cumplimiento con el GDPR o el DPDP. Gestiona el consentimiento correctamente en los términos de tu app y en el flujo de compra antes de automatizar nada. Explicamos exactamente dónde y cómo en Customer Consent & the Consumption API: What Apple Actually Requires.
Qué requiere en realidad automatizar esto
Sobre el papel, automatizar la respuesta suena como un proyecto de un fin de semana: capturar la notificación, completar los campos, llamar al endpoint. En producción, es una pieza de infraestructura permanente, y entender lo que realmente implica es la diferencia entre "lo construiremos" y "lo dejaremos pasar".
Un sistema de respuesta interno confiable tiene que recibir y verificar las notificaciones firmadas de Apple, obtener datos de uso y facturación precisos y actualizados al instante para cada cliente en el momento en que llega una solicitud, mapear esos datos a los valores exactos de ConsumptionRequest de Apple, y enviarlos dentro de la ventana de respuesta para reembolsos de Apple de ~12 horas, a cualquier hora, sin que haya una persona vigilando. Además, necesita reintentos seguros ante el plazo, manejo de fallos, registros que puedas auditar, monitoreo para saber si algo se rompe, y mantenimiento continuo cada vez que Apple modifica sus payloads o campos. Nada de eso es tu producto. Todo eso es infraestructura que tendrías que mantener indefinidamente para un flujo de trabajo que no tiene nada que ver con lo que hace tu app. (Profundizamos en la capa de notificaciones en Setting Up App Store Server Notifications V2.)
Ese es el cálculo al que llegan la mayoría de los equipos: la mecánica se puede entender, pero construir y supervisar un sistema de respuesta conforme y seguro ante el plazo es un costo permanente sin ningún beneficio para la app en sí. Es exactamente el tipo de trabajo de infraestructura genérica para el que existe un servicio administrado.
Eso es lo que hace RefundSensor. Se conecta a tu configuración de App Store Connect con una sola URL de webhook, sin SDK, sin cambios de código, sin volver a enviar la app, y luego responde automáticamente a cada CONSUMPTION_REQUEST dentro de la ventana de reembolso de Apple, mapea los campos a partir de tus datos, gestiona los reintentos y el monitoreo, se mantiene actualizado con los cambios de Apple, y registra cada resultado en un solo dashboard. Para los equipos que buscan un software de automatización de reembolsos de Apple, esto elimina la necesidad de construir y mantener tú mismo toda la infraestructura de respuesta a reembolsos.
¿Responder realmente reduce los reembolsos?
Sí, aunque los resultados varían y Apple siempre decide. Enviar datos de consumo precisos le da al sistema de Apple más contexto, y los desarrolladores que responden de manera consistente generalmente ven menos reembolsos otorgados que los desarrolladores que dejan las solicitudes sin respuesta. Elegir una recomendación "prefer decline", cuando tu evidencia realmente la respalda, es un dato más que Apple considera.
Por eso, responder dentro del tiempo de respuesta para reembolsos de Apple puede ayudar a garantizar que Apple reciba tu información antes del plazo de consumption_request. No garantiza un resultado, pero evita que una respuesta perdida sea la razón por la que tu información no se consideró.
Qué puede y qué no puede hacer la automatización
Sé honesto contigo mismo sobre el límite:
No puede garantizar que se rechace ningún reembolso en particular. Apple toma la decisión final, siempre.
No puede contestar reembolsos que nunca generan un CONSUMPTION_REQUEST, ya que no todos los reembolsos lo generan.
Puede asegurarse de que cada solicitud elegible se responda dentro de la ventana de respuesta para reembolsos de Apple, con datos consistentes y precisos, para que nunca pierdas un reembolso simplemente porque nadie vio la notificación.
Puede automatizar cómo responder a las solicitudes de reembolso de Apple dentro de las 12 horas, reduciendo el riesgo de perder el plazo de consumption_request.
Ese último punto es donde está el verdadero valor. No estás anulando a Apple, estás asegurándote de siempre tener tu turno para hablar.
Por qué la gestión manual no puede cerrar la brecha
Los equipos que intentan manejar esto a mano suelen terminar en uno de estos tres escenarios:
El enfoque de "ya lo revisamos en la mañana" — que se pierde todas las solicitudes nocturnas y de fin de semana, es decir, una gran parte de ellas.
La guardia rotativa — alguien técnicamente responsable de una tarea con ventana de 12 horas las 24 horas del día, lo cual es un trabajo miserable y de todos modos propenso a errores humanos.
El enfoque de "nos rendimos" — la mayoría silenciosa, que dejó de responder porque mantener el ritmo era imposible.
El hilo común: el plazo tiene velocidad de máquina y la respuesta tiene velocidad humana. No puedes superar con disciplina a un reloj que sigue corriendo mientras duermes. En el fondo, todo enfoque manual es simplemente elegir qué solicitudes vas a perder.
Esto es un problema de tiempo, no un problema de producto
El replanteamiento que importa: perder estos reembolsos no dice nada sobre tu app.
Puedes tener un gran producto, usuarios satisfechos y una tasa de reembolsos genuinos baja, y aun así perder ingresos por esta ventana porque las pérdidas no tienen que ver con si el reembolso era merecido. Tienen que ver con si había alguien ahí para responder. Eso, curiosamente, son buenas noticias. Un problema de producto es difícil de resolver. Un problema de tiempo tiene una solución clara: asegurarte de que siempre haya algo listo para responder, al instante, sin importar la hora.
Qué lo resuelve en realidad
Lo único que cierra una ventana de velocidad de máquina es una respuesta de velocidad de máquina. La automatización responde a cada CONSUMPTION_REQUEST en el momento en que llega con datos de consumo precisos y tu preferencia de reembolso dentro de la ventana de Apple, a las 3 a.m. de un domingo con la misma fiabilidad que a las 3 p.m. de un martes.
Eso es lo que hace RefundSensor. Detecta cada solicitud de reembolso, responde automáticamente dentro de la ventana y registra el resultado, para que nunca más pierdas un reembolso simplemente porque nadie vio la notificación. La configuración toma unos 30 minutos sin cambios de código, y también cubre la ventana de revisión de contracargos de Google Play, que tiene el mismo problema de "se abre cuando quiere, se cierra rápido". (Para ver el panorama completo, consulta How to Automate Apple Refund Requests y Google Play Refunds & Chargebacks.)
[MARCADOR DE DATOS DEL PRODUCTO: inserta una estadística real de RefundSensor aquí cuando el Refund Index esté activo, por ejemplo, la proporción de solicitudes que llegan fuera del horario laboral, o el dinero defendido. NO inventes un número.]
No estás haciendo trucos con Apple. Solo te estás asegurando de tener siempre tu turno para hablar el turno que la mayoría de los desarrolladores pierde sin darse cuenta.
Fuentes oficiales {#official-sources}
Los tiempos y el proceso de Apple pueden cambiar, así que considera su documentación como la autoridad final:
La ventana se abre cuando tus clientes quieren. Está presente de todos modos. RefundSensor responde automáticamente a cada solicitud de reembolso de Apple, dentro de la ventana de 12 horas 3 a.m., fines de semana y feriados incluidos y registra cada resultado. Unos 30 minutos para configurarlo, sin cambios de código. Comenzar gratis →
Enlaces internos por agregar una vez publicado: contenido principal sobre automatización de reembolsos de Apple · CONSUMPTION_REQUEST campo por campo · contenido principal sobre reembolsos de Google Play.
Preguntas frecuentes
Alrededor de 12 horas en producción, a partir del momento en que el cliente envía la solicitud. Si no respondes a tiempo, Apple decide sin tu aporte.
Apple procede con la información que tiene, que es la solicitud del cliente y nada de tu parte. Las solicitudes sin respuesta, incluso las injustificadas, suelen otorgarse por defecto.
No. La ventana la establece Apple. La única forma confiable de cumplir siempre con el plazo es responder automáticamente en el momento en que llega la solicitud.
Por lo general, no es por el fondo del caso, sino por el momento en que llegan. Las solicitudes llegan fuera del horario laboral y un proceso manual no puede responder a todas a tiempo, por lo que los reembolsos que se podían contestar se pierden por defecto.
No. Apple siempre toma la decisión final. La automatización garantiza que respondas siempre; no anula la decisión de Apple.
