El primer contracargo que se me escapó llegó a las 11:40 de un sábado por la noche. Solo lo sé porque el lunes me puse a revisar los registros de Pub/Sub y lo encontré ahí, en un topic que nadie estaba consumiendo.
Eso fue antes del 3 de agosto de 2026. En ese entonces, perder un caso te costaba la venta y poco más.
Ahora Google Play traslada los costos de los contracargos a los desarrolladores en los pedidos realizados después de esa fecha. Tú absorbes el importe del pedido menos la comisión de servicio de Google, más una comisión de la red de tarjetas de entre $15 y $25 por caso. A cambio, también te dieron algo: la Review Refund API y alrededor de 24 horas para presentar pruebas.
Así que la pregunta no es si gestionas los contracargos. Es qué los gestiona a medianoche. La configuración está en la defensa contra contracargos de Google Play. Esta es la versión larga: cuatro opciones, de las cuales a dos de ellas disuadiría a la mayoría de los equipos de elegir.
Puntos clave
La gestión de contracargos de Google Play tiene un único punto de entrada: la ReviewRefund API, dentro de las 24 horas posteriores a un Pending Refund Review Notification.
Google registra tu primera llamada e ignora el resto, aunque sigue devolviendo OK. Una sola oportunidad, sin correcciones.
Solo los contracargos se pueden impugnar. Los reembolsos de soporte, los reembolsos de Play de 48 horas y las pruebas gratuitas no reconocidas se deciden sin ti.
Cuatro alternativas reales: construirlo tú mismo, usar tu plataforma de suscripciones, comprar un software o asumir la pérdida.
Los números cambiaron el 3 de agosto de 2026. Si pierdes el plazo en un plan anual de $99, te cuesta el importe del pedido más una comisión de la red.
Cómo es en realidad la gestión manual
Para ser justos, "manual" abarca un rango amplio. En un extremo es una bandeja de entrada compartida y alguien que revisa Play Console cuando se acuerda. En el otro es un calendario de turnos, un canal de Slack, una hoja de cálculo con los pedidos en disputa.
Esa segunda versión es mejor. Pero igual falla, por razones que no tienen nada que ver con el esfuerzo.
Primero, no puedes ver el reloj. Las 24 horas comienzan cuando un PendingRefundReviewNotification llega a tu topic de Pub/Sub. ¿Nunca activaste las notificaciones de desarrollador en tiempo real? Nada te avisa que hay una revisión abierta, y Play Console no lo marcará.
Segundo, y esto sorprende a la gente: Google registra tu primera llamada a ReviewRefund e ignora todas las que vienen después, aunque siga devolviendo OK. Parece que funcionó. Que alguien escriba una respuesta en un script a las 9 a.m., con datos extraídos a mano, es exactamente como se termina con un campo mal puesto y sin forma de deshacerlo.
Esforzarte más no soluciona ninguno de los dos problemas.
El proceso de contracargos de Google Play
Vale la pena detallarlo, porque el plazo es más corto de lo que la gente supone.
El cliente disputa el cargo con su banco. No contigo, ni con Google.
Google marca el pedido para revisión y envía un PendingRefundReviewNotification a través de RTDN, con un pendingRefundToken, el orderId, un refundReason de 7 (que corresponde a CHARGEBACK) y tu obfuscatedAccountId, si configuraste uno al momento de la compra.
Tienes alrededor de 24 horas para llamar a ReviewRefund con una preferencia y las pruebas que puedas reunir.
Google lo usa para argumentar el caso ante el banco.
Si pierdes, y el pedido se realizó después del 3 de agosto de 2026, el costo corre por tu cuenta.
Hay una asimetría que vale la pena tener presente. Apple pregunta por los reembolsos comunes a través de CONSUMPTION_REQUEST. Google Play solo abre revisiones para contracargos. Todo lo demás se resuelve sin ti, y te enteras a través de una compra anulada. Los detalles completos aquí: contracargos de Google Play explicados.
Opción 1: Construir el manejador tú mismo
Un topic de Pub/Sub. RTDN activado desde Monetize y luego Monetization setup. Un endpoint push que verifica el mensaje antes de confiar en él. Después, decodificar el campo data en base64, derivar según cuál de los cinco objetos de notificación llegó, hacer coincidir el pedido con un usuario, reunir pruebas y llamar a ReviewRefund con un token de OAuth con alcance limitado.
Construirlo no es la parte costosa. Dos semanas, si ya tienes experiencia con la fontanería de webhooks.
El segundo año es la parte costosa. Google cambia un campo. Un refresh token de OAuth expira silenciosamente un domingo. Tu manejador se cae la misma noche en que llega una disputa de $200, que de alguna manera siempre pasa así. Vas a necesitar observabilidad, manejo de reproducción (replay) y pruebas para formatos de notificación que todavía no has visto.
Si administras un backend y los reembolsos representan una línea real de ingresos, constrúyelo. Preferiría que lo hicieras. Si eres una sola persona sacando adelante un producto, es un mal uso de tu mes.
Opción 2: Usar la plataforma de suscripciones que ya pagas
Revisa esto antes de escribir una sola línea de código. RevenueCat agregó la Review Refund API de Google dentro de Refund Control, y Adapty tiene Refund Saver del lado de Apple.
El atractivo: tus recibos, entitlements y el mapeo de clientes ya están ahí, así que las pruebas están más a la mano y la coincidencia de cuentas ya está resuelta.
El límite: la respuesta a reembolsos es una función para ellos, no el producto en sí. Espera una preferencia y un par de indicadores (flags), no 1,000 eventos de uso con direcciones IP. Para muchas apps, eso es suficiente. Para disputas con mucho fraude de por medio, no lo es.
Opción 3: Software dedicado de gestión de contracargos de Google Play
Esta categoría casi no existía antes del 3 de agosto, lo que te dice qué tan reciente es el incentivo.
La forma es consistente. El servicio se suscribe a tu RTDN, presenta una recomendación de rechazo con pruebas de entrega e interacción dentro del plazo, y da seguimiento al resultado de cada caso.
Refund Sensor hace eso tanto para Google Play como para el App Store desde una sola cuenta. Inicia sesión con Google, otorga dos permisos de Play Console (ver datos financieros, administrar pedidos y suscripciones) y la herramienta misma aprovisiona el topic de Pub/Sub. Sin SDK, sin cambios de código, sin nada que volver a enviar.
La contrapartida: otro proveedor, otra línea mensual de gasto. Lo que obtienes a cambio es no ser la persona que tiene que estar despierta.
Opción 4: Asumir la pérdida
Es una opción legítima para algunas apps, y no voy a fingir lo contrario. Si vendes un consumible de $1.99 y ves cuatro contracargos al año, dos semanas de trabajo de ingeniería nunca se pagan solas.
Aun así, primero haz el cálculo. Un contracargo perdido en un plan anual de $99 cuesta el importe del pedido menos la comisión de servicio de Google, más una comisión de la red de entre $15 y $25. Dos casos de esos en un trimestre cambian la respuesta.
Cómo automatizar la gestión de contracargos de Google Play
Si optaste por la opción uno, aquí está el orden de construcción. La secuencia importa más de lo que la gente espera.
Activa RTDN en Play Console y crea el topic de Pub/Sub. Usa Send Test Message antes de confiar en el canal.
Decodifica el campo data y deriva según qué objeto de notificación llegó. Solo llega uno por mensaje. Cuando llegue un pendingRefundReviewNotification, guarda el pendingRefundToken e inicia un temporizador. No un correo. Un temporizador.
Haz coincidir el orderId con un usuario. obfuscatedAccountId es el camino rápido, lo cual ya es razón suficiente para empezar a configurarlo en el momento de la compra.
Reúne las pruebas: sampleContentProvided, consumptionPercentageMilliunits (45200 equivale a 45.2 por ciento), y hasta 1,000 consumptionUsageEvents con marcas de tiempo y direcciones IP.
Llama a orders.reviewrefund una sola vez, con un refundPreference de APPROVE, DECLINE o NEUTRAL. Registra la llamada, el payload y la respuesta.
Por separado, gestiona voidedPurchaseNotification para quitar el acceso, y ejecuta la Voided Purchases API cada noche para reconciliar. Tiene un límite de 6,000 llamadas al día.
Ese último paso es el que todos se saltan. Yo me lo salté durante meses. Las notificaciones se pierden durante las caídas del servicio, y la pull API es la forma de descubrir qué llegó mientras estabas fuera de servicio. Voided Purchases API frente a las notificaciones de desarrollador en tiempo real explica qué hace cada canal.
Prevención de contracargos de Google Play
Más económico que todo lo anterior, y funciona en disputas que nunca ves venir.
Un cliente que llega a tu soporte no llega a su banco. Una vía de contacto visible dentro de la app, junto con una respuesta en menos de un día, elimina una proporción sorprendente de disputas antes de que empiecen.
Después, haz que la renovación sea evidente: precio, periodo y fecha de renovación en la misma pantalla que el botón de compra. La sorpresa genera más disputas que cualquier otra cosa que haya visto.
Dos cosas más que no reciben suficiente atención. Vigila las compras no reconocidas, porque las pruebas gratuitas que se convierten sin que nadie se dé cuenta se transforman en contracargos un mes después. Y usa voidedReason como señal de fraude. Tiene nueve valores posibles, incluyendo fraud, friendly_fraud y chargeback, y esas cuentas reinciden. Márcalas antes de darles otra prueba gratuita.
Mantén tu tasa por debajo del umbral de Google. Los problemas persistentes afectan la reputación de la cuenta, lo cual es peor que cualquier reembolso individual.
Fuentes
Preguntas frecuentes
Un reembolso se tramita a través de Google, y lo decide Google o tú mismo desde Play Console. Un contracargo ocurre cuando el cliente acude a su banco, lo que lo somete a las reglas de la red de tarjetas. Solo el contracargo abre una revisión que puedes responder, y solo su costo se te traslada a ti.
Alrededor de 24 horas desde el PendingRefundReviewNotification. El reloj empieza a correr desde la entrega, no desde que te das cuenta.
Google argumenta el contracargo sin tus pruebas, que es la posición más débil posible. En los pedidos realizados después del 3 de agosto de 2026, perder el caso te cuesta el importe del pedido menos la comisión de servicio, más una comisión de la red.
No. Google registra tu primera llamada a ReviewRefund e ignora las siguientes, aunque siga devolviendo OK. Pruébalo contra una compra de prueba antes de acercarlo a producción.
El que presente la respuesta sin que tú tengas que estar despierto. Si administras un backend, construirlo es un proyecto razonable. Si no, un software de gestión de reembolsos de Google Play que se conecte mediante permisos de Play Console es mejor opción que escribir un consumidor de Pub/Sub para un caso excepcional.
No. Estás haciendo una recomendación a través de la propia Play Developer API de Google, respaldada por pruebas de entrega y consumo. Ese es el canal que Google diseñó para esto.
