Usa Google Play RTDN para el manejo rápido de eventos. Usa la API de Compras Anuladas para verificar los pedidos anulados y reconciliar tus registros. Para la mayoría de las apps de pago, la opción más segura es usar ambas.
Si estás planeando una defensa contra reembolsos de Google Play para apps, comienza con esa división. Un camino te indica que algo cambió. El otro permite que tu servidor obtenga una lista de compras anuladas y verifique qué se le ha pasado por alto.
La elección no es exactamente entre dos sistemas de notificación. Google Play RTDN envía mensajes mediante Cloud Pub/Sub. La API de Compras Anuladas es una API de tipo pull: tu backend la consulta.
Ninguna de las dos, por sí sola, evita que alguien solicite un reembolso. Su valor está en detectar cambios, verificar pedidos y asegurarse de que el acceso de pago coincida con el estado de la compra.
Puntos clave
Usa RTDN para reaccionar con rapidez a los eventos de compras y suscripciones.
Usa la lista de compras anuladas como una segunda vía para verificar los pedidos afectados.
No trates una suscripción cancelada como prueba de un reembolso.
Haz que ambas vías utilicen la misma lógica segura de actualización de acceso.
Mantén la revisión pendiente de contracargo separada de una anulación completada.
¿Qué es Google Play RTDN?
Google Play Real-Time Developer Notifications, conocido generalmente como RTDN, envía eventos relacionados con compras a un topic de Cloud Pub/Sub.
Tu backend recibe un mensaje y lo dirige al worker correspondiente. El tipo de mensaje importa. Una renovación, una cancelación y una compra anulada no son el mismo evento.
Para el seguimiento de reembolsos, presta mucha atención a voidedPurchaseNotification. Incluye:
purchaseToken: vincula el evento con una compra.
orderId: identifica el pedido afectado.
productType: identifica una suscripción o una compra única.
refundType: distingue una anulación total de un reembolso parcial basado en cantidad.
La referencia de RTDN y las definiciones de eventos de Google explican estos campos y los demás tipos de notificación.
RTDN es útil cuando quieres actuar poco después de un cambio. Pero un mensaje no es tu base de datos completa de compras. Compáralo con los registros almacenados y recupera el estado de compra correspondiente cuando sea necesario antes de modificar el acceso.
¿Una cancelación de suscripción significa un reembolso?
No. Un cliente puede detener futuras renovaciones y, aun así, conservar el acceso de pago durante el resto del período actual.
No crees una regla que elimine el acceso cada vez que llegue SUBSCRIPTION_CANCELED. En su lugar, verifica el estado de la suscripción y su fecha de vencimiento. La revocación y el vencimiento necesitan su propio manejo.
¿Qué es la API de Compras Anuladas?
La API de Compras Anuladas de Google Play devuelve una lista de compras que fueron canceladas, reembolsadas o sujetas a contracargo dentro de su alcance admitido.
Se aplica a pedidos únicos dentro de la app y a suscripciones. Tu servidor puede usar los resultados para verificar qué compras ya no deberían otorgar acceso.
La lista puede incluir el ID del pedido, el token de compra, la hora de la anulación, la fuente de la anulación y el motivo de la anulación. Para los reembolsos parciales basados en cantidad admitidos, también puede incluir la cantidad reembolsada.
La guía de la API de Compras Anuladas de Google documenta una ventana retrospectiva de 30 días. No es un archivo permanente de reembolsos. Guarda los registros procesados en tu propio sistema.
Esta API es especialmente útil después de una interrupción del worker, un error de enrutamiento o un vacío en tus registros locales. También te brinda una verificación de rutina frente a los eventos que ya procesaste.
RTDN vs. API de Compras Anuladas: la diferencia práctica
Pregunta | Google Play RTDN | API de Compras Anuladas |
¿Cómo funciona? | Google publica un evento en Pub/Sub. | Tu servidor solicita una lista. |
¿Cuál es su función principal? | Manejo rápido de los cambios en el estado de la compra. | Verificación y reconciliación de pedidos anulados. |
¿Cubre eventos más allá de los reembolsos? | Sí, incluidas las renovaciones y otros eventos del ciclo de vida. | Se centra en las compras anuladas. |
¿Puede ayudar después de un vacío de procesamiento? | La recuperación de Pub/Sub depende de tu configuración y retención. | Puede listar los registros disponibles dentro de la ventana de 30 días. |
¿Necesita protección contra duplicados? | Sí. | Sí, especialmente cuando los escaneos se superponen o comparten eventos con RTDN. |
La pregunta clave no es cuál herramienta es mejor por sí sola. Es qué tipo de falla ayuda a resolver cada herramienta.
RTDN te da una vía rápida. La API te da una vía de verificación. Tu propia base de datos debería unificarlas.
¿Cuál debería usar tu app?
Usa RTDN cuando la velocidad importa
Una app de pago no debería tener que esperar un escaneo programado para notar un cambio en el estado de la compra.
Usa RTDN cuando tu app necesite actualizaciones rápidas para suscripciones, compras únicas y pedidos anulados. Dirige cada evento según su tipo en lugar de aplicar una sola regla de reembolso a todos los mensajes.
Usa la API cuando la integridad importa
Usa verificaciones programadas de la API para encontrar pedidos anulados que tu worker no aplicó a tus registros.
Por ejemplo, tu receptor puede haber aceptado un mensaje, pero un error puede haber impedido la posterior actualización de acceso. Arreglar la entrega por sí sola no resolverá ese vacío local.
Usa ambas para un flujo de trabajo de reembolsos en producción
Para la mayoría de las apps de pago, combínalas. Haz que ambas vías alimenten un único manejador compartido que verifique el pedido y aplique cualquier cambio de forma segura.
Esto reduce el riesgo de que un evento no detectado deje el acceso activo. También reduce el riesgo contrario: eliminar el acceso dos veces por el mismo reembolso.
Cómo detectar reembolsos de Google Play paso a paso
1. Mantén un libro de registro de compras
Almacena el paquete de la app, el token de compra, el ID del pedido, el producto, la asignación de usuario y la cantidad otorgada. Un libro de registro es simplemente un registro claro de lo que se compró y qué acceso otorgó.
Para las suscripciones, almacena también los ID de pedido de cada renovación. La referencia de RTDN señala que cada renovación automática tiene un nuevo ID de pedido. Un token de compra por sí solo no basta para identificar cada renovación afectada.
2. Protege y dirige los mensajes de RTDN
Configura correctamente el acceso a Pub/Sub. Para la entrega push, verifica la solicitud autenticada. Para la entrega pull, restringe quién puede leer la suscripción.
Decodifica el mensaje, verifica el nombre del paquete y guárdalo antes de ejecutar tareas lentas. Envía eventos de prueba a través de toda la ruta, no solo al endpoint receptor.
3. Ejecuta un escaneo programado de compras anuladas
Llama al método de listado con las credenciales adecuadas y los permisos de Play Console correspondientes. Recorre todas las páginas de resultados.
Dos parámetros de la consulta son fáciles de pasar por alto:
type=1 incluye tanto compras únicas como suscripciones. El valor predeterminado, 0, incluye solo compras únicas.
includeQuantityBasedPartialRefund=true incluye los reembolsos parciales basados en cantidad admitidos. Su valor predeterminado es false.
La referencia del método voidedpurchases.list de Google cubre los campos de la solicitud y la paginación.
Usa una superposición moderada entre escaneos y elimina duplicados en los resultados. Elige la frecuencia de escaneo según tu volumen, tus cuotas y cuánto retraso puede aceptar tu app. No esperes hasta que la ventana retrospectiva esté casi por terminar.
4. Aplica cada cambio solo una vez
Ambas vías pueden reportar la misma anulación. Crea un manejo idempotente: aplicar el mismo cambio otra vez no debería alterar el resultado.
No uses solo el ID del pedido para descartar todos los eventos posteriores. Una compra de varias unidades puede tener varios reembolsos parciales. Lleva el seguimiento de los ajustes procesados y de las cantidades reembolsadas para que un reembolso real posterior no se pierda.
5. Monitorea el vacío, no solo el conteo de mensajes
Lleva el registro del último escaneo exitoso, las páginas inconclusas, los errores del worker y los pedidos sin coincidencia. Mide cuánto tiempo toma actualizar el acceso después de un evento confirmado.
Para un panorama de reportes más amplio, consulta nuestra guía de herramientas de seguimiento de reembolsos y contracargos para apps móviles.
Ejemplo: un reembolso, dos vías de detección
Este es un flujo de trabajo hipotético, no un caso reportado de un cliente.
Un jugador compra un paquete único que otorga 500 monedas. Más tarde, la compra se anula por completo.
RTDN envía un mensaje de compra anulada. Tu worker encuentra el pedido, verifica la asignación registrada y aplica tu política publicada a las monedas vinculadas a esa compra.
Más tarde, el escaneo programado de la API devuelve el mismo pedido. El manejador compartido ve que el ajuste de anulación total ya se aplicó. Registra la coincidencia y no realiza una segunda deducción.
Ahora supongamos que el worker falló antes de aplicar el primer cambio. El escaneo encuentra el pedido y le da a tu sistema otra vía para procesarlo.
Ese es el sentido de usar ambas. No dos castigos distintos, sino dos caminos para llegar a un mismo resultado correcto.
Si ya se gastaron algunas monedas, no elimines monedas de forma arbitraria de un paquete de pago no relacionado. Usa una política clara, explica la acción y ofrece una vía de soporte.
La revisión de reembolso pendiente es un flujo de trabajo distinto
La documentación actual de Google también incluye pendingRefundReviewNotification para una solicitud de contracargo que requiere revisión por parte del desarrollador.
Para ese evento, Google indica que se debe proporcionar una sugerencia de reembolso y evidencia de uso de la compra a través de orders.reviewrefund dentro de las 24 horas.
No lo confundas con voidedPurchaseNotification. Uno se refiere a una revisión pendiente. El otro informa sobre una compra que ya ha sido anulada.
La API de Compras Anuladas no reemplaza el manejo de un evento de revisión pendiente. Mantén esa rama separada y no asumas que toda solicitud de reembolso la genera.
Reembolsos en App Store y fuga de ingresos: lo que los desarrolladores deben saber
La fuga de ingresos no se limita a si una tienda devuelve dinero. También puede significar que tu backend sigue otorgando acceso de pago después de que la compra correspondiente ya no lo respalda.
Para los equipos que trabajan en ambas plataformas, el objetivo es similar: mantener alineados el dinero, el estado de la compra y los registros de acceso. Sin embargo, las herramientas de cada tienda y las reglas de eventos son distintas. No copies un flujo de trabajo de Apple en Google Play sin adaptarlo.
Nuestra guía de gestión de ingresos por reembolsos en App Store cubre el problema más amplio de la gestión de ingresos. Para esta integración con Google Play, concéntrate primero en las anulaciones no detectadas, las deducciones duplicadas y los cambios incorrectos de acceso a suscripciones.
Qué puede y qué no puede hacer la prevención de fraude en reembolsos de Google Play
La prevención de fraude en reembolsos de Google Play comienza con registros sólidos y reglas justas. Un pedido anulado no es prueba de que el cliente actuó de manera deshonesta.
Un usuario puede tener un reclamo válido. Un pago puede fallar. Tu app puede haber entregado el artículo equivocado.
Usa estas herramientas para verificar los hechos y aplicar cambios de acceso. Revisa los patrones repetidos en contexto. Evita las suspensiones automáticas de cuentas basadas en un solo reembolso y permite que los clientes puedan cuestionar los errores.
Ni RTDN ni la API de listado garantizan que puedas prevenir, rechazar o revertir un reembolso.
Conclusión
La elección entre RTDN y la API de Compras Anuladas no es una decisión excluyente para la mayoría de las apps de pago.
Usa RTDN para reaccionar con rapidez. Usa verificaciones programadas de compras anuladas para reconciliar registros. Dirige ambas a través de un único manejador seguro y mantén las revisiones pendientes separadas de las anulaciones completadas.
Comienza con una prueba pequeña: envía una anulación a través de ambas vías y confirma que el acceso cambia solo una vez. Luego, detén tu worker y verifica que tu vía de recuperación detecte el vacío.
Preguntas frecuentes
RTDN es más adecuado para el manejo rápido de eventos. La API es más adecuada para las verificaciones programadas de pedidos anulados. La mayoría de las apps de pago se benefician de usar ambas.
Sí. Incluye una notificación de compra anulada con detalles del pedido y del tipo de reembolso. Maneja ese evento por separado de una cancelación de suscripción.
Puedes detectar los registros anulados disponibles mediante sondeo (polling), pero la detección depende de tu próximo escaneo exitoso. Además, te perderías el flujo más amplio de eventos del ciclo de vida de RTDN.
Google documenta una ventana de 30 días. Mantén tus propios registros para verificaciones a largo plazo y necesidades de soporte.
Sí. Habilita los resultados de reembolsos parciales admitidos en las solicitudes de listado. Lleva el seguimiento de las cantidades reembolsadas y considera que un pedido puede tener más de un reembolso parcial.
