Respuesta rápida: Antes de enviar datos de consumo a Apple en respuesta a un CONSUMPTION_REQUEST, debes contar con el consentimiento válido del cliente y establecer customerConsented como true. La notificación de Apple no te indica si existe el consentimiento; por diseño, Apple espera que sea tu app, no tu servidor, la que lo recopile. Y como eres tú quien comparte datos que recopilaste del usuario, la responsabilidad legal de ese consentimiento es enteramente tuya, no de Apple. Si te equivocas, es un problema de ley de privacidad, no solo una llamada a la API rechazada.
El vacío que la mayoría de los desarrolladores pasa por alto
A las guías de automatización de reembolsos les encanta hablar de la ventana de 12 horas y de los campos de consumo. Casi ninguna se detiene en el detalle que más probablemente meta en problemas a un desarrollador: la notificación CONSUMPTION_REQUEST no contiene ninguna indicación de consentimiento.
Esto sorprende a muchas personas. Es razonable suponer que si Apple te está pidiendo datos, Apple ya se ocupó del permiso para compartirlos. No es así. La postura de Apple es la contraria: los datos que enviarías son datos que tú recopilaste de tu usuario, así que la responsabilidad de contar con el permiso para compartirlos recae en ti. Apple simplemente te exige que lo atestigües estableciendo customerConsented como true, y rechaza el envío si no lo haces. Este es el núcleo de los requisitos de consentimiento de la Consumption API de Apple.
Así que el campo no es una casilla que marcas para que la API quede conforme. Es una atestación legal. Establecerlo en true cuando en realidad no obtuviste el consentimiento no es un tecnicismo: es una falla de cumplimiento esperando a que la descubran.
Por qué el consentimiento es responsabilidad del desarrollador
Piensa en quién tiene qué. Apple administra la tienda y la decisión de reembolso. Pero la antigüedad de la cuenta, el tiempo de uso, el estado de entrega y el historial de uso que incluirías en un ConsumptionRequest son registros tuyos sobre tu usuario, recopilados bajo tu política de privacidad. Cuando se los envías a Apple, estás divulgando datos personales a un tercero.
Según los regímenes de privacidad aplicables, esa divulgación necesita una base legal adecuada. La documentación específica de la API de Apple exige un consentimiento válido antes de compartir los datos personales a través de la Consumption Information API, mientras que los requisitos legales precisos dependen de la jurisdicción del usuario. Apple señala que los desarrolladores son responsables de determinar el cumplimiento con las leyes aplicables.
Por eso la carga recae en el desarrollador, y por eso "Apple lo pidió" no es una defensa si un regulador pregunta cómo obtuviste permiso para compartir los datos de un usuario. Para un flujo de consentimiento de reembolso de Apple, lo importante es que el consentimiento exista antes de compartir los datos.
Dónde debe recopilarse el consentimiento
Esta es la parte que importa en la práctica: el consentimiento debe recopilarse en tu app, antes del flujo de reembolso, no inferirse en el servidor cuando llega la notificación.
Para cuando un CONSUMPTION_REQUEST llega a tu servidor, ya es demasiado tarde para pedirlo. No hay ningún usuario presente, y el reloj marca aproximadamente 12 horas. El consentimiento ya tiene que existir, capturado antes como parte de cómo tu app incorpora usuarios y divulga sus prácticas de datos, de modo que cuando llegue la solicitud puedas establecer honestamente customerConsented como true.
En la práctica, esto significa que los términos de tu app, la política de privacidad y el flujo de compra u onboarding deben divulgar claramente que los datos de consumo pueden compartirse con Apple para procesar solicitudes de reembolso, y obtener una aceptación que puedas respaldar. Un consentimiento vago, agrupado u oculto es exactamente lo que la ley de privacidad moderna está diseñada para rechazar. Esto también es central para la privacidad en los reembolsos de Apple, porque Apple exige específicamente un consentimiento válido antes de compartir los datos de consumo.
Cómo se relaciona esto con el GDPR y la DPDP
Si alguno de tus usuarios está en la UE/Reino Unido (GDPR), India (DPDP), California (CCPA) o en una lista cada vez mayor de otras jurisdicciones, el intercambio de datos de consumo cae directamente dentro de esos marcos normativos. Algunos principios que se aplican de forma constante:
El consentimiento debe ser informado y específico. El usuario debe entender que los datos relacionados con reembolsos pueden compartirse con Apple, no solo aceptar un muro de texto legal.
El consentimiento debe ser separable. Agrupar el consentimiento para compartir datos con términos no relacionados en una sola casilla obligatoria es un antipatrón reconocido.
Debes poder demostrarlo. Si te lo cuestionan, "teníamos consentimiento" debe poder probarse, lo que significa que la captura de tu consentimiento debe quedar registrada, no supuesta.
Tu política de privacidad realmente tiene que decirlo. Si tu política no divulga que compartes datos de consumo con Apple para reembolsos, tu consentimiento al respecto queda en terreno inestable.
Para los equipos que revisan los requisitos de datos de consumo del GDPR, lo importante es que Apple misma exige un consentimiento válido para esta API, aunque los requisitos legales exactos y la base jurídica pueden variar según la jurisdicción. La guía de Apple indica que el consentimiento debe ser libre, específico, informado e inequívoco, y que los desarrolladores son responsables de determinar el cumplimiento conforme a la ley aplicable.
En el caso de las apps enfocadas en India, el consentimiento para reembolsos bajo la DPDP también debe revisarse frente a los requisitos aplicables, en lugar de asumir que el requisito de la API de Apple por sí solo resuelve todas las obligaciones de privacidad.
Esto no es asesoría legal, y los detalles específicos de tus obligaciones dependen de tus usuarios y jurisdicciones, pero la dirección es clara: el consentimiento detrás de ese campo customerConsented tiene que ser real, informado y estar documentado.
Cómo se ve una configuración conforme
En conjunto, una configuración defendible tiene tres partes funcionando antes de cualquier reembolso:
Divulgación: tu política de privacidad y tus términos indican claramente que los datos de consumo/uso pueden compartirse con Apple para gestionar solicitudes de reembolso.
Captura: tu app obtiene el consentimiento informado y separable del usuario, y lo registra.
Atestación: cuando llega un CONSUMPTION_REQUEST, tu respuesta refleja honestamente ese consentimiento registrado en customerConsented.
RefundSensor se creó teniendo en mente esta cadena. La plataforma gestiona la respuesta de reembolso y la atestación de customerConsented como parte del flujo automatizado, y hemos publicado un conjunto completo de documentos de cumplimiento (política de privacidad, términos, DPA, política de cookies y políticas de reembolso) alineados con el GDPR, la DPDP y la CCPA, de modo que el lado de la divulgación y el procesamiento queda cubierto en lugar de improvisado. La captura del consentimiento en tu app sigue siendo decisión tuya, como debe ser, pero todo lo que viene después está gestionado.
Para los equipos que evalúan un software de cumplimiento de reembolsos o una herramienta de automatización de reembolsos de Apple, esta separación es importante: la automatización puede encargarse de la respuesta técnica, pero no debe inventar ni suponer el consentimiento del cliente.
Los errores más comunes
Establecer customerConsented como true por defecto. La forma más rápida de convertir una función de reembolso en un pasivo de cumplimiento.
Suponer que Apple se encarga del consentimiento. No lo hace, y lo dice explícitamente.
Intentar recopilar el consentimiento en el momento del reembolso. No hay usuario ni ventana de tiempo para hacerlo; tiene que existir de antemano.
No divulgar nada en la política de privacidad. Si la política guarda silencio sobre compartir datos con Apple, el consentimiento detrás de eso es difícil de defender.
Agruparlo en una sola casilla obligatoria. El consentimiento separable es el estándar; agruparlo lo debilita.
Usar App Tracking Transparency como mecanismo de consentimiento. La documentación de Apple indica explícitamente que el consentimiento necesario para la Consumption Information API es independiente de App Tracking Transparency.
Fuentes oficiales
Tanto los requisitos como las regulaciones cambian, así que trata estas fuentes como la autoridad final:
Automatización de reembolsos que respeta la cadena de consentimiento. RefundSensor gestiona la respuesta de reembolso y la atestación de customerConsented como parte de un flujo automatizado, respaldado por un conjunto completo de documentos de cumplimiento alineados con GDPR/DPDP/CCPA. Para los equipos que buscan automatización de reembolsos de apps, la cadena de consentimiento sigue siendo parte de la implementación. Comenzar gratis
Preguntas frecuentes
Sí. Debes contar con un consentimiento válido e informado, y establecer customerConsented como true. Apple exige esa atestación y rechaza las respuestas que no la incluyan, y tú eres legalmente responsable de haber obtenido el consentimiento.
En tu app, antes del flujo de reembolso. Cuando llega un CONSUMPTION_REQUEST a tu servidor no hay ningún usuario presente y el reloj marca aproximadamente 12 horas, así que el consentimiento ya debe existir y estar registrado.
No. La notificación no incluye ninguna indicación de consentimiento. Apple espera que tu app lo haya recopilado, y espera que lo atestigües en tu respuesta.
Puede cumplirlo, si la cadena de consentimiento se hace correctamente: divulgación clara en tu política, consentimiento informado y separable capturado dentro de la app y registrado, y una atestación honesta en la respuesta de la API. La automatización se encarga de la respuesta; la captura del consentimiento dentro de la app es responsabilidad tuya.
Apple no procesará los datos de consumo, así que pierdes la oportunidad de aportar información a esa decisión de reembolso. El camino correcto es obtener un consentimiento real de antemano, en lugar de enviar datos sin él.
