Un cliente le pide un reembolso a Apple. Doce horas después, se cierra una ventana en tu servidor, y la mayoría de los equipos nunca supo que se había abierto.
Esa ventana pertenece a Apple CONSUMPTION_REQUEST, una notificación que el App Store envía cuando quiere información tuya mientras evalúa una solicitud de reembolso. No es un reembolso. No es una decisión. Apple toma la decisión final sobre el reembolso de todos modos. Lo que la notificación te da es una oportunidad limitada de describir lo que realmente pasó con la compra.
Manejarla bien es un problema de backend, no de soporte. La notificación tiene que llegar, la transacción tiene que ser identificable, el estado del consentimiento tiene que conocerse y la respuesta tiene que salir a tiempo.
Este artículo explica qué significa la notificación, qué pide Apple ahora (la lista de campos es mucho más corta que antes) y cómo construir un flujo de trabajo alrededor de ella. Para el proceso más amplio, nuestra guía sobre gestión de reembolsos del App Store da el contexto.
Puntos clave
• CONSUMPTION_REQUEST es Apple pidiendo información durante la evaluación de un reembolso. No es una notificación de reembolso.
• Apple toma la decisión final sobre el reembolso. Tu respuesta es un dato más entre varios.
• El endpoint actual acepta cinco campos, tres de ellos obligatorios, frente a los doce de la versión anterior.
• El consentimiento es obligatorio. Apple rechaza las solicitudes en las que customerConsented no es true.
• Apple pide una respuesta dentro de las 12 horas posteriores a la notificación.
• Como la ventana es corta y las notificaciones llegan a cualquier hora, este paso se presta más a la automatización que a un proceso manual.
¿Qué es Apple CONSUMPTION_REQUEST?
CONSUMPTION_REQUEST es una App Store Server Notification que te indica que un cliente le ha pedido un reembolso a Apple y que el App Store te invita a enviar información de consumo sobre esa compra.
La solicitud de consumo de Apple para desarrolladores existe por una brecha de información. Apple ve la transacción, la cuenta y el historial de compras. No puede ver lo que pasó dentro de tu app: si el contenido se entregó, si funcionó, cuánto lo usó realmente el cliente. Tú sí.
Una cosa que no es: un veto. Una respuesta no bloquea un reembolso, y Apple es explícita en que pondera una variedad de factores.
¿Cómo funciona Apple CONSUMPTION_REQUEST?
La secuencia es así:
El cliente solicita un reembolso
↓
Apple empieza a evaluar la solicitud
↓
CONSUMPTION_REQUEST llega a tu endpoint de notificaciones
↓
Verificas la notificación e identificas la transacción
↓
Compruebas el consentimiento y reúnes datos reales de uso
↓
Envías la información de consumo, si se cumplen los requisitos
↓
Apple toma la decisión sobre el reembolso
↓
Llega REFUND o REFUND_DECLINED; actualizas el estado
Vale la pena señalar: en el endpoint actual de Apple, una solicitud de reembolso de cualquier tipo de producto puede activarla: consumible, no consumible, suscripción no renovable o suscripción con renovación automática. La documentación antigua y la mayoría de los artículos de terceros todavía la describen como limitada a consumibles y suscripciones con renovación automática. Si tu handler filtra por tipo de producto basándose en eso, está descartando solicitudes.
¿Qué información pide Apple a los desarrolladores?
Menos que antes. Esta es la parte en la que se equivoca la mayoría de las guías existentes, así que conviene ser preciso. El endpoint actual de Apple Send Consumption Information acepta cinco campos: tres obligatorios y dos opcionales.
Campo | Obligatorio | Qué significa para ti |
customerConsented | Sí | Debe ser true. De lo contrario, Apple rechaza la solicitud. |
deliveryStatus | Sí | Si tu app entregó correctamente una compra que funciona. |
sampleContentProvided | Sí | Si el cliente recibió contenido de muestra antes de comprar. |
consumptionPercentage | No | Qué porción de la compra se consumió, en miliunidades. |
refundPreference | No | Tu resultado preferido: conceder en su totalidad, rechazar o prorratear. |
Dos restricciones toman a la gente por sorpresa. Si deliveryStatus es cualquier valor distinto de delivered, consumptionPercentage debe ser cero o la solicitud falla. Y las miliunidades no son porcentajes: la mitad consumida es 50000, no 50.
La preferencia de reembolso opcional es más reciente y vale la pena entenderla. Puedes indicar si preferirías que el reembolso se conceda en su totalidad, se rechace o se prorratee. Es una preferencia, no una instrucción: Apple la pondera junto con todo lo demás, y el resultado puede diferir de lo que pediste.
Si Apple aprueba un reembolso prorrateado, la porción revocada vuelve en el payload de la transacción, así que tu lógica de entitlements puede necesitar manejar revocaciones parciales en lugar de tratar cada reembolso como todo o nada.
¿Por qué Apple necesita información de consumo?
Porque Apple está decidiendo sobre algo que solo puede ver en parte.
Apple sabe qué se compró, cuándo, desde qué cuenta y cómo es el historial de esa cuenta. No sabe si tu servidor entregó las monedas, si la función desbloqueada funcionó o si el cliente usó el producto intensamente antes de pedir su dinero de vuelta. Ese contexto vive en tus sistemas.
El flujo de reembolso CONSUMPTION_REQUEST de Apple es la forma que tiene Apple de incorporar ese contexto antes de decidir. Y por eso mismo la precisión importa más que la persuasión. Los datos describen lo que pasó. No es un caso que estés defendiendo, y tratarlo así conlleva un riesgo real sin una recompensa confiable.
Cómo responden los desarrolladores a CONSUMPTION_REQUEST
Ocho pasos. La mayor parte del trabajo ocurre antes de que llegue cualquier solicitud.
1. Recibe la notificación
Las notificaciones CONSUMPTION_REQUEST del App Store llegan a la URL de servidor que configuras para App Store Server Notifications V2. Si ese endpoint falta, no está verificado o falla en silencio, la solicitud nunca te llega. La documentación de App Store Server Notifications de Apple cubre la configuración y el formato del payload.
2. Verifica la notificación
Las notificaciones llegan como payloads JWS firmados. Verifica la firma contra la cadena de certificados de Apple antes de actuar sobre cualquier cosa que contengan, y comprueba que el bundle ID coincida con tu app. Un endpoint sin verificar que acepta cualquier cosa que le envíen es una vía para que otra persona controle tu lógica de reembolsos.
3. Identifica la transacción
El payload decodificado trae los identificadores de la transacción. Necesitas un registro de compra almacenado contra el cual compararlos. Sin registro no hay búsqueda, y no hay forma de decir nada útil sobre el consumo.
4. Asocia la transacción con el usuario correcto
No puedes describir el uso de un cliente hasta saber de qué cliente se trata. Para ese mapeo existe appAccountToken: un UUID que tu app adjunta en el momento de la compra y que vuelve en el payload de la notificación. Sin él, los equipos terminan haciendo coincidencias por tiempos y heurísticas, lo cual es lento y poco confiable justo cuando la velocidad importa.
5. Comprueba los requisitos de consentimiento aplicables
Apple es inequívoca aquí: debes obtener un consentimiento válido antes de compartir los datos de un cliente, y obtenerlo es tu responsabilidad, no la de Apple. La notificación no incluye ningún indicador de consentimiento, así que tienes que saberlo por tus propios registros.
Si el cliente no ha dado su consentimiento, la guía de Apple es no responder en absoluto. Enviar la solicitud con el consentimiento en false no funciona: el App Store la rechaza. Apple también deja claro que el aviso de App Tracking Transparency no es el mecanismo para esto; es un consentimiento independiente, recogido en tu app.
6. Reúne información real de uso
Obtén el estado de entrega y el consumo de tus registros reales. Si tu servidor lleva el saldo de un consumible, ya sabes cuánto se gastó. Si falló el desbloqueo de una función, tus logs también lo saben. No estimes: una cifra de consumo inventada es un dato inexacto enviado a Apple bajo un consentimiento que obtuviste para datos exactos.
7. Envía la información correspondiente
Responde con un PUT al endpoint de consumo usando el identificador de la transacción original que viene en la notificación. Maneja las respuestas de error en lugar de disparar y olvidar: los fallos de validación devuelven HTTP 400 con tipos de error específicos, y una llamada que falla en silencio se ve idéntica a una exitosa si nadie la revisa.
8. Registra el resultado
Registra la solicitud, la transacción, qué enviaste, cuándo lo enviaste y qué decidió Apple al final. Ese registro es lo que te permite responder una pregunta de soporte semanas después, detectar patrones entre reembolsos y confirmar que el estado de tus entitlements es correcto. Cuando llegue un reembolso, revoca el acceso tras el reembolso, y prepárate para restaurarlo si Apple revierte la decisión más adelante.
¿Qué pasa si los desarrolladores no responden al CONSUMPTION_REQUEST?
Nada dramático, y eso es parte del problema.
No responder significa que no aportas la información adicional que Apple te permitió enviar durante ese flujo. Apple decide igual. El reembolso puede aprobarse, o rechazarse, con la información que Apple ya tiene. No hay error, no hay alerta y no hay ninguna señal evidente de que algo se haya omitido.
Las formas en que se pierde son de lo más comunes. La notificación llega a las 2 a. m. El ingeniero responsable del handler está fuera. La búsqueda de la transacción se demora porque el identificador está en un sistema y los datos de uso en otro. Alguien la ve el lunes, mucho después de que se cerró la ventana.
Por qué es difícil manejar CONSUMPTION_REQUEST manualmente
Cada restricción de este flujo apunta en contra del manejo manual.
Las notificaciones llegan a toda hora. La ventana es de 12 horas. Cada solicitud necesita una búsqueda de transacción, una coincidencia de usuario, una comprobación de consentimiento, un cálculo de uso, una llamada firmada a la API y un resultado registrado: siete pasos, ninguno interesante, todos con tiempo limitado.
Con una solicitud a la semana es una molestia. Con treinta al día es el trabajo de alguien: uno que no produce nada cuando se hace bien y pérdidas silenciosas cuando se hace tarde.
Cómo cambia la automatización el flujo de reembolsos
La automatización no te da influencia sobre Apple. Vale la pena repetirlo, porque mucho marketing insinúa lo contrario. La decisión de Apple sigue siendo de Apple.
Lo que hace la automatización es que tu lado sea consistente. Las notificaciones se monitorean y verifican. Las solicitudes relevantes se separan del resto del flujo. Las transacciones se asocian con cuentas. Los datos de respuesta se arman a partir de registros reales, se hace seguimiento de los plazos, las respuestas se envían y se registran, y los resultados alimentan las actualizaciones de entitlements.
Ninguno de esos pasos requiere criterio. Todos requieren atención en el momento justo, algo que el software maneja mejor que las personas.
¿Qué debería cubrir un software de gestión de reembolsos del App Store?
Si estás evaluando software de gestión de reembolsos del App Store, la pregunta útil es si cierra las brechas específicas descritas arriba.
Debería monitorear y verificar las App Store Server Notifications, para que los eventos no desaparezcan en un endpoint que falla. Debería rastrear los eventos CONSUMPTION_REQUEST por separado, ya que necesitan un manejo distinto al de los resultados de reembolso. Debería asociar transacciones con cuentas, porque ahí es donde se va el tiempo manual. Debería hacer seguimiento de las ventanas de respuesta, porque ese es el plazo que la gente pierde.
Más allá de eso: flujos de datos de consumo que respeten el estado del consentimiento, historial de reembolsos con búsqueda, seguimiento de resultados, sincronización de entitlements incluyendo la revocación parcial, e informes lo bastante claros para mostrar patrones. Lo que importa es la cobertura del flujo de trabajo, no la longitud de la lista de funciones.
Dónde están documentadas estas reglas
Tres fuentes de Apple cubren todo lo anterior. Léelas directamente: esta área ha cambiado recientemente, y mucho contenido secundario describe una versión anterior de la API.
Send Consumption Information: el endpoint actual. Cubre el requisito de consentimiento, la ventana de 12 horas, el cuerpo de solicitud de cinco campos y el hecho de que la información de consumo aplica a todos los tipos de producto. Este es el que debes tomar como referencia para las compras dentro de la app estándar.
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, REFUND y REFUND_DECLINED.
Send Consumption Information V1: el endpoint anterior, con el cuerpo de solicitud de doce campos que algunos equipos todavía tienen conectado. La propia nota de Apple en esa página remite las compras dentro de la app estándar al endpoint actual y limita V1 a las compras que usan la Advanced Commerce API. Útil para identificar en cuál está tu integración, no como objetivo de desarrollo.
Reflexiones finales
CONSUMPTION_REQUEST no es la decisión de reembolso de Apple. Es una oportunidad breve y con tiempo limitado para contarle a Apple lo que tus sistemas saben y los suyos no.
Un flujo de trabajo que la maneje de forma confiable necesita un endpoint de notificaciones verificado, transacciones que puedas identificar, clientes que puedas mapear, un consentimiento que realmente hayas recogido, datos reales de uso, una respuesta dentro de la ventana y resultados registrados lo bastante bien como para actualizar los entitlements después.
Si haces una sola cosa después de leer esto, comprueba qué endpoint llama tu integración. Si todavía envía doce campos a la ruta V1 para compras dentro de la app estándar, esa es la brecha que conviene cerrar primero.
Si el volumen de reembolsos ya supera el manejo manual
Cuando la actividad de reembolsos es tan frecuente que vigilar las notificaciones a mano deja de ser realista, un sistema dedicado puede monitorear los eventos, preparar y enviar respuestas dentro de la ventana, hacer seguimiento de los resultados y mantener los entitlements sincronizados. RefundSensor automatiza el lado del desarrollador de ese flujo: no la decisión de Apple, solo la parte de la que tú eres responsable.
Preguntas frecuentes
Es una App Store Server Notification que le indica a tu servidor que un cliente ha solicitado un reembolso y que Apple puede querer información de consumo. No es una decisión de reembolso.
Apple lo envía después de que un cliente solicita un reembolso, mientras Apple está evaluando la solicitud. Puede aplicar a distintos tipos de producto del App Store.
Tu servidor recibe y verifica la notificación, identifica la transacción y el cliente, comprueba el consentimiento y envía la información de consumo requerida a Apple dentro de la ventana de respuesta.
Verifica la notificación, comprueba el consentimiento del cliente, aporta datos precisos de uso y entrega, envíalos a Apple y conserva un registro de la respuesta y del resultado final.
La documentación actual de Apple especifica una ventana de respuesta de 12 horas. Los desarrolladores deberían verificar los requisitos más recientes de Apple antes de implementar.
Es información sobre cómo el cliente usó la compra. Según el endpoint actual, puede incluir consentimiento, estado de entrega, contenido de muestra, datos de consumo y un resultado de reembolso preferido.
No. Apple toma la decisión final. Los desarrolladores pueden aportar información de consumo e indicar una preferencia de reembolso, pero Apple hace la determinación final.
Sí. Los desarrolladores pueden automatizar la verificación de notificaciones, la coincidencia de transacciones, las comprobaciones de consentimiento, la preparación de datos, el seguimiento de plazos y el registro de respuestas.
