Alguien abre Reportar un problema, elige tu app y le pide a Apple que le devuelva su dinero. Apple no decide sin más. Primero hace ping a tu servidor para preguntarte qué sabes sobre la compra, y espera unas 12 horas por una respuesta.
Ese ping es el Apple CONSUMPTION_REQUEST. Muchos equipos con ingresos reales por IAP nunca han oído hablar de él. Muchos más lo vieron una vez en sus logs y lo dejaron ahí. Si ese es tu caso, nuestra
guía explicativa del Apple CONSUMPTION_REQUEST cubre el qué y el por qué. Este post es la parte de responder. Qué enviar, qué no enviar y qué les pasó a quienes lo intentaron.
Puntos clave
Apple envía un CONSUMPTION_REQUEST cuando un cliente solicita un reembolso. Tienes unas 12 horas. Después de eso, decide sin ti.
La respuesta son cinco campos. No cincuenta. Cinco.
Tu preferencia de reembolso es exactamente eso, una preferencia. Apple ya la ha ignorado antes y lo volverá a hacer.
Sin consentimiento del cliente, no hay respuesta. Palabras de Apple, no nuestras.
Una app pasó de una tasa de reembolso del 3% al 1.9% en unas dos semanas solo por empezar a responder. Nunca le pidió a Apple que rechazara nada.
Nadie hace esto a mano por mucho tiempo. La ventana es demasiado corta y las solicitudes llegan a malas horas.
Entonces, ¿qué es exactamente un Apple CONSUMPTION_REQUEST?
Es una notificación de servidor, una de las muchas que Apple envía a través de App Store Server Notifications V2. Esta se dispara cuando alguien solicita un reembolso de una compra dentro de la app. Antes solo aplicaba a consumibles. Desde la WWDC24 también cubre las suscripciones de renovación automática, que es donde está la mayor parte del dinero.
Dentro del payload: la transacción firmada, el ID del producto y el motivo que eligió el cliente. El documento
consumption Request Reason de Apple enumera cinco: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER.
Lo que no encontrarás es un nombre ni un Apple ID. Solo un identificador de transacción. Convertir eso en "esta es la usuaria 48213 y ha abierto la app 40 veces desde que compró" es tu trabajo, y solo funciona si adjuntaste un appAccountToken en el checkout. Escribimos un
post completo sobre appAccountToken porque mucha gente lo omite.
Apple pregunta, tú respondes, Apple decide. Esa es la forma que tienen las solicitudes de reembolso de Apple para los desarrolladores.
Cómo responder a un Apple CONSUMPTION_REQUEST
Haces un PUT con un pequeño cuerpo JSON al endpoint Send Consumption Information de Apple, con el ID de transacción en la ruta. Ese cuerpo es la información de consumo de Apple que lee el sistema de reembolsos.
Customer Consented va primero. True o false. Si es false, detente. No envíes nada. La documentación de Apple dice que sin consentimiento no debes responder en absoluto. Extraño, pero esa es la regla.
Luego, delivery status. DELIVERED si funcionó. Si no, hay variantes UNDELIVERED para problema de calidad, artículo incorrecto, caída del servidor y otros.
Sample Content Provided es un sí o no sobre si el cliente pudo probar antes de comprar. Prueba gratuita, sí. Vista previa del contenido, sí. Un paywall con tres viñetas, probablemente no.
Consumption Percentage confunde a mucha gente. Está en miliunidades, así que 100000 significa consumido por completo y 50000 significa la mitad. Omítelo en las suscripciones de renovación automática. Apple lo calcula a partir del periodo de facturación.
Y por último, refund Preference. DECLINE, GRANT_FULL o GRANT_PRORATED. Opcional. También es el único lugar donde puedes decir lo que quieres.
Una respuesta para un paquete de monedas que ya se gastó:
Apple responde con un 202 y nada más. Sin veredicto. Un ingeniero de Apple lo dijo en los foros de desarrolladores allá por 2021: un 202 significa que tus datos "se tendrán en cuenta". Esa es toda la promesa.
No envíes DECLINE en todo
Sé que es tentador. Resiste.
Lee primero el motivo. FULFILLMENT_ISSUE significa revisar tus logs de entrega. Si la compra realmente no llegó, envía el estado UNDELIVERED correspondiente con GRANT_FULL y sigue adelante. Esa no la vas a ganar, y al intentarlo tus DECLINE posteriores se ven más débiles.
UNINTENDED_PURCHASE tiene que ver con el uso. ¿Compra a las 9:02, solicitud de reembolso a las 9:05, cero sesiones en medio? Probablemente un toque accidental. Déjalo ir. ¿Uso diario durante una semana? DECLINE, con tu cifra real de consumo adjunta.
UNSATISFIED_WITH_PURCHASE es donde Sample Content Provided se gana su lugar. ¿Tuvo una prueba y usó el 80%? Rechaza. ¿Apenas lo abrió? GRANT_PRORATED es un punto medio justo.
Para LEGAL y OTHER, envía datos precisos y omite la preferencia a menos que tus registros hagan obvia la decisión.
Un DECLINE sobre un 95% de consumo y una prueba gratuita es una respuesta sólida. Un DECLINE sobre algo que se usó noventa segundos parece un acto reflejo.
Lo que realmente les pasó a quienes hicieron esto
Dipsea es una app de audio que RevenueCat compró en septiembre de 2024 y usó para probar su propio gestor de reembolsos. El 23 de octubre empezaron a responder a las consumption requests con la preferencia en "dejar que Apple decida". Sin DECLINE. Solo datos. En unos 15 días la tasa de reembolso bajó de un 3% estable al 1.9%.
Publicaron la gráfica.Para mí ese es el dato más útil sobre este tema. Los datos por sí solos movieron la cifra.
Ahora el otro lado. En marzo de 2024 un estudio de videojuegos publicó en los Apple Developer Forums que estaban enviando información de consumo y Apple seguía aprobando "casi todos" los reembolsos de monedas que los jugadores ya habían gastado. Los consumibles son el caso difícil. Una vez que las monedas se gastaron, Apple no puede recuperarlas. Si no revocas el saldo tú mismo tras la notificación REFUND, pierdes el dinero y las monedas.
Y en mayo de 2025 un hilo en r/iOSProgramming se llenó de usuarios de RevenueCat que habían configurado "preferir siempre rechazar" y de repente vieron que se aprobaban todos los reembolsos. RevenueCat dijo que fue un cambio de política del lado de Apple. Sea cual sea la causa, zanjó una vieja discusión. Refund Preference no es un interruptor. El DECLINE indiscriminado es un patrón, y Apple puede aprender a ignorarlo.
Formas de recibir un 400
Apple es estricta con el cuerpo de la solicitud. Estos son los errores que vemos una y otra vez.
El tema de las miliunidades. Alguien lee "porcentaje", envía 100 y acaba de decirle a Apple que el cliente usó una décima de un uno por ciento. El rango va de 0 a 100000.
Un porcentaje distinto de cero en un artículo no entregado. Si delivery Status no es DELIVERED, Consumption Percentage tiene que ser 0 o la solicitud rebota.
Cualquier porcentaje en una suscripción de renovación automática. Apple tiene un error específico para eso. Omítelo.
La clave equivocada. Esta llamada requiere una clave de In-App Purchase, generada en App Store Connect en Usuarios y acceso, luego Integraciones. No la clave de la App Store Connect API, aunque se vean idénticas. Con la equivocada recibes un 401 y una hora dudando de tu JWT.
Saltarse el consentimiento. No es un error HTTP, es uno de cumplimiento. Incluye el texto en tus términos antes de que esto entre en producción.
Prueba primero en sandbox. Un detalle: la documentación de pruebas de Apple te da cinco minutos ahí, no doce horas. Si tu servidor tarda seis, la prueba ignora tus datos. Para forzar un rechazo, elige Otro en la hoja de reembolso y escribe DECLINE.
Cómo gestionan los desarrolladores las solicitudes de reembolso del App Store cuando son muchas
Sobre todo no gestionándolas, si somos francos. La solicitud llega a las 3 a.m. O el sábado. O en un feriado, cuando la única persona que entiende el pipeline está desconectada. Pasan doce horas. Apple falla según la palabra del cliente.
Cómo gestionar las solicitudes de reembolso de Apple como desarrollador se reduce a una decisión. Construir la cadena tú mismo (verificar el JWS, buscar al usuario, extraer el uso, calcular el porcentaje, generar un JWT, llamar al endpoint, registrarlo, reintentar) y mantenerla funcionando para siempre. O conectar un software de gestión de reembolsos de Apple que ya lo hace.
Refund Sensor es una opción en ese segundo grupo. Pegas nuestra URL de notificaciones en App Store Connect, conectas la clave y las respuestas salen en segundos. En las apps que lo usan ahora mismo, el 77% de las solicitudes elegibles se han defendido, con alrededor de $33 protegidos por caso. No hay nada ingenioso detrás. Una respuesta con datos reales sale cada vez, antes del plazo. Si prefieres comparar opciones, nuestra guía de herramientas de gestión de reembolsos de Apple
cubre qué preguntar.
Por eso la automatización de reembolsos de Apple para desarrolladores sigue apareciendo. Doce horas, cada solicitud, cada semana, no es una tarea para humanos. Elijas lo que elijas, elige algo. El silencio significa que Apple solo escucha a una de las partes.
Preguntas frecuentes
Doce horas en producción, cinco minutos en sandbox. Ambos plazos están en la documentación de Apple.
No. Apple describe tu información de consumo como "uno de varios factores". Mejora tus probabilidades. No decide nada.
A todas en las que el cliente haya dado su consentimiento, sí. Incluso a aquellas en las que envías GRANT_FULL porque tu servidor estaba caído. Las respuestas honestas en los casos fáciles son la razón por la que Apple confía después en tus DECLINE.
deliveryStatus y sampleContentProvided, con precisión. Omite el porcentaje. Y luego ve a arreglar tu tracking de uso.
Sí. DECLINE y GRANTFULL funcionan para todos los tipos de producto. GRANTPRORATED también; solo que Apple hace el cálculo del prorrateo por su cuenta en los planes de renovación automática.
