Una compra se procesa, el cliente recibe su producto y tres días después todo desaparece. Google Play revierte el cargo y retira el derecho de acceso, sin que el cliente lo pida y sin que nadie de tu equipo de soporte toque un botón. La compra falló en silencio porque tu servidor nunca le dijo a Google que había sido procesada.
Esa es toda la regla: confirma una compra de Google Play dentro de tres días o Google la reembolsa y la revoca automáticamente. Siempre, sin excepciones. De todas las formas en que una venta puede revertirse en cualquiera de las dos tiendas, esta es una de las pocas que depende por completo de tu propia integración, lo que también la convierte en una de las maneras más silenciosas de perder ingresos.
No es un control antifraude ni una decisión de políticas. Es un callback que nunca se disparó. La solución es pequeña, pero el dinero que pierdes si te la saltas no lo es, así que vale la pena saber exactamente qué dice la regla, por qué las compras se le escapan y qué se lleva consigo cada venta que desaparece.
Lo que realmente exige la documentación de Google
Play Billing exige que tu app notifique a Google en cuanto haya otorgado el derecho de acceso y le haya dicho al usuario que la compra se completó. La documentación de Google lo deja en un número concreto: esta notificación "debe hacerse dentro de tres días para que la compra no se reembolse automáticamente y se revoque el derecho de acceso". La documentación de productos de pago único repite la misma línea sin matices. Si te saltas la confirmación, "el usuario recibe un reembolso automáticamente y Google Play revoca la compra". La compra inicial de una suscripción sigue exactamente la misma regla.
La confirmación no es un mero trámite. Es la única señal que tiene Google de que la entrega realmente ocurrió. Sin esa señal, Google asume que no se entregó nada, así que revierte todo el intercambio a favor del comprador sin consultarte. El comprador ve un reembolso inesperado. Tú ves una venta que desapareció de tus registros.
Puntos clave
Deja una venta sin confirmar durante 72 horas y la reversión ocurre sola: se le devuelve el dinero al comprador, se retira el derecho de acceso, y a nadie se le consulta. Ningún comprador provocó eso. Lo hizo tu backend, al no decir nada, y tu backend es igualmente capaz de evitarlo.
Llegar al estado PURCHASED es lo que pone en marcha la cuenta atrás, lo que hace que el momento del pago en sí sea irrelevante para tu plazo. Todo lo que permanece en PENDING no tiene ningún temporizador asociado y todavía no merece una llamada de confirmación.
Cualquiera de dos llamadas cumple con la obligación. Ejecuta purchases.products.consume para un consumible, o recurre a purchases.products.acknowledge y purchases.subscriptions.acknowledge para cualquier cosa que no lo sea. Google trata ambas como prueba de que el producto llegó.
Las suscripciones te piden esto exactamente una vez, al momento de darse de alta. Cada ciclo de facturación posterior lo resuelve Google por su cuenta, marcado como confirmado sin que tu código mueva un dedo.
¿Vendes un plan prepago que dura menos de siete días? Tu margen se reduce al cincuenta por ciento de la duración del plan. Producto más breve, mecha más corta.
Solo el precio de venta regresa al comprador. El tiempo de cómputo, el gasto en API de modelos, las facturas de almacenamiento, los pagos a creadores: ese dinero salió de tu cuenta durante la entrega y nada de eso regresa. El daño real supera lo que indica la línea del reembolso.
En iOS nada funciona así. StoreKit vuelve a presentar una transacción sin finalizar en cada inicio y espera con paciencia, sin revertir el cargo jamás. Esta exposición en particular existe únicamente en Google Play.
El plazo no empieza en el momento del pago
Tocar "comprar" no activa el temporizador. El estado de la compra primero tiene que pasar a PURCHASED, y algunas compras permanecen en PENDING antes de eso. Los métodos de pago en efectivo hacen esto, igual que las transferencias bancarias lentas y las solicitudes de aprobación parental. Google lo dice directamente: "La ventana de confirmación de tres días comienza solo cuando el estado de la compra pasa de PENDING a PURCHASED".
Esto implica dos cosas para la forma en que construyes el flujo. Otorga el derecho de acceso solo cuando el estado sea PURCHASED, nunca en PENDING, o estarás entregando producto por un dinero que quizás nunca llegue. Y tampoco confirmes una compra en PENDING, porque todavía no hay nada que confirmar. Llama a enablePendingPurchases() al configurar el BillingClient, espera a la transición de estado, y empieza a contar solo cuando llegue a PURCHASED.
Interpreta PENDING como "todavía no vendido". No se debe nada: ni derecho de acceso, ni confirmación, ni nada registrado como ingreso. En el instante en que cambia a PURCHASED, tanto el derecho de acceso como la cuenta atrás de tres días pasan a ser tu problema.
Elegir la llamada de API correcta según lo que vendiste
Hay dos caminos de API que cumplen con el plazo, y cuál aplica depende de qué vendiste. Ambos satisfacen el requisito por igual. Lo que los diferencia es qué le hacen al producto después.
Los consumibles se consumen. Eso es purchases.products.consume en un backend seguro, o consumeAsync() desde la Play Billing Library en el cliente. Consumir cumple una doble función, ya que satisface el requisito de confirmación y vuelve a poner el artículo a la venta. Eso es lo que necesitas para monedas, créditos o cualquier generación puntual que un cliente podría comprar repetidamente.
Los no consumibles y las suscripciones, en cambio, se confirman mediante purchases.products.acknowledge, purchases.subscriptions.acknowledge o acknowledgePurchase() en el cliente. Esto cumple con el plazo, pero no vuelve a habilitar el artículo para su compra.
Así es como cada tipo de producto se corresponde con una llamada y un plazo:
Para un consumible, llama a purchases.products.consume o consumeAsync(). Eso también vuelve a habilitar el artículo para su compra, y tu plazo es de tres días desde PURCHASED.
Para un no consumible, llama a purchases.products.acknowledge o acknowledgePurchase(). El derecho de acceso se confirma sin posibilidad de recompra, y tu plazo es de tres días desde PURCHASED.
Para la compra inicial de una suscripción, llama a purchases.subscriptions.acknowledge o acknowledgePurchase(). Eso confirma la nueva suscripción, y tu plazo es de tres días desde PURCHASED.
Para una renovación de suscripción, no necesitas ninguna llamada. Google la marca como confirmada por su cuenta, así que no hay plazo.
Para un plan prepago de menos de una semana, usa las mismas llamadas de confirmación, pero tu plazo se reduce a la mitad de la duración del plan.
La obligación termina en el primer pago
Las renovaciones de suscripción no necesitan confirmación en absoluto. Google lo dice directamente: "no necesitas confirmar las renovaciones de suscripción", y marca cada una como confirmada por su cuenta. Es solo la primera compra de una suscripción la que llega en un estado de confirmación pendiente y queda en tus manos hasta que la resuelvas. Verifica el estado de confirmación en el servidor, o usa isAcknowledged() en el cliente, antes de actuar. Así nunca enviarás una llamada de confirmación duplicada.
Un plazo más ajustado para los planes prepago de corta duración
Los planes prepago de una semana o más siguen la regla estándar de tres días. Los más cortos no. La documentación de Google indica que los planes "con una duración menor a una semana deben confirmarse dentro de la mitad de la duración del plan". Un plan prepago de tres días te da un día y medio, no la ventana completa. Si las recargas prepago cortas forman parte de tu catálogo, el proceso de confirmación tiene que ser rápido y estar impulsado por el servidor, nunca depender de que el cliente vuelva a abrir la app.
Dónde suele perderse la llamada de confirmación
Nadie se salta este paso a propósito. Se pierde porque la lógica de confirmación queda atada al disparador equivocado. El antipatrón más común es un cliente que solo confirma cuando el flujo de compra vuelve a primer plano. Eso cubre al cliente que termina de comprar y sigue usando la app justo después. No cubre a nadie más.
Los desarrolladores se topan con esto constantemente. Los hilos de la propia comunidad de desarrolladores de Google siguen siempre el mismo guion: alguna versión de un usuario al que se le reembolsa automáticamente tres días después de comprar, o una súplica por entender por qué los pagos siguen revirtiéndose solos al tercer día. El diagnóstico casi nunca cambia: la llamada de confirmación estaba atada a una acción del usuario que nunca ocurrió, así que simplemente nunca se disparó.
Las pruebas gratuitas y el cliente que nunca vuelve a abrir la app
La versión más fea de esto es una prueba gratuita, o una compra realizada en los últimos momentos antes de que alguien cierre tu app por última vez. Cuando la confirmación depende de la próxima apertura de la app y esa próxima apertura nunca llega, la compra simplemente vence. Google la reembolsa y la revoca al tercer día. Para una prueba que iba camino a convertirse, pierdes la primera facturación que nunca llegaste a cobrar, y un derecho de acceso de cliente se evapora silenciosamente junto con ella. Ninguno de los dos aparece en tu cola de soporte. Ambos aparecen como una compra anulada, siempre que te pongas a buscarla.
Una confirmación que depende de la próxima apertura de la app es una venta que pierdes cada vez que un cliente se mantiene alejado durante tres días. Las pruebas gratuitas y las compras de un solo toque son exactamente los momentos en que los clientes se alejan.
El costo real detrás de un reembolso por falta de confirmación
La línea del reembolso subestima lo que realmente perdiste. Google revierte la venta, tú devuelves el precio, y ese es el número que todos ven. No es el costo completo.
Piensa en un consumible que pone en marcha trabajo real en el momento en que alguien lo compra. Un lote de generaciones de imágenes, una serie de llamadas a la API de un proveedor de modelos, una exportación de video, un pago que se le debe a un creador. Pagaste por ese cómputo, esas llamadas de API, ese almacenamiento y esos pagos en el momento en que se usaron. El reembolso devuelve el precio de venta al cliente. No te devuelve a ti la factura del proveedor. Un costo real salió de tu bolsillo y nada regresó a cambio.
Para las suscripciones y las pruebas gratuitas, la pérdida es la primera facturación que nunca cobras, sumada a una relación con el cliente que terminó antes de empezar. Y las apuestas están por subir. 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 para los pedidos realizados después de esa fecha, lo que hace que valga la pena sellar ahora cualquier fuga evitable, en lugar de esperar. Un reembolso por falta de confirmación no es un contracargo, pero enseña la misma lección. El dinero que ya gastaste no se convierte automáticamente en dinero que conservas.
Cómo construir el paso de confirmación para que no se te escape
El patrón confiable saca por completo a tu app de la ruta crítica. Ejecútalo en tu backend, impulsado por notificaciones, no por si alguien vuelve a abrir una pantalla.
Suscríbete a las notificaciones de desarrollador en tiempo real. Un evento de compra de producto de pago único, o un evento de compra de suscripción, llega a tu servidor en el instante en que Google registra la venta, sin importar si la app está en ejecución o no.
Valida el token de compra mediante la Play Developer API y confirma que el estado sea PURCHASED y no PENDING.
Registra el derecho de acceso en tu propio sistema, vinculado a la cuenta de ese cliente.
Consume o confirma sin demora. Los consumibles se consumen, los no consumibles y las suscripciones iniciales se confirman. Lee primero el estado de confirmación para que la llamada nunca se envíe dos veces.
Mantén un respaldo del lado del cliente. Llamar a queryPurchasesAsync() en onResume() recoge cualquier cosa que se haya resuelto mientras la app estaba cerrada. Trátalo como un seguro, no como la vía principal.
El punto central es que la confirmación se dispara a partir de un evento que Google te entrega, y no de una acción del usuario que no tienes forma de garantizar. Alguien que compra una vez y nunca regresa sigue estando totalmente cubierto, porque tu servidor ya hizo el trabajo en el momento en que llegó la compra.
Una red de seguridad para lo que aún se escape
Sin importar cuán bien construido esté el pipeline, de todos modos merece una red de seguridad debajo. La Voided Purchases API de Google enumera los pedidos que terminaron en un reembolso, una revocación o un contracargo, y señala específicamente el escenario en el que la causa fue una compra que "nunca fue confirmada por el desarrollador, y por lo tanto podría no existir en los registros del desarrollador". Consúltala con regularidad y podrás retirar el acceso a cualquiera cuyo pedido Google haya anulado en silencio a tus espaldas. Ten en cuenta el límite, eso sí: solo se pueden recuperar los últimos 30 días, lo que hace de esto un trabajo programado y no algo que atiendes cada trimestre cuando te acuerdas.
iOS nunca fue diseñado para hacerte esto
Pasa a la App Store y nada de esto aplica. Apple construyó su propio paso de cierre, finalizar una transacción, solo que la penalización por saltárselo corre en dirección opuesta. Una transacción sin finalizar permanece estacionada en la cola de Apple. Vuelve a aparecer en cada inicio de la app, y de nuevo cada vez que se conecta el observer, lo que te da oportunidades repetidas de entregar lo que el cliente pagó. Apple no emite ninguna reversión por eso. En esa plataforma no existe nada parecido a un disparador de reembolso a las 72 horas.
Y por eso un solo modelo mental no puede aplicarse a ambas tiendas. Android te da una cuenta atrás y una venta que se evapora si la pierdes. iOS te da un recordatorio persistente y tiempo ilimitado para responder. Si llevas hábitos de iOS a una base de código de Android, tarde o temprano te encontrarás frente a un montón de pedidos revertidos que nadie en el equipo puede explicar.
Cerrar esa brecha es precisamente el trabajo que hace Refund Sensor. La confirmación se dispara directamente a partir de la notificación de la tienda, a los pocos instantes de que llega, mientras una pasada de reconciliación constante contra la Voided Purchases API retira el acceso donde Google ya haya anulado un pedido a tus espaldas. Una cuenta atrás que podrías perder se convierte en una casilla que ya estaba marcada antes de que se te ocurriera revisarla.
Dónde están documentadas estas reglas
Preguntas frecuentes
Tu servidor nunca envió la llamada de confirmación a tiempo. Cuando una compra queda sin confirmar más allá de los tres días desde que llega al estado PURCHASED, Google revierte la venta y retira el derecho de acceso automáticamente. No es algo que haya hecho el cliente, ni es una penalización impuesta por Google. Es una llamada de confirmación faltante, y confirmar desde el servidor a partir de la notificación de la tienda elimina el problema por completo.
Ambas detienen el plazo de tres días, pero dejan el producto en estados distintos. Consumir, mediante purchases.products.consume o consumeAsync(), es para productos consumibles. Esto cumple con el plazo y vuelve a poner el artículo a la venta. Confirmar, mediante purchases.products.acknowledge, purchases.subscriptions.acknowledge o acknowledgePurchase(), es para productos no consumibles y suscripciones. Esto confirma el derecho de acceso sin liberar el producto para una nueva compra.
No, solo la primera compra. Google no exige confirmar las renovaciones y las marca como confirmadas automáticamente. Es solo la compra inicial de la suscripción, que llega en un estado de confirmación pendiente, la que sigue siendo tu responsabilidad hasta que la resuelvas.
No, espera a que llegue a PURCHASED. Una compra en estado PENDING, como un pago en efectivo o una solicitud de aprobación parental, todavía no ha iniciado el plazo de tres días. Otorga el derecho de acceso y envía la confirmación solo una vez que el estado haya cambiado realmente de PENDING a PURCHASED.
No, y vale la pena saberlo antes de asumir que Android e iOS funcionan igual. Una transacción de StoreKit sin finalizar simplemente se vuelve a entregar en cada inicio de la app hasta que la finalices. Apple nunca la reembolsa automáticamente. El reembolso automático a los tres días es exclusivo de Google Play, así que ambas plataformas necesitan un manejo distinto.
El reembolso en sí no se puede revertir. Lo que sí puedes hacer es reconciliar. La Voided Purchases API muestra las compras reembolsadas y revocadas de los últimos 30 días, y marca específicamente las que se anularon por no haberse confirmado nunca, para que puedas revocar el derecho de acceso que otorgaste. De ahí en adelante, confirmar desde la notificación de la tienda es lo que evita que se te escape la siguiente.
