Tus datos de consumo informan la decisión de reembolso de Apple, no la controlan

Un cliente toca reembolso y, en menos de un minuto, tu servidor recibe una CONSUMPTION_REQUEST de Apple. Tienes 12 horas para responder con los datos de consumo, y es tentador leer esa respuesta como un veto: envía preferir rechazar, conserva el dinero. No es un veto. La propia documentación de Apple dice que la App Store utiliza varios factores para determinar si una solicitud de reembolso se aprueba o se deniega, y que la información de consumo que proporcionas se usa para informar sus decisiones de reembolso. Informar, no decidir. Esta publicación recorre lo que tus datos de consumo realmente mueven, por qué una compra que marcaste como preferir rechazar aún puede recibir reembolso, y cuánto vale todo el ejercicio una vez que cuentas el dinero que ya gastaste.

Qué hace Apple realmente con tus datos de consumo

El endpoint Send Consumption Information existe para que puedas entregarle a Apple contexto en el momento en que un reembolso está en cuestión. No te entrega la decisión. Leer el flujo en el orden correcto es la diferencia entre fijar expectativas sensatas y reportar un error contra un comportamiento que está documentado.

La App Store decide, y tú recomiendas

Apple es explícita sobre la división. En la referencia de Send Consumption Information, Apple escribe que la App Store utiliza varios factores para determinar si una solicitud de reembolso se aprueba o se deniega, y que usa la información de consumo que proporcionas para informar sus decisiones de reembolso. En el propio campo refundPreference, Apple afirma que tu preferencia de reembolso es uno de varios factores que la App Store usa para informar sus decisiones de reembolso. Así que la señal más fuerte que puedes enviar, un rotundo preferir rechazar, sigue siendo una entrada más en un modelo que no controlas. El historial del cliente, el motivo que dio, el tipo de producto y las propias señales de fraude de Apple están todos en ese mismo modelo junto a tu respuesta.

CONSUMPTION_REQUEST ahora cubre suscripciones, no solo consumibles

Esto solía ser una historia de consumibles. Desde la WWDC24, la notificación CONSUMPTION_REQUEST se dispara cuando un cliente solicita un reembolso por una compra dentro de la app consumible o una suscripción de renovación automática. Es una gran expansión de alcance. La misma respuesta de 12 horas ahora aplica a los reembolsos de suscripciones, donde tu margen de influencia es diferente porque Apple calcula el consumo de las renovaciones automáticas por sí misma y no aceptará una preferencia prorrateada de tu parte. Lee el tipo de producto en cada solicitud antes de decidir con cuánta fuerza puede empujar tu respuesta.

Las cinco entradas que puedes enviar

El cuerpo de la solicitud V2 que Apple acepta es pequeño, cinco campos hacen el trabajo, y tres de ellos son obligatorios. Cada uno es una entrada que Apple pondera, no un interruptor que fuerza un resultado. Esto es lo que puedes poner en la respuesta y lo que le dice a Apple.

La ventana de 12 horas, y la barrera de consentimiento que la mayoría de los equipos pasa por alto

Dos mecánicas deciden si tu respuesta siquiera cuenta. Una es un reloj. La otra es un indicador de consentimiento que detiene en la puerta muchas respuestas bien intencionadas.

Responde en un plazo de 12 horas o el momento pasa

La instrucción de Apple es clara: responde dentro de las 12 horas de recibir la notificación CONSUMPTION_REQUEST. Esa es toda la ventana. Una solicitud de reembolso no espera a tu próximo día hábil, y una respuesta de consumo que llega tarde es una respuesta que Apple nunca ponderó. Si respondes estas a mano, el reloj de 12 horas es la parte que falla primero y en silencio, los fines de semana, los feriados y a las 3 de la madrugada en tu zona horaria. La respuesta tiene que estar automatizada para ser confiable, porque a la ventana no le importa cuándo está despierto tu equipo.

No puedes enviar datos a menos que el cliente haya consentido

Aquí está la barrera con la que tropiezan los equipos. Apple rechaza una solicitud de Send Consumption Information cuyo valor de customerConsented sea cualquier cosa distinta de true. En palabras de Apple, si el cliente dio su consentimiento, responde llamando a la API y enviando los datos de consumo; si no, no respondas a la notificación CONSUMPTION_REQUEST. Apple también pone la responsabilidad de lleno sobre ti: debes obtener un consentimiento válido del cliente antes de compartir sus datos personales, y tú, el desarrollador, eres el único responsable de obtenerlo. Así que la primera pregunta en cada solicitud no es cuánto usaron, es si este cliente aceptó que le contemos a Apple. Sin consentimiento, no hay respuesta, y el reembolso se decide con todo excepto tu versión de la historia.

Qué mueve realmente la decisión de reembolso de Apple

Si la respuesta es una recomendación, la pregunta honesta es cuánto recomienda. La respuesta es que tus datos importan más justo donde un humano dudaría, y menos donde el resultado nunca estuvo realmente en duda.

Por qué puedes enviar preferir rechazar y aun así ver un reembolso

Los desarrolladores reportan enviar preferir rechazar en una compra que el cliente consumió por completo y ver que Apple la reembolsa de todos modos. Eso no es una API rota. Apple te dijo que pondera varios factores, y en cualquier solicitud dada algunos de esos factores pueden pesar más que un consumible completamente consumido: un cliente con un historial limpio, un motivo declarado que Apple trata como sólido, un monto pequeño, una solicitud por primera vez. Tu respuesta empujó en contra del reembolso. Otras entradas empujaron con más fuerza. La lección no es dejar de responder, es dejar de esperar que un consumible limpio siempre sobreviva. Donde la señal es genuinamente mixta, un estado parcialmente consumido, un problema de entrega documentado y una preferencia honesta son las entradas que pueden inclinar un caso límite a tu favor.

Cuánto vale una recomendación en dólares

Un reembolso no es el precio de la venta. Es el precio de la venta más todo lo que ya gastaste para entregarla, y la respuesta de consumo solo toca la primera parte.

El dinero ya está gastado para cuando llega la solicitud

Para cuando Apple pregunta si reembolsar, el cliente ya usó la cosa. En un consumible eso significa que el cómputo se ejecutó, las llamadas a APIs de terceros se facturaron, las imágenes o tokens o generaciones se produjeron, y el almacenamiento se escribió. Esos son costos pagados de tu lado y no vuelven si Apple deniega el reembolso, y se pierden dos veces si Apple lo concede. Tu respuesta de consumo puede recuperar el precio de venta en un caso límite. No puede recuperar el costo de los bienes que ya entregaste. Esa es la verdadera razón por la que una compra completamente consumida es la cara de reembolsar, y no tiene nada que ver con hace cuánto se compró.

• El precio de venta: tus ingresos netos después de la comisión de Apple, revertidos si se concede el reembolso. Esta es la única parte que tu respuesta puede influir.
• El costo de entrega: cómputo, llamadas a API, almacenamiento y cualquier pago que ya hayas hecho contra la compra. Perdido sin importar la decisión.
• El tiempo del personal: cada reembolso respondido a mano son minutos del día de una persona, y la ventana de 12 horas hace que esos minutos caigan en horas inconvenientes.
• El patrón que pasas por alto: un cliente que reembolsa una y otra vez es un costo que solo ves si haces seguimiento del consumo y del historial a lo largo de las solicitudes, en lugar de tratar cada una como algo aislado.

Cómo maneja Google Play la misma cuestión

Apple no es la única tienda que te pide opinar y luego decide por sí misma. Google Play ejecuta un flujo paralelo para los contracargos bancarios, y la forma es la misma: tú envías evidencia, la tienda decide. Las diferencias están en el reloj y en lo que puedes enviar.

La conclusión en ambas tiendas es idéntica. Tu trabajo es responder dentro de la ventana con evidencia de consumo precisa y una preferencia honesta. El trabajo de la tienda es decidir. Confundir ambas cosas es como un equipo termina o bien ignorando la ventana porque la respuesta es solo una recomendación, o bien confiando en la respuesta como un veto y quedándose desprevenido cuando un reembolso llega de todos modos. Ninguna de las dos es correcta. Responde siempre, responde con precisión y trata el resultado como una decisión que informaste, no una que tomaste.

RefundHalt captura la CONSUMPTION_REQUEST en el momento en que Apple la envía, verifica el consentimiento, ensambla el estado de consumo, el estado de entrega y una preferencia de reembolso basada en evidencia, y responde dentro de la ventana de 12 horas sin que nadie de tu equipo esté mirando un reloj. Hace lo mismo para la revisión de contracargos de Google Play dentro de su ventana de 24 horas. No puedes hacer que Apple decida a tu favor. Puedes asegurarte de que Apple nunca decida sin tu versión de la historia, en cada reembolso, a tiempo.