Reembolso en App Store: lo que ve el desarrollador
Por Mehdi Azizi
Publicado el , 8 min
Apple decide sola los reembolsos. El desarrollador recibe CONSUMPTION_REQUEST, puede responder en 12 horas y conoce la decisión por REFUND.
En el App Store, es Apple quien concede o rechaza un reembolso, nunca el desarrollador. El cliente hace su solicitud en el sitio de Apple o desde tu app. Si conectaste las notificaciones de servidor de Apple, recibes una notificación CONSUMPTION_REQUEST en el momento de la solicitud, y luego REFUND o REFUND_DECLINED cuando se toma la decisión. Entre ambas, tienes 12 horas para enviar datos de consumo y tu preferencia, siempre que el cliente lo haya consentido.
Un reembolso concedido retira la compra de los derechos activos del cliente y aparece en negativo en tus informes de ventas. Esta guía detalla cada paso, lo que puedes enviarle a Apple y lo que tienes derecho a hacer contra las solicitudes abusivas. Las reglas vienen de las páginas de Apple revisadas el 3 de noviembre de 2026. El caso real viene de una alerta que conecté a mis apps en octubre.
¿Quién decide un reembolso en el App Store?
Apple, y solo Apple. La página de soporte de Apple describe el recorrido del cliente: inicia sesión en reportaproblem.apple.com, elige "Request a refund", indica un motivo y luego la compra en cuestión. Apple le aconseja esperar de 24 a 48 horas para tener una respuesta.
El cliente también puede pedir un reembolso desde tu app. Para eso, StoreKit ofrece una hoja de solicitud, disponible desde iOS 15. Apple aconseja abrirla desde los ajustes de la cuenta o un menú de ayuda. Muestra la compra y una lista de motivos, y Apple tarda hasta 48 horas en decidir.
En ambos casos, no tienes nada que aprobar. Solo puedes aportar información y una preferencia, que cuentan entre varios criterios en la decisión de Apple.
Lo que ve cada uno, paso a paso
| Paso | Lado del cliente | Lado del desarrollador |
|---|---|---|
| Solicitud | Formulario de Apple u hoja en la app | Notificación CONSUMPTION_REQUEST |
| En las 12 horas | Espera | Posible envío de los datos de consumo |
| En un plazo de 48 horas | Respuesta de Apple | Notificación REFUND o REFUND_DECLINED |
| Tras una aprobación | Dinero devuelto a su método de pago | Compra retirada de los derechos activos, unidades negativas |
| Tras una impugnación | Reembolso anulado por Apple | Notificación REFUND_REVERSED, acceso a restablecer |
App Store Connect solo te muestra los reembolsos ya concedidos, en Sales and Trends. La solicitud en sí solo llega por las notificaciones de servidor. Sin ellas, descubres el reembolso cuando ya pasó.
Las notificaciones de servidor de un reembolso
Las App Store Server Notifications V2 envían cinco tipos útiles aquí. Las recibes en la dirección HTTPS declarada en App Store Connect, una para producción y otra para sandbox.
| Notificación | Lo que anuncia | Lo que haces |
|---|---|---|
CONSUMPTION_REQUEST | El cliente pide un reembolso | Responder en 12 horas, si hay consentimiento |
REFUND | Apple reembolsó la transacción | Retirar el contenido o el acceso reembolsado |
REFUND_DECLINED | Apple rechazó la solicitud | Nada, el acceso continúa |
REFUND_REVERSED | Apple anula un reembolso tras una impugnación del cliente | Restablecer lo que habías retirado |
REVOKE | Una compra compartida en En familia ya no está disponible | Retirar el acceso al miembro de la familia |
Tu servidor debe responder con un código HTTP entre 200 y 206. Según la página sobre las respuestas a las notificaciones, si no, Apple reintenta cinco veces: 1, 12, 24, 48 y luego 72 horas después del intento anterior. En sandbox, solo envía una vez.
La Consumption API: lo que puedes decirle a Apple
Cuando llega la solicitud, puedes responder con Send Consumption Information. La regla cabe en una frase de Apple: "Respond within 12 hours of receiving the CONSUMPTION_REQUEST notification." La versión 2 de la API sirve para todos los tipos de productos, suscripciones incluidas.
Los campos de la solicitud:
| Campo | Obligatorio | Lo que le dice a Apple |
|---|---|---|
customerConsented | Sí | El cliente consintió compartir sus datos |
deliveryStatus | Sí | La compra se entregó y funciona, o por qué no se entregó |
sampleContentProvided | Sí | Se ofrecía una prueba, un fragmento o una descripción antes de la compra |
consumptionPercentage | No | La parte consumida, de 0 a 100 000 para 0 a 100 % |
refundPreference | No | Tu preferencia: DECLINE, GRANT_FULL o GRANT_PRORATED |
Dos precisiones importan. Si deliveryStatus no es DELIVERED, la parte consumida debe ser cero. Y para un reembolso prorrateado de una suscripción, omites la parte consumida: Apple la calcula.
El consentimiento es la condición de todo. Apple escribe: "You must obtain valid consent from the customer before sharing their personal data with Apple in the Send Consumption Information API." Sin consentimiento, no respondes. Apple también prohíbe usar la ventana de rastreo publicitario para obtener ese consentimiento: "Don't use the AppTrackingTransparency prompt to obtain consent".
Si usas RevenueCat
Con RevenueCat, es él quien recibe las notificaciones de Apple y responde a la solicitud, con Refund Control. Eliges una política entre cuatro: preferir un reembolso completo, preferir un rechazo, enviar solo los datos de consumo o no responder.
Activar el envío de datos equivale a confirmar que tienes el consentimiento de tus clientes. RevenueCat lo dice él mismo: "Enabling consumption data sharing confirms that you obtained consent from your Customers." También aconseja reservar "Prefer no refund" para un grupo específico, y avisa cuando esa preferencia afecta a la mayoría de tus clientes.
Para recibir también las notificaciones en tu propio servidor, RevenueCat ofrece un campo "Apple Server Notification Forwarding URL" en los ajustes de la app. Está descrito en su página sobre las notificaciones de Apple. Es lo que uso. La configuración de una suscripción con RevenueCat está en RevenueCat y la suscripción in-app en iOS.
El efecto en tus ingresos y en la suscripción
En el acceso. Según la documentación de currentEntitlements, "Products that the App Store has refunded or revoked don't appear in the current entitlements". Si tu app verifica los derechos con currentEntitlements, el acceso reembolsado desaparece solo. La transacción lleva la fecha y el motivo de la revocación, en revocationDate y revocationReason.
En los informes. Según la ayuda del informe de ventas, un reembolso aparece con unidades y precio al cliente negativos. Para las suscripciones, la página sobre los datos de suscripción cuenta los reembolsos completos y parciales entre los eventos, y los resta de las unidades diarias.
En tu reputación. La guideline 5.6.4 cita las solicitudes de reembolso excesivas entre las señales de una calidad insuficiente. Una tasa de reembolso alta no es solo una pérdida de dinero: Apple puede tenerla en cuenta para juzgar si respetas el código de conducta.
Mi caso: la alerta conectada a mis apps
El 12 de octubre de 2026, conecté una alerta a mis apps. RevenueCat reenvía las notificaciones de Apple a una ruta de devoria.fr. Esta verifica la firma de Apple y luego me envía una alerta, sin montos. Quería ver la solicitud en el momento en que llega, no solo el resultado.
El 18 de octubre llegó la primera solicitud real en TradaZen, mi simulador de trading. Una suscripción anual, pagada al final de una prueba gratuita de 7 días. Motivo indicado: una compra involuntaria. Tres lecciones:
- La misma solicitud puede llegar varias veces. Recibí tres veces la misma alerta la misma noche. Desde entonces, cada alerta se deduplica según el tipo de notificación y el identificador de transacción.
- La decisión llegó en menos de un día. Apple la rechazó unas 22 horas después de la solicitud. El cliente conservó su acceso.
- Un rechazo no es el final. El mismo cliente volvió a pedirlo dos días después, sobre la misma transacción.
Una solicitud por "compra involuntaria" al final de una prueba no se gana en la respuesta a Apple. Se previene en el paywall, antes del primer pago.
Limitar las solicitudes abusivas sin romper las reglas
Lo que está permitido:
- Responder a cada solicitud con datos exactos, cuando el cliente dio su consentimiento.
- Expresar una preferencia específica, por ejemplo un rechazo para una compra ya consumida, en lugar de un rechazo para todo el mundo.
- Vincular cada
REFUNDa una cuenta de cliente. La página de Apple sobre las notificaciones de reembolso lo recomienda para detectar reembolsos repetidos. - Decir claramente lo que se compra antes de la compra. La guideline 3.1.2(c) pide describir lo que el usuario obtiene por el precio, antes de proponerle suscribirse.
Lo que está prohibido:
- Enviar datos falsos para que se rechace una solicitud, o responder sin consentimiento.
- Obtener el consentimiento con la ventana de rastreo publicitario, algo que Apple excluye de forma explícita.
- Hacer trampa con la compra. La guideline 5.6 prohíbe empujar a los clientes a compras no deseadas o cobrar lo que no se entrega.
- Presionar a un cliente que pide un reembolso. La misma regla exige respeto en la atención al cliente, sin intimidación.
La mejor palanca sigue estando antes: un paywall que diga el precio, la fecha del primer pago y la forma de cancelar. Los errores que debes evitar están en los errores de paywall, y las reglas de la prueba en la prueba gratuita en el App Store.
Probar antes de producción
Según la página sobre las pruebas de solicitudes, el sandbox y las pruebas de StoreKit en Xcode aceptan solicitudes de reembolso. En sandbox, cualquier motivo provoca una aprobación automática. Para simular un rechazo, elige "Other" y escribe DECLINE. Para un reembolso prorrateado, escribe GRANT_PRORATED. En sandbox, tu respuesta de consumo debe salir en los cinco minutos siguientes.
Una suscripción con menos reembolsos
El iOS & Android Kit parte del código de mis apps, con el onboarding, el paywall y las suscripciones ya programados, y sigue cuatro etapas hasta el App Store, a tu ritmo. La configuración completa se detalla en la página suscripción in-app en iOS, y las reglas de Apple sobre la suscripción en la guideline 3.1.2.
Antes de lanzar tu paywall, haz tu diagnóstico gratuito: te dice qué está bloqueando de verdad tu proyecto y te envía mi checklist contra los rechazos de Apple.
Preguntas frecuentes
¿El desarrollador puede rechazar un reembolso del App Store?
No. Apple decide sola. Puedes enviar datos de consumo y una preferencia, DECLINE por ejemplo, que cuentan entre varios criterios. Apple tiene la última palabra.
¿Se avisa al desarrollador de una solicitud de reembolso?
Sí, si conectó las App Store Server Notifications V2. Apple envía CONSUMPTION_REQUEST en el momento de la solicitud, y luego REFUND o REFUND_DECLINED cuando decide. Sin notificaciones, solo ves los reembolsos concedidos, en tus informes.
¿Cuánto tarda Apple en procesar una solicitud de reembolso?
Apple le anuncia al cliente de 24 a 48 horas. La documentación de StoreKit habla de 48 horas como máximo. Por tu parte, tienes 12 horas para enviar los datos de consumo.
¿Qué pasa con el acceso después de un reembolso?
La compra reembolsada sale de los derechos activos del cliente: StoreKit 2 ya no la devuelve en currentEntitlements. Si Apple anula después el reembolso, recibes REFUND_REVERSED y debes restablecer el acceso.
¿Hace falta el consentimiento del cliente para responderle a Apple?
Sí. Apple exige un consentimiento válido antes de compartir cualquier dato mediante la Consumption API. Sin él, no respondes a la notificación. La ventana de rastreo publicitario no puede servir para obtenerlo.
¿Los reembolsos cuentan en contra de mi app?
Pueden contar. La guideline 5.6.4 cita las solicitudes de reembolso excesivas entre las señales de una calidad insuficiente, que Apple puede tener en cuenta para juzgar el respeto del código de conducta.

