La revisión de contracargos de Google Play te da 24 horas para defenderte, esto es lo que debes enviar

Cuando el banco de un cliente revierte un cargo de Google Play, Google Play no se limita a devolver el dinero y seguir adelante. Envía a tu servidor una PendingRefundReviewNotification e inicia un reloj de 24 horas. Responde esa notificación a través de la ReviewRefund API con una preferencia de reembolso y pruebas de lo que el cliente realmente usó, y Google Play integra tu aporte en cómo impugna el contracargo. Guarda silencio, y la disputa se resuelve sin una palabra de la única parte que sabe cómo se consumió el producto.

La revisión de contracargos de Google Play es el único flujo de reembolsos de Android que te pide pruebas, la contraparte directa del CONSUMPTION_REQUEST de Apple. Ahora importa más que antes. A partir del 3 de agosto de 2026, Google Play traslada el costo de los contracargos a los desarrolladores, así que una disputa que no respondas sale de tu cuenta, no de la de Google. Aquí está exactamente lo que lleva la notificación, lo que envías de vuelta, los campos que componen tus pruebas y dónde el silencio se convierte en dinero.

Qué es realmente una revisión de contracargos de Google Play

Un contracargo no es una solicitud de reembolso. El cliente acude a su banco o red de tarjetas y disputa el cargo, y el banco retira los fondos. Google Play gestiona la mayoría de estos por su cuenta. Para un subconjunto, abre una revisión y te pregunta primero, porque tienes información que Google no tiene: si el pedido se entregó y cuánto de él consumió el cliente. Esa revisión es el flujo detrás de la ReviewRefund API.

Este es el único lugar en el sistema de reembolsos de Android donde tus pruebas cambian el resultado. Todas las demás vías de reembolso de Google Play se ejecutan sin ti. Un cliente puede autogestionar un reembolso dentro de las 48 horas de la compra, el soporte puede conceder uno, y una compra no confirmada se reembolsa automáticamente, todo decidido por Google. La revisión de contracargos es la excepción, y vale la pena tratarla como la única conversación de reembolso a la que realmente puedes unirte.

Es la versión Android de la ventana de pruebas de Apple

Dos tiendas, dos flujos que piden pruebas al desarrollador, y esa es toda la lista. Apple envía un CONSUMPTION_REQUEST y te da 12 horas para responder con Send Consumption Information. Google Play envía una PendingRefundReviewNotification y te da 24 horas para responder con orders.reviewrefund. La mecánica difiere, pero la lección es idéntica: cuando la tienda pregunta qué usó el cliente, una respuesta precisa es la diferencia entre conservar la venta y devolverla.

Una diferencia importa en la práctica. La carga de consumo de Apple son cinco campos numéricos y nada más. Las pruebas de Google Play son más ricas. Puedes enviar un porcentaje de consumo más una lista de eventos de uso individuales, cada uno con una marca de tiempo, un identificador de cuenta e incluso una dirección IP y una ubicación aproximada. Google Play te da más margen para describir la entrega, lo que significa más margen para ser convincente.

El reloj de 24 horas y cómo te llega la notificación

La revisión llega como una Real Time Developer Notification en tu topic de Cloud Pub/Sub, el mismo canal que entrega tus eventos de suscripción y compra. El mensaje es una carga codificada en base64 con un objeto pendingRefundReviewNotification dentro. El reloj empieza cuando se publica esa notificación, no cuando la lees, así que un consumidor que sondea una vez al día es un consumidor que pierde disputas.

PendingRefundReviewNotification, campo por campo

La notificación es pequeña. Te dice qué pedido está bajo revisión, te entrega el token que debes citar de vuelta y nombra la razón. Aquí está cada campo que lleva.

Solo un contracargo abre una revisión pendiente

El refundReason de una revisión pendiente siempre es CHARGEBACK, entregado como el entero 7. Existen otras razones de reembolso en el mundo de Google Play, pero no te llegan por este flujo, porque no tienes voz en ellas. Si ves una PendingRefundReviewNotification, un banco ha revertido un cargo y Google Play está decidiendo si impugnarlo. Ese es el único disparador.

Qué envías de vuelta a través de la ReviewRefund API

Respondes con un único POST a orders.reviewrefund. La ruta completa es POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund, autorizado con el scope https://www.googleapis.com/auth/androidpublisher, el mismo scope de OAuth que ya usa tu integración con la Play Developer API. Un éxito devuelve un cuerpo vacío con HTTP 200.

El cuerpo es donde vive tu caso. Devuelves el pendingRefundToken de la notificación, declaras una preferencia de reembolso y adjuntas pruebas de consumo.

Tu preferencia de reembolso es una recomendación, no un veredicto

El campo refundPreference toma uno de tres valores, y es un consejo para Google Play, no una decisión final. Google sigue siendo dueño del resultado. Pero es un consejo respaldado por datos que Google no puede ver por sí solo, así que tiene peso.

Los campos de prueba que respaldan un DECLINE

Un DECLINE sin más es una afirmación sin prueba. Los campos de consumo son la prueba. consumptionPercentageMilliunits es un entero en milésimas, así que 100000 dice que el cliente consumió el 100 percent de lo que compró y 50000 dice la mitad. consumptionUsageEvents es un array opcional donde cada evento puede llevar un obfuscatedAccountId, un obfuscatedProfileId, un consumptionTime, un ipAddress, un consumptionItemDescription y una location aproximada. sampleContentProvided es un booleano para el caso en que diste al cliente una muestra gratuita del contenido de pago. Juntos dicen, en el propio esquema de Google Play, que el producto se entregó y se usó.

Tu primera llamada es tu única llamada

Google Play registra la primera llamada a ReviewRefund que haces contra una notificación e ignora cada llamada posterior, aunque sigue devolviendo un estado OK. No hay borrador ni revisión. Si tu primera respuesta es un NEUTRAL apresurado sin pruebas porque tu pipeline no estaba listo, esa es la respuesta que queda registrada, y la llamada posterior con el historial de consumo completo se descarta en silencio. Construye la respuesta completa antes de enviar nada.

Cuánto te cuesta la revisión en dinero

Durante años, un contracargo perdido en Google Play le costaba al desarrollador la venta y poco más, porque Google Play absorbía las comisiones posteriores. Eso termina el 3 de agosto de 2026. Para los pedidos realizados después de esa fecha, Google Play comparte el costo del contracargo con los desarrolladores, y la parte del desarrollador es el precio de compra menos la comisión de servicio de Play, más la comisión de contracargo asociada que cobra la institución financiera. Google Play sigue cubriendo la parte de la comisión de servicio. La comisión del banco es un peso nuevo en tu lado del libro contable.

El reembolso nunca es la cifra real

La disputa devuelve el pago del cliente, pero el pago nunca fue tu único costo. Un video generado, un lote de llamadas a la API de un modelo, un pago a un creador, almacenamiento que aprovisionaste, todo ese dinero salió de tu cuenta en el momento en que se entregó el pedido, y nada de eso vuelve con el contracargo. Ahora suma la comisión de contracargo del banco encima. Estás pagando la factura del proveedor, reembolsando la venta y cubriendo la comisión de la disputa, tres costos por un pedido que tenías las pruebas para defender.

La escala que Google está combatiendo

Google Play dice que bloqueó US$3.4B de fraude y abuso en 2025 y está añadiendo detección de fraude a lo largo de 2026. El cambio de reparto de costos es parte del mismo impulso: dar a los desarrolladores una razón para alimentar el sistema con pruebas, y el sistema impugna más de las disputas ilegítimas. La ReviewRefund API es cómo entran tus pruebas. Una respuesta vacía es un voto para dejar que un contracargo de fraude amistoso se sostenga a tu costa.

Cómo estar listo antes de que llegue la notificación

La ventana de 24 horas no es el problema. El problema es que las pruebas que necesitas tienen que existir antes de la disputa, capturadas en el momento de la compra y el consumo, no reconstruidas después de que aparezca un token. Un equipo que empieza a recopilar datos cuando llega la notificación ya ha perdido.

Adjunta la identidad en el momento de la compra

Configura un obfuscatedAccountId con setObfuscatedAccountId en cada compra, para que el id de cuenta de la notificación apunte directamente a un usuario en tu sistema. Mantenlo como un hash, de 64 caracteres o menos, nunca correo en texto claro u otros datos personales, porque los identificadores en texto claro hacen que se bloqueen las compras. Sin ese vínculo no puedes conectar el pendingRefundToken con un historial de uso real, y tu DECLINE no tiene nada detrás.

Registra el consumo a medida que ocurre

Registra qué entregó un pedido de pago, cuándo y a quién, en una forma que puedas convertir en consumptionPercentageMilliunits y consumptionUsageEvents cuando lo necesites.

• Marca con una hora cada unidad de consumo, para que consumptionTime en cada evento sea real, no estimado.
• Rastrea la entrega frente a la compra, para que puedas declarar un porcentaje de consumo con confianza en lugar de adivinar.
• Mantén los identificadores de cuenta y perfil junto al uso, para que un evento se arme en una sola consulta cuando llegue el token.
• Captura la IP de la solicitud y la ubicación aproximada si las tienes, ya que Google Play acepta ambas como campos de evento.

Responde dentro de la ventana, automáticamente

Una ventana de 24 horas es cómoda para una máquina y brutal para un humano que tiene que estar despierto y atento. La respuesta debería ser automática: entra la notificación, se busca la cuenta, se arma el consumo, sale una llamada a ReviewRefund, todo sin una persona en el circuito. Esa es la parte que RefundHalt ejecuta por ti. Escuchamos la PendingRefundReviewNotification, hacemos coincidir el pedido con el uso que ya rastreamos para esa cuenta, y respondemos a orders.reviewrefund dentro de la ventana con una preferencia de reembolso y pruebas de consumo reales. El token es el hilo, y las pruebas son el caso. Ten ambos listos y la única conversación de reembolso a la que puedes unirte es una que puedes ganar.