¿Qué herramientas se integran con las notificaciones en tiempo real de Google Play para la defensa de reembolsos?

Respuesta corta: menos de las que crees, y la mayoría solo escucha.

Google Play RTDN es el canal. Transporta renovaciones, cancelaciones, compras anuladas y, desde mediados de 2026, un mensaje que indica que un contracargo está en revisión y que tienes 24 horas para responder. Ese último es el único lugar donde realmente ocurre la defensa de reembolsos de Google Play. Todo lo demás en el feed es Google contándote lo que ya decidió.

Entonces, cuando alguien pregunta qué herramientas se integran con las notificaciones de desarrollador en tiempo real de Google Play para la defensa de reembolsos, en realidad está haciendo dos preguntas. Cuáles pueden escuchar el feed y cuáles pueden responderlo. Para el lado de Apple, nuestra explicación de CONSUMPTION_REQUEST cubre el mismo problema en iOS.

Puntos clave

• Google Play RTDN es un topic de Pub/Sub. Google publica, tú te suscribes.

• Solo un tipo de RTDN te permite responder: PendingRefundReviewNotification. Se activa con los contracargos y te da 24 horas.

• Desde el 3 de agosto de 2026, tú absorbes el contracargo. El precio de compra menos la comisión de Google, más una comisión bancaria de entre $15 y $25 adicionales.

• La mayoría de las plataformas de suscripción reciben notificaciones de reembolso de Google Play. Muy pocas envían algo de vuelta.

• RevenueCat responde a las revisiones de contracargos, pero, según su propia documentación, no envía datos de consumo. Solo una preferencia y una bandera.

• Si te pasas de las 24 horas, Google argumenta la disputa sin nada de tu parte.

Qué envía realmente Google Play RTDN

Las notificaciones de desarrollador en tiempo real llegan a un topic de Google Cloud Pub/Sub que tú administras. Cada mensaje es un blob en base64 que contiene uno de cinco payloads. Eventos de suscripción, eventos de productos de una sola compra, un ping de prueba y los dos que importan aquí.

VoidedPurchaseNotification es la clásica notificación de reembolso de Google Play. Una compra fue reembolsada, sufrió un contracargo o fue anulada de alguna otra forma. Cuatro campos: purchaseToken, orderId, productType, refundType. Sirve para revocar el acceso. Inútil para argumentar, porque el dinero ya se fue.

PendingRefundReviewNotification es la nueva. La referencia de RTDN de Google dice que se envía "cuando un usuario solicita un contracargo para una compra, y la solicitud requiere revisión del desarrollador". Recibes un pendingRefundToken, el orderId y un refundReason que actualmente siempre es 7, lo que significa CHARGEBACK. Luego empieza a correr un reloj de 24 horas.

Las notificaciones de reembolso de Google Play RTDN vienen entonces en dos variantes. Una es un recibo. La otra es una pregunta.

Por qué la ventana de 24 horas de repente importa

Durante años, los contracargos en Android fueron problema de Google. Un usuario disputaba un cargo con su banco, Google lo absorbía, tú recibías una notificación de compra anulada y seguías adelante.

Eso terminó para los pedidos realizados después del 3 de agosto de 2026. Ahora pagas el precio de compra menos la comisión de servicio de Play, más cualquier comisión de contracargo que cobre el banco. Google cubre solo su propia comisión de servicio y nada más.

Las comisiones de las redes de tarjetas van de $15 a $25 por disputa. A veces más. Entonces, un paquete de monedas de $4.99 que recibe un contracargo te cuesta cerca de $3.50 en ingresos perdidos más $20 en comisiones. Veintitrés dólares perdidos en una venta de cuatro dólares.

A cambio, Google abrió la API de ReviewRefund. Cuando llega un PendingRefundReviewNotification, envías un POST a orders.reviewrefund con el token, una refundPreference (DECLINE, APPROVE o NEUTRAL), si ofreciste una muestra, un porcentaje de consumo en miliunidades, y hasta 1,000 eventos de uso. Google lleva eso al banco por ti.

Si te pasas de la ventana, Google entra con las manos vacías. Las cifras de la industria ubican las tasas de éxito en contracargos sin asistencia alrededor del 20 al 30 por ciento. Con evidencia, algunos proveedores afirman un 80. Toma ambas cifras con cautela, pero la tendencia es evidente.

Las herramientas, ordenadas según lo que realmente hacen

Muchos productos dicen que "son compatibles con Google Play RTDN". Casi todos quieren decir que se suscriben al topic. Muy pocos quieren decir que responden.

Refund Sensor. Creado para este trabajo. Aprovisiona el topic de Pub/Sub en tu proyecto de Cloud, lo registra en Play Console y, cuando llega un PendingRefundReviewNotification, envía una recomendación de DECLINE con evidencia de entrega y consumo a través de la Review Refund API. La configuración consiste en iniciar sesión con Google y otorgar dos permisos en Play Console, sin SDK. Al momento de escribir esto, es una de las pocas herramientas que presenta evidencia en lugar de solo una preferencia. Más detalles en la página de defensa de Google Play.

RevenueCat. Recibe RTDN, consulta periódicamente la Voided Purchases API y revoca entitlements cuando hay un reembolso. En julio de 2026 agregaron Google a Refund Control, así que ahora responden a las revisiones de contracargos. Pero lee su propia documentación. En Google envían el token, sampleContentProvided establecido en true y tu preferencia. En sus propias palabras: "RevenueCat doesn't currently collect or send consumption percentages or usage events." Un voto, pero sin argumento. Está bien si ya los usas. No es una defensa completa.

Adapty. Un receptor sólido de RTDN. Su documentación te guía para pegar un nombre de topic en Play Console y presionar el botón de prueba. Los reembolsos aparecen en el feed de eventos y disparan webhooks. No encontré ninguna integración con ReviewRefund. Solo escucha.

Qonversion, Glassfy y el resto. La misma historia. Consumen las notificaciones de desarrollador en tiempo real de Google Play para mantener actualizado el estado de las suscripciones. Ninguna interviene en la revisión de contracargos, según su documentación pública.

Tu propio backend. Siempre es una opción. Una suscripción de Pub/Sub, un decodificador, una búsqueda de pedido, una consulta de uso, un POST autenticado. Lo difícil no es el código. Es que la notificación llega a las 2 a.m. de un domingo y el reloj no espera.

Si estás buscando software de gestión de contracargos para Google Play, hazle una pregunta a cada proveedor: cuando llega una notificación de revisión, ¿qué envían exactamente de vuelta? "Tu preferencia" es un comienzo. Los datos de consumo son una defensa.

Cómo integrar tú mismo Google Play RTDN para la defensa de reembolsos

Si prefieres construirlo en lugar de comprarlo, esta es la secuencia.

Habilita la Cloud Pub/Sub API en un proyecto de Google Cloud. Crea un topic. Otórgale a [email protected] el rol de Pub/Sub Publisher en él. Si omites ese rol, nunca llegará nada. Es la queja más común en los foros de RevenueCat.

En Play Console, ve a Monetize y luego a Monetization setup. Marca "Enable real-time notifications", pega el nombre completo del topic (projects/your-project/topics/your-topic) y presiona Send test notification. Si llega, el canal funciona.

Crea una suscripción de Pub/Sub, push o pull. Decodifica el campo data. Ramifica según el payload.

Para PendingRefundReviewNotification: busca el pedido, obtén el uso real, decide una preferencia, envía un POST a reviewrefund con el pendingRefundToken. Dentro de las 24 horas o ni te molestes. Para VoidedPurchaseNotification: revoca el acceso. Nuestro artículo sobre revocar el acceso después de un reembolso explica por qué ese paso es fácil de hacer mal, específicamente en Google.

Registra todo. La tasa de respuesta y la tasa de éxito son cifras distintas.

Hay algo que Google no te da: un PendingRefundReviewNotification de prueba. Lo configuras y esperas a que llegue un contracargo real. Por eso las herramientas alojadas muestran "awaiting first refund event" en lugar de una marca verde.

Las mejores herramientas para integrar Google Play RTDN, si tuviera que clasificarlas

Para la defensa de reembolsos de Google Play específicamente, es decir, responder a la revisión del contracargo con evidencia, la lista es corta. Refund Sensor lo hace con datos de consumo y sin código. RevenueCat lo hace solo con una preferencia, lo cual es mejor que el silencio, pero no por mucho. Todos los demás solo observan el feed.

Para la infraestructura general de RTDN y la sincronización de entitlements, tanto RevenueCat como Adapty son maduros y están bien documentados.

Para no tener que lidiar con nada de esto, un merchant of record como Tebex o Xsolla en una tienda web traslada la responsabilidad fuera de tus libros. Pero también saca la compra de Play, y no hace nada por las que se quedan.

Elige según el problema que tengas.

Conclusión

Google Play RTDN fue creado para contarte cosas. Solo recientemente comenzó a preguntar. El PendingRefundReviewNotification es la primera vez que Google quiere tu versión de la historia de un reembolso en Android, y llegó en la misma temporada en que Google empezó a hacerte pagar por los que pierdes.

Eso cambia las cuentas. Una herramienta que solo escucha las notificaciones de reembolso de Google Play estaba bien cuando un reembolso perdido te costaba solo la venta. Ahora es la venta más una comisión bancaria, y lo único entre tú y esa factura es una solicitud POST dentro de las 24 horas.

Configura el topic. Verifica qué envía realmente tu plataforma de vuelta. Si la respuesta es nada, o solo una preferencia, cierra esa brecha antes de que el próximo contracargo la encuentre.