Si has leído algo sobre CONSUMPTION_REQUEST en los últimos años, seguramente viste una lista de doce campos: antigüedad de la cuenta, dólares gastados en total, tiempo de juego, plataforma, etcétera.
Esa lista corresponde a la versión anterior del endpoint. El endpoint actual de Apple recibe cinco campos, tres de ellos obligatorios, y cubre más tipos de producto que el original. Muchas integraciones en producción siguen construidas sobre el formato antiguo.
Así que este es un recorrido por lo que realmente es la notificación, lo que Apple espera recibir hoy y cómo construir una ruta de respuesta que aguante.
Puntos clave
• CONSUMPTION_REQUEST es una notificación que solicita información durante la revisión de un reembolso. No es un reembolso ni una decisión.
• Apple toma la decisión sobre el reembolso. Tu respuesta es solo uno de los factores.
• El endpoint actual recibe cinco campos, tres obligatorios, y cubre todos los tipos de producto.
• El consentimiento del cliente es obligatorio. Apple rechaza las solicitudes en las que no se confirma.
• Apple pide una respuesta dentro de las 12 horas posteriores a la notificación.
• Existen dos versiones del endpoint. Verifica cuál usa tu integración.
¿Qué es Apple CONSUMPTION_REQUEST?
Apple CONSUMPTION_REQUEST es una App Store Server Notification que le indica a tu servidor que un cliente solicitó un reembolso y te invita a enviar información de consumo sobre esa compra. Llega a la URL de notificaciones que configuraste, incluye la transacción a la que se refiere y te da una ventana limitada para responder.
No es una notificación de reembolso. Cuando llega, nada se ha decidido todavía: Apple está a mitad de la evaluación de la solicitud y recopilando contexto antes de terminar. Para un desarrollador, el significado práctico es concreto: acaba de llegar una tarea a tu backend, tiene una fecha límite y necesita datos que solo tus sistemas tienen.
¿Por qué Apple envía un CONSUMPTION_REQUEST?
Porque Apple solo puede ver la mitad de la transacción.
Apple sabe qué se compró, cuándo, con qué cuenta y cuál es el historial de esa cuenta. Lo que no puede ver es el interior de tu app: si las monedas se acreditaron, si el desbloqueo funcionó o cuánto usó el cliente antes de pedir su dinero de vuelta.
“Consumo” aquí significa qué tanto aprovechó el cliente lo que compró. Una suscripción usada a diario durante tres semanas y una que nunca se abrió se ven idénticas para Apple. Para ti no.
Conviene tener claros los límites. Apple no aprueba ni rechaza basándose únicamente en una cifra de consumo. La información alimenta una decisión que pondera varios factores, y un porcentaje de consumo alto no es un botón de rechazo.
¿Cómo funciona Apple CONSUMPTION_REQUEST?
La secuencia es la siguiente:
El cliente inicia una solicitud de reembolso
↓
Apple comienza su revisión del reembolso
↓
CONSUMPTION_REQUEST llega a tu endpoint de notificaciones
↓
Verificas la notificación e identificas la transacción
↓
Compruebas el consentimiento y reúnes los datos de uso
↓
Envías la información de consumo, si se cumplen los requisitos
↓
Apple pondera la información
↓
Apple toma la decisión sobre el reembolso
↓
Haces seguimiento del estado resultante de la transacción
Una salvedad. La documentación actual de Apple describe esta notificación en relación con solicitudes de reembolso de todos los tipos de producto, un alcance mayor del que sugería la documentación anterior. Pero Apple no publica ninguna garantía de que llegue una en todos los casos, así que construye un handler que responda cuando llega una solicitud, en lugar de una lógica que asuma que siempre llegará.
¿Qué información pide Apple a los desarrolladores?
El endpoint actual Send Consumption Information de Apple recibe cinco campos. Tres son obligatorios y dos son opcionales.
Campo | Obligatorio | Qué significa |
customerConsented | Sí | Debe ser true. De lo contrario, Apple rechaza la solicitud. |
deliveryStatus | Sí | Si tu app entregó una compra funcional y, de no ser así, por qué. |
sampleContentProvided | Sí | Si el cliente pudo probar contenido antes de comprar. |
consumptionPercentage | No | Cuánto se consumió, en miliunidades (50% es 50000). |
refundPreference | No | Conceder en su totalidad, rechazar o prorratear — tu preferencia, no una decisión. |
Dos reglas de validación suelen tomar a la gente por sorpresa. Si el estado de entrega es cualquier cosa distinta de entregado, el porcentaje de consumo debe ser cero o la solicitud falla. Y las miliunidades no son porcentajes: la mitad consumida es 50000.
La preferencia de reembolso es la pieza más nueva y la que más se presta a malinterpretaciones. Puedes indicarle a Apple que prefieres que el reembolso se conceda en su totalidad, se rechace o se prorratee, y Apple lo pondera junto con todo lo demás. El resultado puede ser distinto. Si se aprueba un reembolso prorrateado, la parte revocada llega en el payload de la transacción, así que tu lógica de entitlements debe manejar la revocación parcial.
La diferencia de versiones que conviene revisar
Apple documenta dos versiones de este endpoint, y la nomenclatura se presta a confusión. Send Consumption Information V1 es la versión anterior, con el cuerpo de doce campos que la mayoría de los artículos de terceros todavía describe. La propia nota de Apple en esa página remite las In-App Purchases estándar al endpoint actual y limita V1 a las compras que usan la Advanced Commerce API.
| Endpoint actual | Endpoint V1 |
Campos de la solicitud | 5 (3 obligatorios) | 12 |
Tipos de producto | Los cuatro tipos | Consumibles y suscripciones auto-renovables |
Úsalo para | In-App Purchases estándar | Compras con Advanced Commerce API |
Si tu integración es anterior al cambio, empieza por aquí.
¿Qué es la información de consumo?
La información de consumo son los datos que envías a Apple para describir qué pasó con una compra después de que el cliente la realizó: si se entregó, si pudo probarla antes y cuánto la usó.
Importa porque es la única parte del panorama que Apple no puede ver. Para una app de suscripción, describe si el cliente usó el servicio después de comprar. Para un consumible, cuánto del saldo se gastó. Para un no consumible, si el desbloqueo funcionó.
La palabra importante es precisa. Son datos que obtuviste consentimiento para compartir, extraídos de tus registros. No es un argumento que estés construyendo, y sesgarlos hacia el resultado que prefieres conlleva un riesgo real sin ninguna ganancia confiable.
¿Cómo deben responder los desarrolladores a CONSUMPTION_REQUEST?
Nueve pasos, y la mayor parte del trabajo ocurre antes de que llegue cualquier solicitud.
1. Recibe la notificación
Las solicitudes llegan a la URL que configuraste para App Store Server Notifications V2. La documentación de App Store Server Notifications de Apple cubre la configuración y la estructura del payload. Un endpoint mal configurado significa que la solicitud nunca te llega, y sin ningún aviso.
2. Valida la notificación
Los payloads van firmados. Verifícalos contra la cadena de certificados de Apple y confirma el bundle ID antes de actuar sobre cualquier contenido.
3. Identifica la transacción relacionada
Extrae los identificadores de transacción del payload decodificado y compáralos con tus registros de compras. Sin registro almacenado no hay búsqueda posible, ni base para describir el consumo.
4. Comprueba si el consentimiento permite responder
Apple exige un consentimiento válido del cliente antes de que compartas sus datos, y obtenerlo es tu responsabilidad. La notificación no incluye ningún indicador de consentimiento, así que tienes que saberlo a partir de tus propios registros. Apple también aclara que el aviso de App Tracking Transparency no es el mecanismo para esto: es un consentimiento aparte, que se recopila en tu app. Si no hay consentimiento, la guía de Apple es no responder. Nuestro artículo sobre appAccountToken y la defensa ante reembolsos de Apple cubre la parte de identificación que hace posible esta búsqueda.
5. Reúne la información de consumo relevante
Lee el estado de entrega y el uso desde tus propios sistemas. Si registras el saldo de un consumible, la cifra ya existe. Si un desbloqueo falló, tus logs lo saben.
6. Prepara la respuesta admitida
Arma los campos obligatorios, agrega los opcionales cuando tengas valores reales y revisa primero las reglas de validación.
7. Envía dentro de la ventana de Apple
Envía un PUT al endpoint de consumo usando el identificador de la transacción original que viene en la notificación.
8. Registra la respuesta
Guarda qué enviaste, cuándo y qué recibiste de vuelta. Un envío que falló la validación se ve idéntico a uno exitoso a menos que hayas capturado el resultado.
9. Haz seguimiento del resultado final del reembolso
Apple envía la decisión como una notificación aparte. Regístrala asociada a la transacción y al cliente.
¿Cuánto tiempo tienen los desarrolladores para responder?
La documentación actual de Apple pide una respuesta dentro de las 12 horas posteriores a la recepción de la notificación.
Doce horas suenan generosas hasta que consideras cuándo llegan las notificaciones. Las solicitudes entran de madrugada, en fines de semana, en días festivos, y el reloj no se detiene. Una solicitud que llega a las 11 p. m. de un viernes ya venció antes del lunes.
Apple no afirma que perder la ventana signifique automáticamente que el reembolso se concede, y sería incorrecto asegurarlo. Lo que sí significa es más simple: no aportaste información que Apple estaba dispuesta a considerar, y la decisión se toma sin ella.
¿Qué pasa después de que un desarrollador responde?
Apple incorpora la información a su revisión y decide. Verás el resultado como una notificación: concedido, rechazado o, más adelante, revertido si Apple deshace un reembolso que antes había aprobado.
A partir de ahí, el trabajo es tuyo. Revoca el entitlement cuando se concede un reembolso, restáuralo en una reversión y maneja el caso prorrateado en el que solo se devuelve parte de la transacción.
El estado de la suscripción también requiere atención, ya que un periodo reembolsado normalmente termina la suscripción en lugar de dejarla activa, y el reembolso debe reflejarse en los registros de ingresos del periodo correcto.
Vale la pena decirlo con claridad: tú aportas información, Apple decide y luego tú mantienes tus sistemas sincronizados con el resultado. Tres responsabilidades separadas, y solo la del medio le corresponde a Apple.
¿Por qué es difícil manejar CONSUMPTION_REQUEST manualmente?
Cada restricción de este flujo de trabajo juega en contra de que lo haga una persona.
Las notificaciones llegan a cualquier hora. La ventana es de 12 horas. Cada solicitud requiere verificar la firma, buscar la transacción, asociarla a un usuario, comprobar el consentimiento, calcular el uso, hacer una llamada autenticada a la API y registrar el resultado. Nada de esto es difícil. Todo tiene tiempo limitado, es repetitivo y no produce nada visible cuando sale bien.
La escala lo empeora: varias apps, datos de transacciones en un sistema y datos de uso en otro, logs de respuestas con huecos, estados de entitlements que se desvían del estado de las transacciones sin que nadie lo note. Eso no significa que el manejo manual siempre te cueste dinero, pero el riesgo es real y se acumula en silencio.
¿Se puede automatizar Apple CONSUMPTION_REQUEST?
Sí, y la forma del flujo de trabajo lo justifica, ya que casi todos los pasos son deterministas.
La automatización puede monitorear y verificar notificaciones, identificar específicamente las solicitudes de consumo, resolver transacciones a cuentas, armar la respuesta a partir de tus registros, controlar la ventana, enviar, registrar el resultado, guardar la decisión y propagar actualizaciones de entitlements.
Lo que no puede hacer es influir en la decisión de Apple. Ninguna herramienta cambia eso, y cualquier producto que insinúe lo contrario está describiendo mal el proceso. Lo que la automatización cambia es si tu parte ocurre de forma consistente y dentro de la ventana.
Cómo RefundSensor ayuda a los desarrolladores con los flujos de reembolso de Apple
La gestión de reembolsos de App Store es la categoría a la que pertenece este trabajo. RefundSensor cubre la parte del desarrollador: monitorear los flujos relacionados con reembolsos de Apple, gestionar la ruta de respuesta admitida para CONSUMPTION_REQUEST y mantener los eventos y resultados de reembolsos en un solo lugar en vez de dispersos entre dashboards y hojas de cálculo.
En la práctica, las respuestas salen dentro de la ventana sin que alguien tenga que vigilar las notificaciones, y los registros de reembolsos se mantienen precisos a medida que crece el volumen. No detiene los reembolsos ni puede garantizar ninguna decisión concreta de Apple. Reduce el monitoreo manual y los pasos omitidos.
Dónde están documentadas estas reglas
Tres fuentes de Apple respaldan todo lo anterior. Léelas directamente y vuelve a consultarlas: esta área ha cambiado recientemente y las fuentes secundarias van rezagadas.
Send Consumption Information — el endpoint actual. El requisito de consentimiento, la ventana de 12 horas, el cuerpo de solicitud de cinco campos y los tipos de producto que cubre. Construye sobre este para In-App Purchases estándar.
Send Consumption Information V1 — el endpoint anterior con el cuerpo de doce campos. Útil para determinar en qué versión está tu integración, y para equipos que usan la Advanced Commerce API.
App Store Server Notifications — cómo llegan las notificaciones a tu backend, el formato del payload firmado y los tipos de notificación, incluidos CONSUMPTION_REQUEST y los resultados de reembolso.
Si esto todavía se gestiona a mano
Una ventana de 12 horas y notificaciones que llegan a las 3 a. m. encajan mal con un proceso que depende de que alguien revise un dashboard.
Si ahí es donde está tu equipo, RefundSensor se encarga de la parte del desarrollador en estos flujos: monitorea las notificaciones, prepara y envía respuestas dentro de la ventana y hace seguimiento de los resultados hasta tus registros de entitlements.
Preguntas frecuentes
Una App Store Server Notification que le indica a tu servidor que un cliente solicitó un reembolso y que Apple te invita a enviar información de consumo sobre la compra. No es una notificación de reembolso ni una decisión. Apple decide por separado, usando tu respuesta como un factor más entre varios.
Porque Apple no puede ver el interior de tu app. Conoce la transacción y el historial de la cuenta, pero no si el contenido se entregó, si funcionó o cuánto lo usó el cliente. Ese contexto vive en tus sistemas, y Apple lo pide antes de terminar su revisión.
Un cliente solicita un reembolso, Apple comienza a revisarlo y una notificación llega a tu endpoint configurado. Tú la verificas, identificas la transacción, confirmas el consentimiento, reúnes los datos de uso y envías la información de consumo dentro de la ventana. Apple la pondera, decide y envía el resultado como una notificación aparte.
En el endpoint actual, cinco campos. Tres obligatorios: consentimiento del cliente, estado de entrega y si se ofreció contenido de muestra. Dos opcionales: cuánto de la compra se consumió y tu preferencia sobre el resultado del reembolso. El endpoint V1 anterior pedía doce, por eso los artículos más antiguos describen una lista mucho más larga.
La documentación actual de Apple describe la notificación en relación con solicitudes de reembolso de todos los tipos de producto, un alcance mayor del que sugería la documentación anterior. Pero Apple no publica ninguna garantía para todos los casos, así que construye un handler que responda cuando llega una solicitud, en lugar de una lógica que dependa de que siempre llegue una.
La documentación de Apple pide una respuesta dentro de las 12 horas posteriores a la notificación. Las solicitudes llegan a cualquier hora, incluidos los fines de semana, así que este es el paso que más se le escapa a un proceso manual. Consulta la página de Apple para conocer el requisito vigente en lugar de confiar en una integración antigua.
Puedes informarla, no controlarla. Los datos de consumo precisos le dan a Apple un contexto que de otro modo no tendría, y el endpoint actual te permite indicar una preferencia de reembolso. Apple pondera ambos junto con otros factores y puede decidir algo distinto. No existe ningún mecanismo para que un desarrollador apruebe o rechace un reembolso.
Sí. Verificar notificaciones, identificar transacciones, comprobar el estado del consentimiento, armar los datos a partir de los registros, cumplir la ventana, enviar y registrar los resultados son pasos deterministas. Lo que sigue siendo humano es diseñar el flujo de consentimiento en tu app y definir cuál debe ser tu política de preferencia de reembolso.
