Entender qué es un CONSUMPTION_REQUEST toma más o menos un párrafo. Construir algo que lo maneje de forma confiable toma bastante más, y las partes que suelen complicar a la gente no son las que esperarías.
La verificación de firma es una. El consentimiento es otra, porque tiene que existir antes de que llegue la notificación. Y el calendario de reintentos interactúa con la ventana de respuesta de una manera que sorprende a la mayoría de los equipos la primera vez que la analizan con detalle.
Aquí recorremos el handler desde el momento en que la solicitud llega a tu endpoint hasta la actualización del entitlement que cierra el proceso.
Puntos clave
• CONSUMPTION_REQUEST solicita información durante una revisión de reembolso. Apple sigue siendo quien decide.
• Verifica el payload firmado antes de actuar sobre él. Nunca confíes en una notificación sin verificar.
• El consentimiento ya debe existir en tu app. No puedes recopilarlo después de que llega la solicitud.
• Apple pide una respuesta dentro de las 12 horas posteriores a la notificación.
• Apple reintenta las entregas fallidas según un calendario fijo, y el segundo reintento llega después de que la ventana de respuesta ya cerró.
• Da seguimiento al resultado y actualiza el entitlement después. Responder no es el último paso.
¿Qué es una notificación CONSUMPTION_REQUEST de Apple?
Una notificación CONSUMPTION_REQUEST de Apple es 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 esa compra. Llega a la URL de notificaciones que configuraste, incluye la transacción correspondiente y te da un tiempo limitado para responder.
No es un reembolso ni una decisión. Apple está a mitad de una revisión y recopilando contexto. Tu papel es proporcionar información precisa sobre lo que pasó con la compra; el papel de Apple es decidir.
¿Por qué Apple envía un CONSUMPTION_REQUEST?
Porque Apple no puede ver dentro de tu app. Conoce la transacción, la cuenta y el historial de compras. No sabe si el contenido se entregó, si funcionó ni cuánto lo usó el cliente.
La información de consumo llena ese vacío. Es uno de varios factores que Apple pondera, no el decisivo, y una cifra de consumo alta no es un interruptor de rechazo. Trátala como contexto que aportas, no como un caso que defiendes.
¿Qué deben hacer los desarrolladores cuando reciben un CONSUMPTION_REQUEST?
Validar la notificación, identificar la transacción y al cliente, confirmar el consentimiento, reunir datos de consumo precisos, enviarlos dentro de la ventana de Apple y luego registrar lo que pasó.
Diez pasos en la práctica:
1. Recibe la notificación en el endpoint de servidor que configuraste y persístela de inmediato.
2. Verifica el payload firmado antes de tratar cualquier campo como real.
3. Lee el tipo de notificación y enrútala. Una solicitud de consumo no es el resultado de un reembolso.
4. Identifica la transacción relacionada a partir del payload decodificado.
5. Vincula la transacción con una cuenta de cliente en tu propio sistema.
6. Comprueba si el consentimiento de ese cliente permite responder.
7. Reúne los datos de entrega y uso desde tus registros, no desde estimaciones.
8. Prepara la respuesta y revísala contra las reglas de validación de los campos.
9. Envíala al endpoint de consumo de Apple y captura el resultado.
10. Da seguimiento al resultado del reembolso que viene después y luego actualiza el entitlement y los registros.
¿Cómo deben validar los desarrolladores un CONSUMPTION_REQUEST?
Verifica la firma antes de confiar en el contenido. Las notificaciones llegan como payloads JWS firmados, documentados en la documentación de App Store Server Notifications de Apple, y tu handler debe comprobarlos contra la cadena de certificados de Apple y confirmar que el bundle ID coincide con tu app.
La razón es sencilla. Tu URL de notificaciones es un endpoint público. Una implementación que parsea lo que sea que llegue y actúa en consecuencia es una que cualquiera que encuentre la URL puede manipular.
Tres detalles del handler importan tanto como la firma:
Responde con el código de estado correcto. Apple trata los HTTP 200 a 206 como éxito. Un 40x o 50x le indica al App Store que reintente. Devuelve éxito una vez que hayas almacenado la notificación, no cuando hayas terminado de procesarla; son momentos distintos, y acoplarlos significa que un proceso lento aguas abajo puede provocar reintentos innecesarios.
Maneja los duplicados. Los reintentos implican que la misma notificación puede llegar más de una vez, y cada una incluye un UUID de notificación que puedes usar para deduplicar. Confirma las repeticiones en lugar de devolver error; una respuesta de fallo simplemente reinicia el ciclo de reintentos.
Recuerda que el sandbox se comporta distinto. Los reintentos aplican en producción. En el sandbox, el App Store intenta la entrega una sola vez, así que un handler que se ve bien en pruebas puede seguir perdiendo eventos en producción, y también ocurre lo contrario.
¿Qué deben comprobar los desarrolladores antes de responder?
Cuatro cosas, en este orden.
Primero el consentimiento, porque es lo que puede detenerlo todo. Apple exige un consentimiento válido del cliente antes de que compartas sus datos, obtenerlo es tu responsabilidad y no la de Apple, y la notificación en sí no incluye ningún indicador de consentimiento. Apple también deja claro que el aviso de App Tracking Transparency no es el mecanismo para esto. Si no hay consentimiento, la indicación es no responder.
Segundo, la identidad de la transacción. Necesitas saber de qué compra se trata y qué cuenta está detrás. De ese mapeo trata appAccountToken y la defensa ante reembolsos de Apple: sin un vínculo estable entre transacción y cuenta, estás infiriendo contra reloj.
Tercero, el tipo de producto, ya que afecta qué opciones tienes disponibles. Y por último, si realmente cuentas con datos utilizables. Si tus sistemas no pueden decir si el contenido se entregó, vale la pena saberlo antes de empezar a armar una respuesta.
¿Qué información de consumo pueden enviar los desarrolladores a Apple?
La documentación actual de Send Consumption Information de Apple define cinco campos. Tres son obligatorios y dos opcionales.
Campo | Obligatorio | En términos simples |
customerConsented | Sí | ¿El cliente dio su consentimiento? Debe ser true, o la solicitud se rechaza. |
deliveryStatus | Sí | ¿Tu app entregó realmente una compra funcional y, si no, por qué no? |
sampleContentProvided | Sí | ¿El cliente pudo probarlo antes de comprar? |
consumptionPercentage | No | ¿Cuánto usó? En miliunidades: la mitad es 50000, no 50. |
refundPreference | No | Lo que preferirías: conceder en su totalidad, rechazar o prorratear. |
Dos reglas suelen causar tropiezos. Si el estado de entrega es cualquier cosa distinta de entregado, el porcentaje de consumo debe ser cero. Y la preferencia de reembolso es una preferencia, no una instrucción; Apple puede decidir de otra manera, y lo hace.
Vale la pena revisar en qué endpoint estás. Apple también documenta la documentación de ConsumptionRequestV1 de Apple, la versión anterior con un cuerpo de doce campos que la mayoría de los artículos de terceros todavía describe. La nota de Apple ahí dirige las In-App Purchases estándar al endpoint actual y limita V1 a las compras de Advanced Commerce API. Si tu integración es anterior al cambio, eso es lo primero que debes revisar.
¿Cuánto tiempo tienen los desarrolladores para responder a un CONSUMPTION_REQUEST?
La documentación actual de Apple pide una respuesta dentro de las 12 horas posteriores a la notificación.
Aquí está la parte que merece atención. Apple reintenta las entregas fallidas cinco veces, a las 1, 12, 24, 48 y 72 horas después del intento anterior. Compara eso con una ventana de 12 horas y la aritmética es incómoda: si tu endpoint no recibe la primera entrega, el primer reintento llega una hora después y no hay problema. Si tampoco recibe ese, el siguiente intento llega alrededor de la hora trece, cuando la ventana ya cerró.
Así que la confiabilidad del endpoint no es aquí una cuestión de higiene general. Para las solicitudes de consumo en particular, aproximadamente una hora de caída es recuperable y medio día no lo es.
Apple no afirma que perder la ventana signifique que el reembolso se aprueba automáticamente, y sería incorrecto decirlo. Lo que significa es simplemente que Apple decide sin la información que pudiste haber aportado.
¿Qué pasa después de que el desarrollador responde?
Apple incorpora tu información a su revisión, la pondera junto con todo lo demás y decide. El resultado llega como una notificación separada: concedido, rechazado o revertido si Apple más tarde deshace un reembolso que había aprobado.
Aquí ocurren tres cosas distintas y conviene mantenerlas separadas. Tu respuesta es información. La decisión de Apple es una decisión. La actualización de tu sistema es un cambio de estado. Solo la del medio le pertenece a Apple, y la tercera no ocurre a menos que tú la construyas.
Cómo gestionan los desarrolladores los reembolsos de Apple después de la respuesta
Una vez que llega el resultado, el trabajo vuelve a ti.
Registra el resultado asociado a la transacción y al cliente. Actualiza el estado de la suscripción, ya que un período reembolsado normalmente termina la suscripción en lugar de dejarla activa. Revoca el entitlement cuando el reembolso se concede, restáuralo en una reversión y maneja el caso prorrateado en el que solo se revoca parte de una transacción.
Luego concilia el monto en el período de reporte correcto y conserva el reembolso en un historial consultable. Ese historial es lo que después te dirá si un producto o precio está generando una proporción desmedida, y también es lo que soporte necesita cuando un cliente pregunta qué pasó con su acceso.
¿Cuáles son los errores comunes al manejar CONSUMPTION_REQUEST?
Los que aparecen una y otra vez:
• Tratar la notificación como un reembolso y revocar el acceso de inmediato. Todavía no se ha decidido nada.
• Saltarse la verificación de firma porque el payload se ve bien en pruebas.
• Descubrir que no existe un flujo de consentimiento justo cuando toca responder.
• Enviar cifras de consumo estimadas en lugar de reales.
• Lanzar la solicitud y nunca comprobar si tuvo éxito. Un envío fallido se ve idéntico a uno exitoso después.
• Confundir una cancelación con un reembolso. Son eventos distintos con efectos distintos sobre el acceso.
• Manejar los resultados de concedido y rechazado, pero olvidar el caso de reversión, lo que deja fuera a clientes que sí pagan.
• Depender de que alguien note la notificación manualmente, con un reloj de 12 horas en contra.
¿Se puede automatizar el manejo de CONSUMPTION_REQUEST?
Sí, y casi todo debería estarlo, porque prácticamente cada paso es determinista.
La automatización cubre el monitoreo y la validación de notificaciones, la búsqueda de transacciones, las comprobaciones de consentimiento, la preparación de los datos de consumo, el envío, el registro de respuestas, el seguimiento de resultados, las alertas internas y los reportes. Nada de eso requiere criterio en el momento.
Lo que sigue siendo humano está más arriba: diseñar el flujo de consentimiento en tu app y decidir cuál debe ser tu política de preferencia de reembolso. Y la automatización no tiene ninguna influencia en la decisión de Apple, sin importar lo que algunas herramientas den a entender.
Cómo RefundSensor ayuda a los desarrolladores a gestionar los flujos de reembolso de Apple
La gestión de reembolsos del App Store es la categoría, y RefundSensor cubre el lado del desarrollador: monitorear los flujos de reembolso de Apple, gestionar la vía de respuesta soportada para las solicitudes de consumo, dar seguimiento a los eventos y resultados de reembolso, y quitarle a las personas las partes repetitivas.
En la práctica, las respuestas salen dentro de la ventana sin que nadie vigile un dashboard a las 3 de la mañana, y los registros de reembolsos se mantienen precisos a medida que crece el volumen. No evita los reembolsos y no puede influir en lo que Apple decide. Elimina el monitoreo manual y los pasos omitidos.
Dónde están documentadas estas reglas
Send Consumption Information: el endpoint actual. El requisito de consentimiento, la ventana de 12 horas y los cinco campos de la solicitud. Construye sobre este para las In-App Purchases estándar.
Send Consumption Information V1: el endpoint anterior con el cuerpo de doce campos. Útil para identificar qué versión llama tu integración y para las compras de Advanced Commerce API.
App Store Server Notifications: la entrega de notificaciones, el formato del payload firmado, los códigos de respuesta esperados y el calendario de reintentos.
Si esto todavía se maneja a mano
Una ventana de 12 horas, un calendario de reintentos que puede superarla y notificaciones que llegan de madrugada encajan mal con el monitoreo manual. RefundSensor se encarga del lado del desarrollador en estos flujos: validar notificaciones, preparar y enviar respuestas dentro de la ventana, y dar seguimiento a los resultados hasta tus registros de entitlement.
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 y trata tu respuesta como un dato más entre varios factores.
Porque Apple no puede ver lo que pasó dentro de tu app. Conoce la transacción y el historial de la cuenta, pero no si el contenido se entregó, si funcionó ni cuánto lo usó el cliente. Ese contexto está en tus sistemas, así que Apple lo solicita durante la revisión.
Verifica la notificación firmada, identifica la transacción y al cliente detrás de ella, confirma que existe consentimiento, reúne datos reales de entrega y uso desde tus registros y luego envíalos al endpoint de consumo de Apple dentro de la ventana. Captura el resultado de la respuesta en lugar de asumir que la llamada tuvo éxito.
Cinco campos en el endpoint actual. Tres obligatorios: consentimiento del cliente, estado de entrega y si se proporcionó contenido de muestra. Dos opcionales: porcentaje de consumo y tu preferencia de reembolso. El endpoint V1 anterior pedía doce campos, por eso las guías más antiguas describen una lista 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 más amplio que el que sugerían los documentos anteriores. Apple no publica una garantía para cada caso, así que construye un handler que responda cuando llegue una solicitud, en lugar de una lógica que asuma que siempre llegará.
Apple pide una respuesta dentro de las 12 horas posteriores a la notificación. Vale la pena notar que el calendario de reintentos de Apple para entregas fallidas es de 1, 12, 24, 48 y 72 horas, así que un endpoint que siga caído después del primer reintento podría recibir la notificación solo cuando la ventana ya cerró.
Apple la pondera junto con otros factores y decide. El resultado llega como una notificación separada que indica si el reembolso fue concedido, rechazado o revertido más tarde. A partir de ahí, es tu tarea actualizar el entitlement, el estado de la suscripción y los registros de ingresos para que coincidan con el nuevo estado de la transacción.
Sí. La validación, la búsqueda de transacciones, las comprobaciones de consentimiento, la preparación de datos, el envío, el registro y el seguimiento de resultados son todos deterministas. Lo que sigue siendo humano es diseñar el flujo de consentimiento y definir tu política de preferencia de reembolso. La automatización no tiene ningún efecto en la decisión de reembolso de Apple.
