Apple puede revertir un reembolso que ya concedió, y un reembolso revertido que tu servidor ignora bloquea a un cliente que pagó

Un reembolso no siempre es la última palabra. El App Store puede revertir un reembolso que ya concedió, después de que el cliente lo dispute, y cuando ese reembolso revertido llega a tu servidor lleva una sola instrucción: devuelve el acceso. La mayoría de los equipos configuran la notificación REFUND simple, cortan el acceso al cliente y se detienen ahí. Nunca construyen la otra mitad. Así que cuando llega la reversión, no se ejecuta nada, y un cliente que vuelve a pagar se queda bloqueado sin lo que compró. Aquí te explicamos cómo funciona el conjunto completo de notificaciones de reembolso en el App Store y Google Play, y cuánto te cuesta cada una cuando la ignoras.

El App Store envía tres notificaciones de reembolso, no una

La mayoría de la gestión de reembolsos se construye para un solo evento: el dinero se devolvió, corta el acceso al cliente. El feed de App Store Server Notifications V2 en realidad lleva tres resultados de reembolso distintos, y piden tres cosas diferentes. Dos de ellos cambian lo que un cliente puede acceder. Uno de ellos deshace el primero. Aquí está el conjunto completo, en las propias palabras de Apple.

REFUND, la que todos los equipos gestionan

Cuando el App Store procesa un reembolso, envía una notificación REFUND a la URL que configuraste, y la definición de Apple es clara: 'indica que el App Store reembolsó correctamente una transacción por un In-App Purchase consumible, un In-App Purchase no consumible, una suscripción de renovación automática o una suscripción sin renovación.' Almacenas la transacción reembolsada, revocas lo que haya comprado, y Apple te pide que le digas al cliente qué cambió con mensajes contextuales dentro de la app. Esta es la notificación que todos configuran primero, y a menudo la única.

REFUND_DECLINED, la que no necesita nada de ti

REFUND_DECLINED significa exactamente lo que dice: 'el App Store rechazó una solicitud de reembolso.' El cliente lo pidió, Apple dijo que no, y la transacción se mantiene. Nada sobre el acceso del cliente cambia, así que tu lógica de derechos de acceso no hace nada aquí. El valor de esta notificación es de registro. Cierra el ciclo de una solicitud de reembolso que quizá respondiste con un CONSUMPTION_REQUEST, y confirma que el cliente todavía tiene lo que pagó. Trátala como un registro, no como una acción.

REFUND_REVERSED, la que toma por sorpresa a los equipos

Esta es la notificación que la mayoría de las canalizaciones de reembolso nunca gestionan. La definición de Apple es inequívoca: REFUND_REVERSED 'indica que el App Store revirtió un reembolso concedido anteriormente debido a una disputa que planteó el cliente. Si tu app revocó contenido o servicios como resultado del reembolso relacionado, debe restablecerlos.' Léelo dos veces. Apple le dio un reembolso al cliente, tú revocaste el acceso, luego Apple decidió que el reembolso no debía mantenerse y lo retiró. El cargo vuelve a estar activo. El cliente pagó, y si tu servidor solo sabe revocar, sigue bloqueado. Un reembolso revertido es el único evento de reembolso que devuelve el acceso, y es el que casi nadie construye.

Cuánto te cuesta realmente un reembolso revertido

Una reversión perdida no es un error de redondeo. Sigue el dinero en ambas direcciones, porque equivocarse en cualquiera de las mitades tiene un precio.

Pierde la reversión y mantendrás bloqueado a un cliente que paga. Apple ha restablecido el cargo, así que el cliente vuelve a estar sin su dinero, y tu app le niega lo que compró. El costo inmediato es tiempo de soporte y un reembolso de buena voluntad que quizá ahora emitas tú mismo, esta vez sin comisión de la tienda que vuelva para suavizarlo. El costo más lento es la reseña y la pérdida de clientes, y en Google Play esa misma frustración por el bloqueo es exactamente lo que se convierte en un contracargo.

Pierde el reembolso original y seguirás atendiendo a un cliente que no pagó nada. El error espejo es nunca revocar en absoluto. Un cliente reembolsado que sigue generando imágenes, llamando a tus APIs y llenando tu almacenamiento acumula un costo real contra una venta que se revirtió. El cómputo, las llamadas a terceros y el almacenamiento son dinero que ya gastaste, y nada de eso vuelve con el reembolso.

• Costo de soporte: una persona respondiendo un ticket por un acceso que tu propio código eliminó y nunca restauró.
• Reembolsos de buena voluntad: devolver dinero a un cliente que bloqueaste por error, sin comisión de la tienda devuelta en un gesto manual.
• Gasto desperdiciado: cómputo, llamadas a la API y almacenamiento consumidos por una cuenta reembolsada que nunca cortaste.
• Riesgo de contracargo: en Google Play, un cliente que se siente cobrado dos veces puede disputar, y una disputa perdida ahora recae sobre ti.

El reembolso revertido y el reembolso simple son el mismo feed de webhook apuntando en direcciones opuestas. Gestiona uno y omite el otro y pagarás en ambos extremos.

Por qué Apple revierte un reembolso, y cómo leer revocationReason

Una reversión no es aleatoria. Apple la vincula a 'una disputa que planteó el cliente,' que es el cliente cuestionando la decisión de reembolso después del hecho. Cuando el reembolso se concedió por primera vez, la transacción llevaba un revocationDate y un revocationReason, y vale la pena leer esa razón antes de que algo posterior actúe sobre ella.

• revocationReason 1: el App Store reembolsó 'debido a un problema real o percibido dentro de tu app.' Eso es una señal sobre tu producto, no solo sobre este cliente.
• revocationReason 0: el App Store reembolsó 'por otras razones, por ejemplo, una compra accidental.' Sin ninguna señal de calidad de la app asociada.

Cuando llega un REFUND_REVERSED para esa transacción, la revocación se está deshaciendo. Tu lógica de restablecimiento debe buscar el id de la transacción original, confirmar que la revocaste, y devolver el derecho de acceso exactamente como estaba.

Google Play no envía una reversión, así que reconcilias en su lugar

El modelo de Google Play es diferente, y la diferencia importa si ejecutas ambas tiendas a través de un solo manejador de webhook. No hay equivalente de Google para REFUND_REVERSED. Las notificaciones en tiempo real para desarrolladores de Google dividen los eventos de reembolso en dos mensajes, y las reversiones se gestionan mediante reconciliación, no mediante un push.

La notificación de compra anulada

Cuando se anula una compra de Google Play, tu servidor recibe una VoidedPurchaseNotification. Nombra el purchaseToken y el orderId, un productType de subscription o one-time, y un refundType que es una anulación completa o un reembolso parcial basado en cantidad en compras de múltiples cantidades. Google dice que esos datos bastan para encontrar la compra correcta y ajustar el derecho de acceso. Para cualquier cosa más, te dirige a la Voided Purchases API, un modelo pull que lista los pedidos anulados dentro de un rango de marcas de tiempo que consultas.

La revisión de contracargo, y su reloj de 24 horas

Los contracargos llegan a través de un mensaje diferente, la PendingRefundReviewNotification. Cuando un cliente disputa un cargo con su banco, Google Play envía esta notificación e inicia un reloj. Tienes 24 horas para llamar a orders.reviewrefund con una preferencia de reembolso y cualquier evidencia de uso, para que Google pueda impugnar un contracargo ilegítimo en tu nombre. Google registra tu primera llamada e ignora el resto. Este es el paralelo de Google al CONSUMPTION_REQUEST de Apple, la única ventana en la que tu lado de una disputa cuenta.

Como no hay push de reversión, un contracargo que Google impugna y gana no llega como un evento de restablecimiento ordenado. Lo reconcilias contra la Voided Purchases API y tus propios registros. La lección es la misma que en el App Store: un pedido anulado no siempre es permanente, y el estado de tus derechos de acceso tiene que poder moverse hacia atrás, no solo hacia adelante.

Cómo gestionar cada notificación de reembolso sin bloquear a nadie

No necesitas canalizaciones separadas por tienda. Necesitas un manejador que pueda mover un derecho de acceso en ambas direcciones y trate cada mensaje como posiblemente duplicado.

• Construye el restablecimiento, no solo la revocación. Para cada ruta que elimina el acceso ante un REFUND, escribe la inversa que lo restaura ante un REFUND_REVERSED, asociada al mismo id de transacción.
• Hazlo idempotente. Ambas tiendas pueden entregar la misma notificación más de una vez, así que asocia cada revocación y restablecimiento al id de la transacción o del pedido y haz que una repetición no tenga efecto.
• Lee la razón antes de actuar. Usa revocationReason para distinguir un reembolso por calidad de la app de uno accidental, y encamina los de calidad de la app a quien sea responsable de la calidad del producto.
• Responde a las ventanas de evidencia a tiempo. Envía los datos de consumo de Apple dentro de las 12 horas de un CONSUMPTION_REQUEST, y llama a orders.reviewrefund dentro de las 24 horas de una PendingRefundReviewNotification.
• Almacena cada evento. Conserva REFUND_DECLINED y las notificaciones sin procesar, para que una reversión que llegue más tarde pueda emparejarse con el reembolso que deshace.

Nada de esto cambia si ocurre un reembolso. Cambia si el cliente al otro lado de un reembolso revertido llega a notar que tu servidor se equivocó.