Respuesta rápida: Cuando un cliente le pide 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 alrededor de 12 horas para responder con datos de consumo a través del endpoint Send Consumption Information. Apple tiene en cuenta esos datos en su decisión. Si no respondes a tiempo, Apple decide sin tu aporte y los reembolsos injustificados a menudo se aprueban de forma predeterminada. Automatizar esta respuesta significa que cada solicitud se responde dentro del plazo, siempre.
La versión corta
Apple controla los rieles de pago. Cuando alguien compra una suscripción o una compra dentro de la app en tu aplicación, Apple cobra el dinero, se queda con su parte 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 toma en cuenta en la decisión de reembolso. Tú no puedes aprobar o denegar el reembolso por tu cuenta; Apple sigue teniendo la decisión final. Pero el silencio no le da a Apple nada con qué trabajar, y una respuesta bien formada le aporta contexto.
El detalle está en el tiempo y la consistencia. El plazo es corto, se abre en horarios impredecibles, y hacerlo manualmente con cualquier volumen real es imposible. Ese es el problema que resuelve la automatización de reembolsos de Apple.
Cómo funciona realmente el flujo de reembolsos de Apple
Esta es la secuencia, de principio a fin:
El cliente solicita un reembolso. Va a reportaproblem.apple.com, selecciona la compra, elige un motivo y la envía.
Apple notifica a tu servidor. Para las compras elegibles, el App Store envía una notificación CONSUMPTION_REQUEST mediante App Store Server Notifications V2. El payload contiene datos de transacción firmados que identifican la compra. Estas app store server notifications son las que activan el flujo de trabajo automatizado.
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. El endpoint send consumption information es el paso clave de la API en este proceso.
Apple decide. Su sistema de decisión de reembolsos pondera 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 aprobado; una notificación REFUND_DECLINED (para solicitudes iniciadas mediante la StoreKit API) 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 verdadero trabajo. Apple define un ConsumptionRequest estructurado con campos que incluyen:
Campo | Qué le dice a Apple |
customerConsented | Indica si el cliente aceptó compartir estos datos. Debe ser true o Apple rechaza el envío. |
consumptionStatus | Indica si el contenido comprado no se consumió, se consumió parcialmente o se consumió por completo. |
deliveryStatus | Indica si el valor o servicio dentro de la app realmente se entregó. |
accountTenure | Cuánto tiempo lleva el cliente con una cuenta en tu servicio. |
playTime | Cuánto tiempo ha pasado el cliente en la app. |
lifetimeDollarsPurchased | Total que el cliente ha gastado en todas tus apps. |
lifetimeDollarsRefunded | Total que se le ha reembolsado previamente al cliente. |
sampleContentProvided | Indica si el cliente pudo probar el contenido antes de comprarlo. |
userStatus | El estado actual de la cuenta del cliente (activa, suspendida, etc.). |
refundPreference | 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. Desglosamos cada campo y sus valores aceptados en ¿Qué es una notificación CONSUMPTION_REQUEST? Un desglose campo por campo. Los desarrolladores que evalúan una api de reembolsos de Apple también deben entender cómo estos campos encajan en el flujo completo de reembolsos.
El plazo de 12 horas
Tienes alrededor de 12 horas para responder a un CONSUMPTION_REQUEST en producción. Si lo dejas pasar, pierdes la oportunidad de aportar información; Apple decide con lo que ya tiene.
El problema no es la duración del plazo, sino cuándo se abre. Las solicitudes de reembolso no esperan al horario laboral. El plazo puede abrirse de madrugada, un fin de semana o durante un feriado, y una cola de revisión manual no puede cubrir eso sin que alguien esté de guardia permanentemente. Esta es la razón más común por la que los desarrolladores pierden reembolsos que podrían haber impugnado: no una mala respuesta, sino ninguna respuesta. Profundizamos en esto en El plazo de 12 horas: por qué la mayoría de los desarrolladores pierden reembolsos por defecto.
El requisito de consentimiento: no te lo saltes
Esta es la parte en la que casi todos tropiezan, y es un asunto 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 sea tu app, no tu servidor, la que recopile y confirme el consentimiento antes de enviar cualquier dato de consumo. Debes establecer customerConsented en true en tu llamada a la API, y tú, el desarrollador, eres el único responsable de haber obtenido un consentimiento válido, porque eres quien comparte datos que recopilaste del usuario.
Si te equivocas en esto, no solo te arriesgas a un envío rechazado, sino a un problema de cumplimiento con el GDPR o el DPDP. Gestiona el consentimiento correctamente en los términos y el flujo de compra de tu app antes de automatizar nada. Explicamos exactamente dónde y cómo en Consentimiento del cliente y la Consumption API: lo que Apple realmente exige.
Lo que realmente implica automatizar esto
Sobre el papel, automatizar la respuesta suena como un proyecto de 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 vamos a construir" y "lo vamos a omitir".
Un sistema de respuesta interno confiable tiene que recibir y verificar las notificaciones firmadas de Apple, obtener datos precisos y actualizados de uso y facturación de cada cliente en el instante en que llega una solicitud, mapear esos datos a los valores exactos de ConsumptionRequest de Apple, y enviarlos dentro del plazo de ~12 horas, a cualquier hora, sin que nadie esté vigilando. Además, necesita reintentos seguros frente al plazo, manejo de fallas, registros que puedas auditar, monitoreo para saber si algo se rompe, y mantenimiento continuo cada vez que Apple revisa 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 Configuración de App Store Server Notifications V2.)
Ese es el cálculo al que llegan la mayoría de los equipos: la mecánica es comprensible, pero construir y vigilar un sistema de respuesta conforme y seguro frente al plazo es un costo permanente sin ningún beneficio para la app en sí. Es exactamente el tipo de trabajo técnico indiferenciado 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 reenviar la app y luego responde automáticamente a cada CONSUMPTION_REQUEST dentro del plazo de Apple, mapea los campos a partir de tus datos, gestiona los reintentos y el monitoreo, se mantiene al día con los cambios de Apple y registra cada resultado en un solo dashboard. Obtienes el resultado de un sistema de respuesta bien construido sin tener que construirlo ni mantenerlo. Para los equipos que buscan un software de automatización de reembolsos de Apple, esto ofrece una alternativa administrada a mantener el flujo de trabajo internamente.
¿Responder realmente reduce los reembolsos?
Sí, aunque los resultados varían y Apple siempre decide. Enviar datos de consumo precisos le da más contexto al sistema de Apple, y los desarrolladores que responden de forma constante generalmente ven menos reembolsos aprobados que los que dejan las solicitudes sin respuesta. Elegir una recomendación de "prefer decline", cuando tu evidencia realmente lo respalda, es un factor más que Apple considera. Esto puede ser especialmente relevante al gestionar un flujo de reembolso de suscripción a gran escala.
Lo que la automatización puede y no puede hacer
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 impugnar reembolsos que nunca generan un CONSUMPTION_REQUEST, ya que no todos los reembolsos lo hacen.
Sí puede asegurar que cada solicitud elegible se responda dentro del plazo, con datos consistentes y precisos, para que nunca pierdas un reembolso simplemente porque nadie vio la notificación.
Ese último punto es donde está el verdadero valor. No estás anulando a Apple, estás asegurándote de que siempre tengas tu turno para hablar.
Para los detalles específicos, considera los propios materiales de Apple como la autoridad final:
La industria tardó 15 años en conseguir que los desarrolladores tuvieran voz en los reembolsos. Úsala siempre. RefundSensor responde automáticamente a las notificaciones CONSUMPTION_REQUEST de Apple dentro del plazo y registra cada resultado, tanto para Apple como para Google Play.Empieza gratis
Preguntas frecuentes
Es una App Store Server Notification que Apple envía a tu servidor cuando un cliente solicita un reembolso de una compra dentro de la app o suscripción elegible. Es tu señal para responder con datos de consumo que Apple tendrá en cuenta en su decisión de reembolso.
Alrededor de 12 horas en producción. Si no respondes a tiempo, Apple decide sin tu aporte, y las solicitudes sin respuesta a menudo se aprueban de forma predeterminada.
No. Puedes enviar un refundPreference recomendando un rechazo, pero Apple siempre toma la decisión final. La automatización mejora tus probabilidades al garantizar que se envíen datos precisos cada vez, pero no te da poder de veto.
Sí. Debes obtener un consentimiento válido en tu app y establecer customerConsented en true. Apple no recopila esto por ti, y enviar datos sin consentimiento crea un riesgo de cumplimiento de privacidad del que eres responsable.
No. Responder a CONSUMPTION_REQUEST ocurre del lado del servidor mediante App Store Server Notifications y la Consumption API. Con RefundSensor, pegas una URL de webhook en App Store Connect: sin SDK, sin cambios de código, sin reenviar la app.
Apple procede sin tus datos. Pierdes la única oportunidad de brindar contexto, y es más probable que se aprueben los reembolsos, incluidos los injustificados.
