Respuesta rápida: Google Play te ofrece dos formas de saber que una compra fue reembolsada o revocada. Las Real-time Developer Notifications (RTDN) envían eventos a tu servidor en el momento en que ocurren, mediante Google Cloud Pub/Sub. La Voided Purchases API te permite consultar una lista de compras anuladas cuando lo necesites. No son alternativas: RTDN te da velocidad, la Voided Purchases API te da una red de seguridad, y una configuración confiable usa ambas para que nada se escape.
Por qué Google te ofrece dos mecanismos
En Google Play, la mayoría de los reembolsos ocurren sin consultarte: Google los emite, revoca el derecho (entitlement) y tu tarea es enterarte para que tu app y tus analíticas se mantengan precisas. (Para saber qué puedes y qué no puedes disputar, consulta Google Play Refunds & Chargebacks.)
Google ofrece dos herramientas distintas para enterarte, y cada una resuelve el problema desde un ángulo opuesto. Una te envía eventos a medida que ocurren. La otra te permite solicitar una lista cuando quieras. Usadas en conjunto, cubren las debilidades de la otra; usadas por separado, cada una deja un vacío.
Para los desarrolladores enfocados en el seguimiento de reembolsos en Android, entender esta diferencia es importante porque un flujo de eventos en tiempo real y un mecanismo de conciliación histórica resuelven partes distintas del problema de monitoreo de reembolsos.
Real-time Developer Notifications (push)
Real-time Developer Notifications (RTDN) es el mecanismo push. Cuando algo le sucede a una suscripción o compra, incluyendo reembolsos y compras anuladas, Google publica un evento en un topic de Google Cloud Pub/Sub al que tu backend está suscrito. El objetivo es la inmediatez: te enteras del evento casi en el momento en que ocurre, en lugar de descubrirlo horas después.
Para los desarrolladores que buscan integrar RTDN en Google Play, este es el mecanismo que conecta los eventos de facturación de Google Play con tu backend. Para todo lo urgente, como una revisión de contracargo (chargeback), donde tienes aproximadamente 24 horas para responder, esta inmediatez lo es todo. Si dependes de revisar periódicamente, ya perdiste un tiempo que no tenías.
La trampa: RTDN funciona sobre Pub/Sub, lo que implica configurar un proyecto de Google Cloud, un topic, los permisos de publicación correctos para Google Play y un suscriptor de tu lado. Son más piezas en movimiento que un simple webhook, y es justo donde muchos desarrolladores se atascan.
La Voided Purchases API (pull)
La Google Play Voided Purchases API es el mecanismo pull. Devuelve una lista de pedidos que han sido anulados, reembolsados, sujetos a contracargo o revocados, que puedes consultar cuando lo necesites. En lugar de esperar un evento, le preguntas directamente a Google: ¿qué se ha anulado?
Su fortaleza es la integridad y la recuperación. Si una notificación push se retrasó, se perdió o nunca se procesó, una consulta a la Google Play Voided Purchases API igualmente revela la compra anulada. Así es como concilias y te aseguras de que tu registro coincida con el de Google.
La contrapartida es que no es instantánea por naturaleza: es algo que consultas, así que por sí sola funciona como una red de seguridad y no como un disparador.
Por qué necesitas ambas, no solo una
Esta es la distinción que confunde a muchos: no se trata de decidir «cuál es mejor».
Solo RTDN te da velocidad, pero sin garantía de integridad: si pierdes o manejas mal una notificación, ese evento simplemente desaparece de tu vista.
Solo la Voided Purchases API te da integridad, pero no velocidad: solo te enterarías de un reembolso la próxima vez que hagas una consulta.
RTDN de Google Play le da a tu backend una señal en tiempo real, mientras que la Google Play Voided Purchases API ofrece la capa de conciliación para los eventos perdidos o retrasados.
Una configuración confiable usa RTDN como disparador en tiempo real y la Voided Purchases API como la capa de conciliación que recupera todo lo que la vía push dejó pasar. Velocidad más una red de seguridad. Cualquiera de las dos por sí sola deja un hueco por el que eventualmente caerás.
Dónde esto se complica
Configurar esto correctamente implica más trabajo del que parece, y el esfuerzo es continuo, no algo que se hace una sola vez:
Aprovisionamiento de Pub/Sub. Crear el topic, otorgarle a Google Play el permiso para publicar, suscribir tu backend y dejar los permisos exactamente bien configurados es el paso con más probabilidades de consumirte una tarde o tres. Esta configuración de Pub/Sub para Play Billing también debe seguir siendo confiable a medida que crece tu infraestructura de facturación.
Dos sistemas que mantener sincronizados. Ahora estás ejecutando un consumidor push y un trabajo programado de consulta y conciliación, y debes asegurarte de que ambos coincidan.
Deduplicación y orden. El mismo evento puede llegarte más de una vez, o fuera de orden; tu manejo tiene que ser idempotente.
Mantenerse al día. Google revisa sus APIs de facturación y los tipos de eventos, y tu integración tiene que mantener el ritmo o quedará desactualizada sin que lo notes.
Notificaciones de reembolso de Google Play. Tu sistema necesita procesar correctamente cada notificación de reembolso relevante de Google Play y vincularla con la compra, el derecho (entitlement) y el registro de cliente correctos.
Por separado, nada de esto es exótico. En conjunto, es una pieza real de infraestructura que hay que construir y mantener, todo por el privilegio de registrar con precisión reembolsos que, en su mayoría, de todos modos no puedes disputar.
Cómo encaja esto en el manejo de reembolsos
Si juntas las piezas, el manejo de reembolsos de Google Play tiene dos mitades: atrapar la única cosa que puedes disputar (la revisión de contracargo) dentro de su ventana de tiempo, y registrar con precisión todo lo que no puedes disputar para que tus derechos (entitlements) y analíticas se mantengan fieles a la realidad. Ambas mitades dependen de que la base de RTDN + Voided Purchases sea sólida.
Para los equipos que se preguntan cómo rastrear reembolsos de Google Play con RTDN y la Voided Purchases API, la respuesta es usar RTDN para la detección rápida de eventos y la Voided Purchases API para la conciliación y recuperación. Esto le da a tu backend una visión más completa de los reembolsos, las compras anuladas y los contracargos.
Esta es exactamente la capa que RefundSensor gestiona por ti. Aprovisiona automáticamente el topic de Pub/Sub para que solo tengas que pegar un nombre de topic en Play Console, consume RTDN en tiempo real, concilia contra las compras anuladas para que nada se pierda, envía una recomendación de rechazo en las revisiones de contracargo dentro de su ventana de tiempo, y registra cualquier otro reembolso, todo en un solo dashboard junto con tus reembolsos de Apple. Obtienes el resultado de una configuración correcta con dos mecanismos sin tener que construir ni mantener ninguno de los dos.
Fuentes oficiales {#official-sources}
Las APIs de facturación de Google cambian, así que trata su documentación como la autoridad final:
Una sola configuración, ambos mecanismos, cero mantenimiento. RefundSensor aprovisiona automáticamente Pub/Sub, consume RTDN en tiempo real, concilia con las compras anuladas y gestiona las revisiones de contracargo para Google Play y Apple, en un solo dashboard. Comenzar gratis →
Enlaces internos por agregar una vez publicado: artículo pilar de reembolsos de Google Play · artículo pilar de automatización de reembolsos de Apple · la ventana de 12 horas.
Preguntas frecuentes
RTDN envía eventos a tu servidor en tiempo real a través de Pub/Sub; la Voided Purchases API te permite consultar una lista de pedidos anulados cuando lo necesites. RTDN te da velocidad, la Voided Purchases API te da integridad.
Para una configuración confiable, sí. RTDN es tu disparador en tiempo real y la Voided Purchases API es tu red de seguridad de conciliación para todo lo que la vía push haya dejado pasar. Cada una por separado deja un vacío.
Un pedido que ya no es válido, generalmente debido a un reembolso, un contracargo o una revocación. Hacer seguimiento de las compras anuladas mantiene precisos tus derechos (entitlements) y tus analíticas.
RTDN funciona sobre Google Cloud Pub/Sub, lo que implica un topic, permisos de publicación para Google Play y un suscriptor de tu lado: más piezas en movimiento que simplemente pegar una URL. RefundSensor aprovisiona automáticamente el topic de Pub/Sub para eliminar esa fricción.
En su mayoría, no. Los reembolsos y revocaciones ordinarios los decide Google. El único caso que puedes disputar es un contracargo en revisión, el cual deberías detectar mediante RTDN y responder dentro de su ventana de aproximadamente 24 horas.
