Durante mucho tiempo, la respuesta honesta a "¿cómo respondo a una solicitud de reembolso de Apple?" era que no lo hacías. Apple recibía el pago, recibía la solicitud, decidía, y lo primero que sabía el desarrollador al respecto era un pago menor. Eso dejó de ser cierto desde 2021, aunque mucha gente todavía lo cree.
Ahora Apple le pregunta a tu servidor qué sabe sobre la compra antes de decidir, y espera alrededor de 12 horas la respuesta. Ya hemos escrito sobre qué contiene realmente un CONSUMPTION_REQUEST, así que no voy a repetir el payload campo por campo. Esto trata sobre qué hacer cuando llega uno.
Puntos clave
Apple decide todos los reembolsos de App Store. Lo que envíes no cambia eso, pero sí cambia lo que Apple sabe al momento de decidir.
La solicitud llega como una notificación CONSUMPTION_REQUEST, solo para consumibles y suscripciones de renovación automática.
Tienes 12 horas para responder a través del endpoint Send Consumption Information, que ahora requiere cinco campos.
La respuesta se basa principalmente en tres datos: si se entregó, cuánto se usó y si antes recibieron una muestra gratuita. Más tu preferencia.
Según nuestra experiencia, los reembolsos que pierden los desarrolladores son, en su mayoría, los que nadie respondió.
¿Qué es una solicitud de reembolso de Apple App Store?
Una solicitud de reembolso de Apple App Store es cuando un cliente le pide a Apple que le devuelva el dinero por una app o por una compra dentro de la app. No te lo pide a ti. Va a reportaproblem.apple.com, o usa la hoja de reembolso dentro de la app, elige un motivo de un menú corto, selecciona la compra y envía la solicitud. La página de soporte de Apple les indica que esperen una respuesta en 24 a 48 horas.
Si la compra fue un consumible o una suscripción de renovación automática, Apple hace ping a tu servidor y pregunta qué sabes, luego combina tu respuesta con el historial de compras y reembolsos del propio cliente, que Apple conoce mucho mejor que tú, y toma la decisión. No ves el nombre del cliente ni tienes derecho a veto. Tienes una ventana corta para poner los hechos sobre la mesa.
Cómo funciona el proceso de reembolso de Apple para los desarrolladores
El proceso de reembolso de Apple para los desarrolladores tiene cuatro etapas, y tú solo intervienes en una de ellas.
El cliente le pide a Apple un reembolso y elige un motivo.
Apple envía un CONSUMPTION_REQUEST a la URL del servidor que registraste en App Store Connect. Esto solo ocurre con consumibles y suscripciones de renovación automática.
Tienes 12 horas para llamar al endpoint Send Consumption Information con tus datos.
Apple decide y luego te avisa con una notificación REFUND o una REFUND_DECLINED.
Si nunca configuraste una URL de servidor para App Store Server Notifications, la etapa dos simplemente no ocurre. Apple decide solo con la cuenta del cliente y tú te enteras por el informe de ventas, si es que lo lees.
¿Qué sucede después de que un cliente solicita un reembolso?
Poco después de que el cliente envía la solicitud, tu endpoint recibe un payload JSON firmado con un notificationType de CONSUMPTION_REQUEST. Dentro: la transacción firmada, el ID del producto, el ID de la transacción original y un consumptionRequestReason. Apple añadió el motivo en 2024 y lo explicó en la sesión de WWDC24 sobre las API de servidor de App Store. Cinco valores posibles: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL y OTHER.
Lo que falta es la persona. El único hilo que te conecta con tus registros es el ID de transacción, y el appAccountToken si lo estabas adjuntando al momento de la compra. Si no lo hacías, este es el momento en el que desearás haberlo hecho.
Así que la revisión es, en realidad, una búsqueda: quién compró esto, si lo recibió y qué ha hecho con ello desde entonces.
Cómo responder a una solicitud de reembolso de Apple
Quienes buscan cómo responder a las notificaciones de solicitud de reembolso de Apple suelen encontrar la referencia de la API. Aquí están los pasos en orden.
1. Verifica el payload
Apple firma cada notificación. Verifica la firma antes de creerte una sola palabra. La App Store Server Library de Apple hace esto en Java, Python, Node y Swift.
2. Encuentra la compra
Usa el ID de transacción o el appAccountToken para buscar la compra en tu propio sistema. Necesitas al usuario, el registro de entrega y cualquier dato de uso que hayas registrado desde entonces.
3. Lee el motivo y luego verifícalo
FULFILLMENT_ISSUE significa que el cliente dice que nunca recibió lo que pagó. Revisa primero tus registros de entrega, porque si tiene razón, querrás que este reembolso se apruebe.
UNINTENDED_PURCHASE suele ser un niño o un toque accidental.
UNSATISFIED_WITH_PURCHASE es donde tus datos de uso realmente pesan, ya que "no me gustó" se ve distinto con un 2 por ciento de uso que con un 100.
4. Elige una preferencia
Apple acepta GRANT_FULL, GRANT_PRORATED o DECLINE. Elige la que respalden tus datos. Es solo una preferencia, y Apple ha otorgado bastantes reembolsos que los desarrolladores le pidieron rechazar.
5. Envíala
Llama al endpoint Send Consumption Information . El cuerpo de la solicitud actual tiene cinco campos: customerConsented, deliveryStatus, consumptionPercentage, sampleContentProvided y refundPreference.
El consumo se mide en miliunidades, lo cual confunde a mucha gente: 100000 significa uso total, y 45200 significa 45.2 por ciento.
Y customerConsented tiene que ser true, así que el permiso para compartir datos de uso debe estar en tus términos mucho antes de que llegue la primera solicitud.
6. Actúa según el resultado
REFUND significa revocar el contenido o el derecho de acceso, idealmente dentro de la hora siguiente. REFUND_DECLINED significa que nada cambia. En cualquier caso, registra el resultado en el caso.
Supongamos que alguien compra un paquete de 500 monedas a las 11 p.m., gasta 470 durante la noche y presenta una solicitud bajo UNSATISFIED_WITH_PURCHASE a la mañana siguiente. Entregado, 94 por ciento consumido, sin prueba, preferencia DECLINE. Esa es una respuesta completa a una solicitud de reembolso de Apple. No es un ensayo.
¿Qué información deben revisar los desarrolladores antes de responder?
Cinco cosas, la mayoría de las cuales ya deberían estar en tu base de datos.
El registro de la compra
Fecha, producto, precio y si esta cuenta te ha comprado antes. Si tus registros son escasos, el endpoint Get Transaction History de Apple devuelve todo lo que este cliente ha comprado en tu app, a partir de uno de sus ID de transacción.
Entrega
¿Tu servidor realmente entregó las monedas, desbloqueó la función, inició la suscripción, y cuándo? Si esa llamada falló, tu deliveryStatus es uno de los valores UNDELIVERED y el reembolso está justificado. No discutas con tus propios registros.
Uso desde entonces
Sesiones, capítulos abiertos, monedas gastadas, lo que sea que signifique "usarlo" para tu producto. Apple solo quiere un porcentaje, pero no puedes producir uno que puedas defender sin los eventos que lo respaldan.
Si antes recibieron una muestra
Es decir, una prueba gratuita, un capítulo de vista previa o un nivel gratuito. Apple pregunta esto directamente, y un "sí" debilita la historia de "no sabía lo que estaba comprando".
La cuenta de tu lado
Cuánto tiempo tiene, si ya le has hecho un reembolso antes, si hay un ticket de soporte abierto. Apple ve la mitad de ese historial que corresponde a App Store. Tú ves el tuyo.
Todo esto depende de vincular el ID de transacción de Apple con un usuario de tu sistema, que es justamente para lo que existe appAccountToken. Es el vacío más común que encontramos, y hemos escrito sobre por qué appAccountToken es importante para la defensa de reembolsos si quieres conocer los detalles de la configuración.
Errores comunes de los desarrolladores con las solicitudes de reembolso de Apple
La notificación nunca llega
No hay una URL de servidor en App Store Connect, o sí la hay, pero apunta a un entorno de staging que alguien dio de baja en marzo. Apple sigue enviando. No hay nadie del otro lado.
Responder tarde
Doce horas suenan a mucho tiempo hasta que una solicitud llega a las 2 a.m. un domingo y la persona que las gestiona está dormida, luego desayunando, y después apenas consciente de un mensaje en Slack. Un proceso diseñado alrededor del horario de oficina pierde una buena parte de las solicitudes, por diseño.
No tener nada que decir
La notificación llega y no hay registro de entrega, ni eventos de uso, ni appAccountToken. Apple decide basándose solo en la palabra del cliente. Ese error se cometió meses antes, en el checkout.
Pedirle a Apple que rechace todo
Hemos visto configuraciones que envían DECLINE en cada solicitud, incluso en aquellas donde los propios registros del desarrollador muestran que la entrega falló. Apple puede ver el patrón, y eso te cuesta credibilidad en las solicitudes donde sí tienes un caso real.
Olvidar revocar el acceso después de un reembolso otorgado
Este es el error que cuesta el doble. El dinero ya se fue y el cliente todavía tiene el contenido, y algunos se dan cuenta.
Hacer pruebas en producción
Apple te da un endpoint de notificaciones de prueba y solicitudes de reembolso en sandbox. Usa ambos antes de que llegue la primera solicitud real a una hora inconveniente.
Gestión de reembolsos de Apple: manual vs. automatizada
La gestión de reembolsos de Apple abarca todo lo relacionado con esa ventana de 12 horas: recibir la solicitud, encontrar los datos, elegir una preferencia, enviar la respuesta, registrar el resultado y revocar el acceso cuando corresponda.
Manual
De forma manual, eso significa una sola persona con acceso a los registros y una alerta. Funciona bien con un puñado de solicitudes al mes, siempre que esa persona nunca se tome una semana libre.
Alrededor de veinte solicitudes a la semana, el proceso empieza a fallar. Con cien, se convierte en un trabajo de tiempo completo, y uno que nadie pide.
Automatizada
Con la automatización, la búsqueda y la respuesta se ejecutan según reglas que definiste una sola vez. Un consumible totalmente gastado recibe DECLINE, un FULFILLMENT_ISSUE con una entrega fallida recibe GRANT_FULL, y cualquier cosa fuera de lo común se marca para que la revise una persona.
Las respuestas se envían en minutos, tan confiables a las 2 a.m. como a las 2 p.m.
La trampa: la automatización es tan buena como los datos en los que se basa. Registros de entrega y uso incompletos solo hacen que se envíe "unknown" más rápido.
¿Cuándo deberían los desarrolladores considerar un software de gestión de reembolsos de Apple?
Honestamente, no al principio. Dos o tres solicitudes al mes se pueden manejar con una lista de verificación y una alerta notoria, y hacer algunas a mano te enseña mucho.
Empieza a tener sentido cuando las solicitudes llegan más rápido de lo que una persona puede resolverlas dentro del plazo, o a horas en las que nadie está despierto. También ayuda cuando manejas varias apps, o Apple y Google Play en paralelo, y quieres una sola lista en lugar de tres.
Un software de gestión de reembolsos de Apple se justifica cuando el proceso manual empieza a dejar solicitudes sin atender. Sabrás cuándo es: será la semana en que se te escapen tres seguidas y solo te enteres por el pago.
Software de defensa de reembolsos de Apple: ¿qué deben buscar los desarrolladores?
Si estás comparando software de defensa de reembolsos de Apple, empieza por la infraestructura: ¿recibe el propio CONSUMPTION_REQUEST y responde a los casos de rutina sin que una persona intervenga? ¿Con qué rapidez, incluyendo noches y fines de semana? Minutos es la respuesta correcta, y pide ver las marcas de tiempo.
Evidencia
¿Puede obtener o recibir tus datos de entrega y uso, o simplemente devuelve la notificación con una preferencia adjunta? El segundo tipo no vale mucho.
También debería estar construido sobre la App Store Server API y Server Notifications V2, y no sobre el análisis de correos electrónicos.
Visibilidad
Notificaciones cuando llega una solicitud, cuando se envía una respuesta y cuando Apple decide.
Un caso por cada solicitud, con la respuesta y el resultado en un solo lugar.
Informes sobre tasas de reembolso, tasas de éxito y motivos, por app y por producto.
Un registro de auditoría de quién o qué envió cada respuesta y cuándo.
Reglas que controlas tú, de modo que cambiar tu lógica no requiere un despliegue.
Precios
Los precios también varían: tarifas mensuales fijas, tarifas por solicitud y modelos de porcentaje sobre lo recuperado, cada uno tiene sentido en distintos volúmenes.
Hay algo que ninguno puede hacer: evitar que ocurran las solicitudes de reembolso, o garantizar cómo decidirá Apple. Quien diga lo contrario te está vendiendo algo.
Buenas prácticas para responder a las solicitudes de reembolso de Apple
Fija esto junto al calendario de guardias.
Registra una URL de servidor de producción para App Store Server Notifications V2, y configura una alerta si deja de recibir notificaciones.
Configura appAccountToken en cada compra. En todas, sin excepción.
Registra la entrega con una marca de tiempo y un resultado, además de los pocos eventos de uso que indican que "lo usaron".
Incluye desde ya el consentimiento para compartir datos de uso en tus términos.
Responde a cada solicitud dentro de las 12 horas, incluidas aquellas en las que la respuesta es "otorgarlo".
Solo pide DECLINE cuando tus datos lo respalden. Apple se fija en los patrones.
Revoca el acceso ante cada notificación REFUND, el mismo día.
Una vez al mes, revisa qué porcentaje de solicitudes respondiste realmente. Ese número influye en tu tasa de reembolso más que cualquier otra cosa.
¿Vale la pena usar un software de gestión de reembolsos de Apple?
Con poco volumen, probablemente no. Una vez que las solicitudes superan lo que una persona puede responder de forma confiable, o empiezan a llegar fuera del horario laboral, un software que responde automáticamente suele pagarse solo.
Si hay un solo hábito que debes llevarte de todo esto, es responder a cada solicitud, con datos reales, antes de que se acabe el tiempo. Dipsea, una app de audio por suscripción, pasó de una tasa de reembolso del 3 por ciento al 1.9 por ciento en unas dos semanas después de empezar a responder, y nunca le pidió a Apple que rechazara nada. Las apps que se quedan en silencio nunca llegan a saber qué podrían haber conservado.
Preguntas frecuentes
Es cuando un cliente le pide a Apple, normalmente a través de reportaproblem.apple.com, un reembolso por una app o una compra dentro de la app. Apple indica a los clientes que esperen una respuesta en un plazo de 24 a 48 horas. En el caso de los consumibles y las suscripciones, primero le solicita información al desarrollador.
Verifica la notificación, busca la compra en tus propios registros, revisa la entrega y el uso, elige una preferencia y llama al endpoint Send Consumption Information de Apple dentro de las 12 horas. Luego, actúa según lo que decida Apple.
No. Puedes decirle a Apple que preferirías que lo rechazara y enviar datos que lo respalden. Aun así, la decisión final es de Apple, y puede otorgar (y de hecho otorga) reembolsos que los desarrolladores le pidieron rechazar.
Cinco cosas: que el cliente dio su consentimiento para compartir datos, si la compra se entregó, cuánto se consumió, si tuvo una muestra o prueba gratuita, y tu preferencia de reembolso. Eso es todo el cuerpo de la solicitud actual.
Doce horas desde el CONSUMPTION_REQUEST. Apple indica que debes responder dentro de ese plazo si quieres que tus datos se incluyan en la decisión.
