No confirmes una compra de Google Play en tres días y Google la reembolsa, esto es lo que te cuesta

Un cliente compra tu producto, el cargo se procesa y tres días después Google Play lo reembolsa en silencio y retira lo que entregaste. Nadie pidió ese reembolso. El cliente no lo solicitó y ningún agente de soporte lo concedió. Se activó porque tu servidor nunca le dijo a Google que la compra estaba gestionada. Si no confirmas una compra de Google Play en tres días, Google reembolsa al comprador y revoca la compra, siempre. Es uno de los pocos reembolsos en cualquiera de las dos tiendas que depende por completo de tu integración para evitarse, y una de las formas más silenciosas de perder ingresos.

Esto no es un problema de fraude ni una disputa de políticas. Es una devolución de llamada perdida. La solución es pequeña y el coste de omitirla es dinero real, así que vale la pena conocer la regla con exactitud, por qué las compras se quedan sin confirmar y lo que realmente se lleva consigo cada venta perdida.

Lo que dice en realidad la regla de los tres días

La documentación de Play Billing de Google es tajante al respecto. Después de que tu app conceda el derecho y le diga al usuario que la compra fue correcta, tiene que notificar a Google que la compra se procesó. En palabras de Google, esto "debe hacerse en un plazo de tres días para que la compra no se reembolse automáticamente y se revoque el derecho". La página del producto de un solo uso lo repite sin suavizarlo: "Si no confirmas una compra en tres días, el usuario recibe automáticamente un reembolso y Google Play revoca la compra". Las suscripciones aplican la misma regla para la compra inicial.

La confirmación es una señal, no un trámite. Le dice a Google que el derecho llegó al usuario. Google trata la ausencia de esa señal como una entrega que nunca ocurrió, y deshace la transacción en nombre del cliente. Desde el lado del comprador parece un reembolso gratuito que nunca pidió. Desde el tuyo parece una venta que se evaporó.

El reloj empieza en PURCHASED, no en el pago

La ventana de tres días no empieza cuando el usuario toca comprar. Empieza cuando el estado de la compra pasa a PURCHASED. Una compra puede quedarse primero en PENDING, lo que ocurre con pagos en efectivo, transferencias bancarias lentas o un padre aprobando la solicitud de un hijo. Google es explícito: "La ventana de confirmación de tres días empieza solo cuando el estado de la compra pasa de PENDING a PURCHASED".

Eso tiene dos consecuencias. Concede el derecho solo cuando el estado es PURCHASED, nunca en PENDING, o entregarás el producto por un pago que puede no completarse nunca. Y tampoco confirmes una compra en PENDING. Llamas a enablePendingPurchases() cuando construyes el BillingClient, esperas la transición y solo entonces empieza a contar el reloj de confirmación en tu cabeza.

Confirmar o consumir, y cuál te toca

Hay dos formas de cumplir el requisito, y cuál usas depende del producto. Ambas cumplen el plazo de tres días. La diferencia es lo demás que hacen.

Para un consumible, lo consumes. En un backend seguro eso es purchases.products.consume, o del lado del cliente consumeAsync() en la Play Billing Library. Consumir confirma la compra y a la vez vuelve a hacer el producto comprable, que es justo lo que quieres para monedas, créditos o una generación de un solo uso. Para un no consumible o una suscripción, lo confirmas: purchases.products.acknowledge o purchases.subscriptions.acknowledge en el backend, o acknowledgePurchase() del lado del cliente. Confirmar cumple el plazo sin liberar el producto para una nueva compra.

Las renovaciones ya están gestionadas, las compras iniciales no

Solo debes confirmar la primera compra de una suscripción. Google afirma con claridad que "no necesitas confirmar las renovaciones de suscripción", y estampa las renovaciones como ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED por su cuenta. Una compra nueva llega como ACKNOWLEDGEMENT_STATE_PENDING y sigue siendo tu responsabilidad hasta que la despejes. Antes de confirmar, comprueba acknowledgementState en el backend o isAcknowledged() del lado del cliente para no confirmar dos veces.

Los planes prepago tienen una mecha más corta

Los planes de suscripción prepago ajustan la ventana. La regla de Google: los planes prepago que duran una semana o más deben confirmarse en tres días, pero "los planes prepago con una duración menor a una semana deben confirmarse en la mitad de la duración del plan". Un plan prepago de tres días te da un día y medio, no tres días. Si vendes recargas prepago cortas, tu ruta de confirmación tiene que ser rápida y dirigida por el servidor, no depender de que el usuario vuelva a abrir la app.

Por qué las compras se quedan sin confirmar en primer lugar

Nadie se propone saltarse la confirmación. Se escapa porque el código que confirma está en el lugar equivocado. El antipatrón común es un cliente que confirma solo cuando el flujo de compra regresa en primer plano. Eso funciona para un usuario que termina de comprar y sigue usando la app. Falla con todos los demás.

Los desarrolladores se topan con esto constantemente. Los hilos en la propia comunidad de desarrolladores de Google se leen igual cada vez, alguna variante de "a un usuario se le reembolsó automáticamente después de comprar en mi app tras tres días" y "por qué los pagos se reembolsan automáticamente después de tres días". La respuesta casi siempre es la misma: la llamada de confirmación nunca se disparó porque la app nunca estuvo en un estado para dispararla.

La prueba gratuita y el usuario que nunca vuelve

La peor versión es la prueba gratuita o una compra justo antes de que el usuario cierre la app para siempre. Si tu confirmación depende de la próxima apertura de la app, y no hay próxima apertura, la compra caduca. Al tercer día Google la reembolsa y la revoca. Para una prueba que se habría convertido en una suscripción de pago, pierdes el primer cobro que nunca llegaste a recaudar, más un derecho de cliente que desapareció en silencio. Ninguno de los dos aparece como un ticket de soporte. Aparece como una compra anulada que tienes que ir a buscar.

Lo que cuesta en realidad un reembolso sin confirmar

La línea del reembolso subestima la pérdida. Cuando Google revierte la venta, devuelves el precio, y ese es el número visible. No es la factura completa.

Piensa en un consumible que dispara trabajo real en el momento en que se compra. Un lote de generaciones de imágenes, una serie de llamadas a la API de un proveedor de modelos, una exportación de vídeo, un pago a un creador. Pagaste por ese cómputo, esas llamadas a la API, ese almacenamiento y esos pagos en el momento de uso. El reembolso devuelve el precio de venta al cliente. No te devuelve la factura del proveedor. Entregaste un coste real y no recibiste nada a cambio.

Para suscripciones y pruebas, la pérdida es el primer cobro que nunca recaudas y la relación con el cliente que terminó antes de empezar. Y a partir del 3 de agosto de 2026, Google Play traslada a los desarrolladores el precio de compra de los contracargos y las comisiones bancarias en los pedidos realizados después de esa fecha, lo que hace que valga la pena cerrar ahora, y no más tarde, cualquier fuga de ingresos evitable. Un reembolso sin confirmar no es un contracargo, pero es la misma lección: el dinero que ya gastaste no es automáticamente dinero que conservas.

Cómo confirmar una compra de Google Play desde el servidor

El patrón fiable saca la app de la ruta crítica. Hazlo en tu backend, impulsado por notificaciones, no por que el usuario vuelva a abrir la pantalla.

• Escucha las Real-time developer notifications. Un evento de compra ONE_TIME_PRODUCT o SUBSCRIPTION_PURCHASED le dice a tu servidor que existe una compra en el instante en que Google lo sabe, esté o no abierta la app.
• Verifica el token de compra contra la Play Developer API y confirma que el estado es PURCHASED, no PENDING.
• Concede el derecho en tus propios registros, asociado al usuario.
• Confirma o consume de inmediato. Consume los consumibles, confirma los no consumibles y las suscripciones iniciales. Comprueba acknowledgementState primero para no confirmar nunca dos veces.
• Rellena también en el cliente. Llama a queryPurchasesAsync() en onResume() para que cualquier compra que se completó mientras la app estaba cerrada aún se procese. Esto es una red de seguridad, no la ruta principal.

El punto es que la confirmación se dispara desde un evento que Google te envía, no desde una acción del usuario con la que no puedes contar. Un usuario que compra y nunca vuelve queda totalmente cubierto porque tu servidor actuó en el momento en que llegó la compra.

Una red de reconciliación para las que se escapan

Incluso una tubería limpia se beneficia de una comprobación. La Voided Purchases API lista las compras que fueron reembolsadas, revocadas o con contracargo, y nombra el caso en que el motivo es que la compra "nunca fue confirmada por el desarrollador y, por lo tanto, puede no existir en los registros del desarrollador". Consúltala y podrás revocar el derecho que concediste por cualquier cosa que Google ya haya deshecho. Ten en cuenta el límite: la API solo devuelve compras anuladas de los últimos 30 días, así que la reconciliación tiene que ejecutarse según un calendario, no una vez por trimestre.

Apple no tiene un equivalente, y eso importa

Este es un problema específico de Google Play. StoreKit de Apple también tiene un paso de finalización, finalizar una transacción, pero hace lo contrario ante un fallo. Si nunca finalizas una transacción de StoreKit, Apple la mantiene en la cola y la vuelve a entregar cada vez que tu app se inicia o el observador se conecta, así que tienes otra oportunidad de conceder el derecho. Apple no reembolsa una transacción sin finalizar. No hay un reembolso automático de tres días en el App Store.

Así que el modelo mental tiene que seguir siendo específico de cada plataforma. En Google Play, una compra sin gestionar es un reembolso a punto de ocurrir y un plazo contra el que corres. En el App Store, una compra sin gestionar es una reentrega a punto de ocurrir y ningún reloj en absoluto. Trasladar la suposición de Apple a Android es como los equipos acaban con un muro de reembolsos sin confirmar que no pueden explicar.

Por eso RefundHalt confirma las compras de Google Play automáticamente en el momento en que llega la notificación de la tienda, y las reconcilia contra la Voided Purchases API para que un derecho concedido por una compra que Google luego deshizo no siga activo. La regla de los tres días deja de ser una carrera que puedes perder y se convierte en un paso que ya ocurrió.