La detección de reembolsos en StoreKit 2 se reduce a una propiedad de la transacción, y es revocationDate

La mayoría de las apps se enteran de un reembolso de Apple por su servidor, a través de una App Store Server Notification, y nunca notan que el mismo reembolso ya está dentro de la app. Está en la transacción, en una propiedad llamada revocationDate, y leerla permite que tu app corte el acceso de un cliente reembolsado la próxima vez que la abra, en lugar de esperar a un trabajo del backend. La detección de reembolsos de StoreKit 2 es una señal del lado del cliente que la mayoría de los equipos se saltan. Aquí verás exactamente dónde aparece un reembolso en el dispositivo, qué te dice, qué no, y por qué debe ir junto a tus notificaciones de servidor y no en su lugar.

Dónde aparece un reembolso dentro de StoreKit 2

StoreKit 2 te entrega las transacciones como valores firmados, y un reembolso no elimina la transacción. La marca. Dos propiedades de la Transaction llevan esa marca, y ambas se mantienen en nil durante toda la vida de una compra sana. Cuando una de ellas pasa a no ser nil, la App Store ha recuperado la compra.

revocationDate es el campo que cambia

revocationDate es un Date opcional. La propia descripción de Apple es exacta: es la fecha en que la App Store reembolsó la transacción o la revocó de Family Sharing. Para una compra que sigue siendo válida, es nil. En el momento en que se procesa un reembolso, contiene la marca de tiempo de ese reembolso. Esa única comprobación, si revocationDate no es nil, es toda la detección de reembolsos del lado del cliente. Todo lo demás es matiz apilado encima.

revocationReason te dice por qué Apple la retiró

revocationReason está junto a la fecha y explica la causa. StoreKit le da dos valores que importan para los reembolsos. developerIssue significa que el cliente le dijo a Apple que el reembolso se debía a un problema real o percibido en tu app. other abarca todos los demás motivos. Un tercer valor, upgradedToBundle, no es un reembolso en absoluto; marca una transacción que la App Store revocó porque el cliente pasó a un paquete de suscripción. Lee el motivo antes de actuar, porque developerIssue es el que vale la pena contar: un grupo de ellos es tu propio producto diciéndote dónde falló.

currentEntitlements ya descarta una compra reembolsada

No siempre tienes que leer los campos de revocación tú mismo. Transaction.currentEntitlements es la secuencia de compras a las que un cliente sigue teniendo derecho ahora mismo, y Apple la construye para dejar fuera las que no deberías honrar. Un producto que la App Store ha reembolsado o revocado no aparece en ella. Tampoco las suscripciones caducadas, ni los consumibles, que desaparecen en el momento en que se agotan.

Eso hace de currentEntitlements el filtro más limpio para el acceso. Pregúntale qué posee el cliente, concede exactamente eso, y un reembolso elimina el derecho por ti sin una sola comprobación de revocationDate. Los campos de revocación son para cuando quieres el detalle, la fecha y el motivo, para registrar el evento o reaccionar a él. La lista de derechos es para la pregunta llana de si mantener las luces encendidas.

La detección de reembolsos de StoreKit 2 en la práctica, desde el arranque y mientras la app se ejecuta

Hay dos momentos en que tu app puede captar un reembolso en el dispositivo, y necesitan código distinto. Uno es mientras la app está abierta y un reembolso ocurre en vivo o en otro dispositivo. El otro es al arrancar, poniéndote al día con todo lo que cambió mientras estabas cerrada. Falla en el segundo y tu detección de reembolsos de StoreKit 2 tiene un agujero justo donde caen la mayoría de los reembolsos, porque los clientes rara vez tienen tu app abierta cuando piden uno.

Empieza a escuchar al arrancar o te pierdes los reembolsos que ocurrieron mientras estaba cerrada

Transaction.updates es la secuencia asíncrona que emite una transacción cada vez que el sistema crea o actualiza una fuera de tu app o en otro dispositivo, un reembolso incluido. La instrucción de Apple es tajante: inicia un Task que la recorra en cuanto tu app arranque, o puedes perder las transacciones que entrega una sola vez al inicio. Un reembolso que llegó de madrugada aparece a través de updates la próxima vez que la app se abre, pero solo si ya hay un escucha en marcha para recibirlo. Sin escucha, no hay evento, y el reembolso queda invisible hasta que algo más lo reconcilie.

Una compra en el mismo dispositivo no llega a través de updates

Una trampa atrapa a quienes prueban reembolsos a mano. Una compra normal hecha en el mismo dispositivo no llega a través de updates; StoreKit la devuelve directamente desde el resultado de la llamada de compra. updates es para los cambios fuera de banda: reembolsos, aprobaciones de Ask to Buy, canjes de códigos de oferta y compras hechas en otro lugar. Así que construye tu manejo de reembolsos en torno a updates y currentEntitlements, no en torno al flujo de compra, porque el reembolso nunca volverá por el camino que tomó la venta.

Lo que la detección del lado del cliente no puede hacer por ti

Leer reembolsos en el dispositivo es rápido y es gratis, pero tiene un techo, y fingir que no lo tiene es como se fuga el ingreso. El dispositivo solo sabe lo que StoreKit le ha dicho, y StoreKit solo habla mientras tu app se ejecuta. Un cliente que recibe un reembolso y nunca vuelve a abrir tu app es un cliente que tu comprobación del lado del cliente nunca ve.

Una revocationDate no siempre es un reembolso

El mismo campo cambia por Family Sharing. Cuando un cliente pierde el acceso a una compra compartida, porque el organizador lo quitó o el uso compartido terminó, esa transacción también recibe una revocationDate. Así que una fecha no nil significa que el cliente ya no tiene esta compra, que es exactamente lo que necesitas para el control de acceso, pero no siempre significa que salió dinero de vuelta. Si estás contando reembolsos para los ingresos, separa las revocaciones de Family Sharing de las reales antes de fiarte del número.

Un reembolso se puede revertir

Un reembolso no siempre es definitivo. Apple puede revertir uno, y cuando lo hace, los campos de revocación se eliminan de la transacción y la compra vuelve a ser válida. Si cortaste el acceso por el reembolso, se espera que lo restaures en la reversión. En el dispositivo eso aparece como otro evento de updates con una transacción limpia; en tu servidor es una notificación distinta, REFUND_REVERSED. Maneja solo el reembolso y dejarás varado a un cliente que paga sin acceso y con un recibo que funciona.

Lo que realmente cuesta una revocación tardía

Un reembolso rara vez es solo el precio de venta saliendo de tu cuenta. Para cuando se liquida, normalmente ya has gastado dinero real atendiendo esa compra, y ese gasto no vuelve. Las imágenes generadas cuestan minutos de GPU. Las respuestas del chat cuestan llamadas a la API del modelo que te facturaron por token. Las subidas cuestan almacenamiento que sigues pagando por retener. Si la compra financió un pago a un creador, ese dinero ya salió por la puerta. Nada de eso se revierte con el reembolso.

La detección del lado del cliente reduce la ventana en la única parte que aún puedes controlar, que es el gasto futuro. Cuanto antes sepas que una compra se reembolsó, antes dejas de atenderla. Pero el dispositivo solo te avisa mientras la app está abierta, así que un usuario reembolsado que nunca regresa conserva el acceso del lado del servidor que le concediste, costándote en silencio cada vez que un trabajo en segundo plano o un dispositivo sincronizado actúa en su nombre. El cliente hace la revocación rápida. No la hace garantizada.

Usa el cliente para la rapidez y el servidor para la verdad

El diseño limpio usa ambas señales para lo que cada una hace bien. En el dispositivo, Transaction.updates y currentEntitlements te dan una reacción local e instantánea en el momento en que un cliente reembolsado abre la app, buena para la interfaz y para terminar cambios de derechos sin una ida y vuelta. En el servidor, App Store Server Notifications V2 envía un mensaje REFUND que llega tanto si la app vuelve a abrirse como si no, que es la única señal que detiene de forma fiable el gasto de tu backend en una cuenta reembolsada.

Conecta las señales del dispositivo para el cliente que tiene el teléfono en la mano, y la notificación del servidor para el que no. El reembolso aparece en ambos lugares a propósito. Leer solo uno de ellos es como una cuenta reembolsada te sigue costando después de que la venta ya se fue.