El envío de información de consumo de Apple ahora pide cinco campos, no doce, y aquí tienes cada uno

La lista de datos que Apple te pide cuando un cliente quiere un reembolso se ha vuelto mucho más corta. La carga de Send Consumption Information, la única respuesta que un desarrollador puede aportar a una decisión de reembolso de la App Store, solía tener doce campos. Ahora tiene cinco. Apple la recortó alrededor de la WWDC24 y condensó la mayoría de las antiguas preguntas de perfilado de la cuenta en dos sencillas y un número. Menos campos no es una edición menor. Cambia qué evidencia pondera Apple y cambia qué campos no puedes permitirte equivocar.

Aquí está el motivo por el que esto merece tu atención y no es solo una nota sobre el esquema. Esta carga es el único momento en un reembolso de Apple en el que tu versión de la historia llega a la decisión. Un reembolso de un consumible revierte ingresos que ya gastaste dinero real en entregar, y los cinco campos son cómo le dices a Apple que el producto se entregó y se usó. Si pierdes la ventana de 12 horas o rellenas un campo mal, Apple decide solo con la reclamación del cliente.

Qué es Send Consumption Information

Send Consumption Information es el endpoint de la App Store Server API que llamas después de que Apple envíe a tu servidor una notificación CONSUMPTION_REQUEST. Esa notificación significa que un cliente pidió a Apple un reembolso de una compra dentro de la app y Apple quiere tu aporte antes de decidir. Respondes enviando con un PUT un pequeño cuerpo JSON, el ConsumptionRequest, al endpoint. Apple lo lee, lo pondera frente al historial del cliente y toma la decisión. Tú nunca decides el reembolso. Aportas datos.

El cuerpo es toda la interfaz. No hay un formulario aparte, ni apelación, ni un segundo envío que cuente. Lo que envíes en esa única carga es tu caso completo, así que el significado de cada campo importa más de lo que el número de campos sugiere.

Los cinco campos que Apple pide ahora

El ConsumptionRequest actual tiene cinco miembros. Tres son obligatorios y dos son opcionales. Todo lo que Apple solía preguntar sobre la cuenta del cliente, su antigüedad, su gasto de por vida, sus reembolsos de por vida, su tiempo de juego, se ha eliminado de lo que envías.

customerConsented es la barrera

customerConsented es un booleano, y es el campo que decide si envías algo en absoluto. Registra si el cliente aceptó que compartas datos de consumo con Apple. La guía de Apple es directa: si el cliente no dio su consentimiento, no envíes la información de consumo. Así que no es un campo que pongas en true para reforzar tu caso. Refleja un sí o no real que ya debes tener, y un false aquí significa que el resto de la carga no debe enviarse.

deliveryStatus es el campo que mueve los reembolsos

deliveryStatus es un enum de cadena, y es la palanca más fuerte que tienes. Le dice a Apple si tu app realmente entregó una compra funcional dentro de la app. Un valor dice sí. Los otros cuatro dicen no, cada uno por un motivo distinto, y cada uno le dice a Apple que el cliente tiene una queja legítima.

sampleContentProvided responde a una pregunta de equidad

sampleContentProvided es un booleano. Registra si diste al cliente una muestra gratuita, una prueba o información clara sobre lo que hace la compra antes de que comprara. Un true aquí es una pequeña señal de equidad: el cliente tuvo la oportunidad de saber qué estaba comprando. No decide nada por sí solo, pero es uno de solo tres campos obligatorios, así que Apple claramente lo quiere en cada respuesta.

consumptionPercentage ahora es un número, no un estado

Este es el campo que más cambió. La carga antigua tenía consumptionStatus, un enum de cuatro pasos: UNDECLARED, NOT_CONSUMED, PARTIALLY_CONSUMED, FULLY_CONSUMED. La nueva carga lo reemplaza por consumptionPercentage, un entero medido en milliunits. 100,000 milliunits significa que el artículo se consumió por completo, así que 50,000 es la mitad y 0 es intacto. Un número preciso supera a un cubo de cuatro opciones, porque te permite decir que un cliente agotó el 90 por ciento de un paquete de créditos en lugar de redondear hacia abajo a consumido parcialmente.

Una salvedad que confunde a la gente. En las suscripciones de renovación automática Apple calcula el consumo por sí misma a partir del tiempo transcurrido, así que consumptionPercentage está pensado para compras consumibles y no renovables. Envíalo donde aplique, y deja que Apple lo derive donde no.

refundPreference expresa una preferencia, no un veredicto

refundPreference es una cadena opcional, y es donde le dices a Apple qué resultado preferirías. También cambió de forma. El campo antiguo era un número con valores como prefer-grant, prefer-decline y no-preference. El nuevo es una cadena con nombre y tres valores.

Qué eliminó Apple, y por qué importa

El ConsumptionRequest antiguo tenía doce campos. Siete de ellos ya no están en lo que envías. accountTenure, lifetimeDollarsPurchased, lifetimeDollarsRefunded, playTime, userStatus, platform y appAccountToken eran la mitad de perfilado de la cuenta de la carga, los campos que te pedían clasificar a un cliente por cuánto tiempo tenía una cuenta, cuánto había gastado, cuánto le habían reembolsado y cuánto tiempo había usado la app.

Apple los eliminó por un motivo que vale la pena señalar. Esos campos pedían a los desarrolladores entregar un perfil del cliente, y la mayoría de los desarrolladores o los dejaban sin declarar o los adivinaban. Los cinco que quedan tratan sobre la compra y la entrega, datos que realmente puedes verificar desde tus propios sistemas. El cambio va de quién es el cliente a qué pasó con esta compra concreta.

El endpoint y el reloj

Envías la carga con un PUT de HTTP al endpoint de Send Consumption Information, identificado por el id de la transacción de la compra en disputa: PUT /inApps/v1/transactions/consumption/{transactionId}. Un éxito devuelve 202 Accepted, y el cuerpo de la respuesta está vacío. Esa respuesta vacía es esperada, no un fallo. Confirma que Apple puso tus datos en cola, y no te dice nada sobre el resultado final, que llega después como una notificación REFUND o REFUND_DECLINED.

El reloj es la parte que no puedes estirar. Apple te da 12 horas desde el CONSUMPTION_REQUEST para responder. Solo se usa tu primera respuesta, así que la primera carga tiene que ser la completa y correcta. Apple puede enviar el CONSUMPTION_REQUEST más de una vez para la misma compra, pero el plazo de cada uno es fijo, y una revisión manual rara vez cabe dentro de 12 horas entre zonas horarias y fines de semana.

Qué te cuesta un campo mal gestionado

El dinero salió del edificio antes que el reembolso

El reembolso de un consumible no es una reversión limpia. Para cuando un cliente pide que le devuelvan su dinero por un paquete de créditos o un lote de generaciones de IA, tú ya gastaste para entregarlo: inferencia de GPU en cada solicitud, llamadas a API de modelos de terceros facturadas por token, almacenamiento de lo que produjiste, y cualquier pago a creadores o socios ligado a ese uso. El precio de la tienda vuelve al cliente. Tu coste de entrega no vuelve a ti. Así que un reembolso que podrías haber impugnado no es un evento de equilibrio, es una pérdida neta de todo lo que pagaste por atender la cuenta.

Los cinco campos son cómo evitas pagar dos veces

deliveryStatus configurado en DELIVERED y un consumptionPercentage alto son los dos datos que le dicen a Apple que el cliente recibió y usó el producto. Son tu prueba de que el cómputo, las llamadas a la API y el almacenamiento cumplieron su función. Deja la carga sin enviar y Apple nunca lo sabe. Decide a partir de la reclamación del cliente, el reembolso es más probable que se conceda, y tú te comes tanto los ingresos revertidos como el coste de entrega detrás.

Los contracargos son la peor puerta, y el silencio apunta a ella

Un cliente que no consigue satisfacción a través del flujo de reembolsos de Apple todavía puede disputar el cargo con su banco. Un contracargo de tarjeta es definitivo, conlleva una tarifa de disputa fija, y saca la decisión de las manos de Apple y de las tuyas. Responder bien al CONSUMPTION_REQUEST mantiene la disputa dentro del sistema de Apple, donde tienes voz. Ignorarlo empuja los casos límite hacia el único canal donde no tienes ninguna.

Cómo lo gestiona RefundHalt

Los cinco campos parecen simples hasta que tienes que rellenarlos correctamente, dentro de 12 horas, en cada CONSUMPTION_REQUEST, ligados a la transacción correcta. RefundHalt capta la notificación, lee tus propios registros de entrega y uso de esa compra, y envía la carga automáticamente antes de que se cierre la ventana. deliveryStatus refleja lo que tus registros muestran realmente, consumptionPercentage viene del uso real en lugar de una suposición, y refundPreference sigue la política que configuraste una vez. Consigues que el reembolso impugnable se revise con evidencia, no un plazo perdido y una decisión tomada sin ti.