Contracargos de Google Play explicados: lo que todo desarrollador debe saber
Un cliente compra tu nivel premium. Semanas después, el dinero simplemente desaparece de tu pago. Sin correo. Sin ticket de soporte. Solo un saldo más bajo y una línea que no tenías prevista. Eso es un contracargo de Google Play, y a partir del 3 de agosto de 2026, el costo de perder uno recae sobre ti.
Durante años, Google absorbió la mayoría de estas pérdidas. Eso se acabó. Un contracargo perdido ahora saca dinero directamente de tus ingresos. Si desarrollas para Android y vendes algo a través de Play Billing, este es dinero que puedes perder mientras duermes. La buena noticia es que también tienes una nueva forma de defenderte, y la mayoría de los equipos todavía no la ha configurado. Nuestra guía de contracargos de Google Play cubre la configuración, pero este artículo explica primero la mecánica.
Esto no es una explicación para consumidores. Esto es lo que el proceso de contracargo de Google Play realmente le hace a tus cuentas y a tu backend, y qué puedes hacer al respecto.
Puntos clave
• Un contracargo de Google Play es una reversión forzada del pago iniciada por el banco del cliente, no por Google ni por tu equipo de soporte.
• Desde el 3 de agosto de 2026, un contracargo perdido te cuesta el precio de compra menos la tarifa de servicio de Google, más la comisión por contracargo del banco.
• Google envía una PendingRefundReviewNotification a través de Real-time Developer Notifications cuando una disputa necesita tu respuesta.
• Tienes 24 horas desde esa notificación para responder a través de la ReviewRefund API.
• Solo cuenta tu primera respuesta a la API. Las llamadas posteriores se ignoran, aunque la API siga devolviendo OK.
• Las comisiones bancarias por contracargo son fijas, así que en productos baratos la comisión sola puede costar más que la venta.
• Establecer un ID de cuenta ofuscado al momento de la compra es lo que te permite vincular una disputa con un usuario real.
• Quedarte en silencio significa que absorbes la pérdida completa sin ningún argumento registrado.
¿Qué es un contracargo de Google Play?
Un contracargo de Google Play ocurre cuando el banco de un cliente revierte un pago que ya hizo por tu app o por una compra dentro de la app.
El cliente no te pregunta a ti. Tampoco le pregunta a Google. Llama a su banco o emisor de tarjeta y disputa el cargo. El banco retira el dinero y abre una investigación. Esto es distinto de un reembolso normal porque empieza fuera de la tienda, dentro del sistema bancario, donde no tienes acceso directo.
Ejemplo. Alguien compra una suscripción anual de $40. A las dos semanas, le dice a su banco que nunca la autorizó. El banco recupera los $40 y marca el cargo como disputado. Puede que ya hayas entregado un mes de funciones premium. Al contracargo no le importa lo que entregaste.
En Play, Google es el comerciante registrado (merchant of record), así que el golpe directo para ti es financiero y no un problema de reputación con el procesador. Aun así, es dinero real que sale de tu cuenta.
Por qué los contracargos son distintos de los reembolsos
Un reembolso es una solicitud que se gestiona dentro de Google Play. Una disputa de contracargo de Google Play la gestiona un banco.
Un reembolso sigue las reglas de Google y tu configuración. Un contracargo sigue las reglas de las redes de tarjetas y los plazos del banco. Tienes mucho menos control, y las cuentas son peores, porque el banco añade su propia comisión fija encima de la venta revertida. Un reembolso estándar también puede pasar por tu servidor sin dejar rastro, y un contracargo es aún más silencioso hasta que el dinero ya se fue.
Reembolso de Google Play | Contracargo de Google Play |
Iniciado dentro de Google Play por el usuario o por tus reglas | Iniciado en el banco por el cliente |
Sigue la política de Google Play y tu configuración | Sigue las reglas de las redes de tarjetas y del banco |
Devuelve el monto de la venta al comprador | Devuelve el monto de la venta más una comisión bancaria fija |
A menudo puedes prevenirlo o moldearlo | Solo puedes impugnarlo con evidencia |
Sin comisión bancaria adicional | Comisión bancaria por contracargo sumada a tu pérdida |
Ejemplo. Un reembolso de una compra de $10 devuelve $10 al comprador. Un contracargo sobre esa misma compra de $10 puede devolver los $10 y añadir una comisión bancaria fija. En una venta pequeña, una sola disputa puede dejarte más abajo de lo que la venta llegó a ganar.
Cómo funciona el proceso de contracargo de Google Play
El proceso de contracargo de Google Play empieza cuando un banco disputa un cargo; luego Google lo revisa y, en los casos que necesitan tu respuesta, te pide evidencia dentro de una ventana fija.
Este es el flujo, paso a paso:
1. El cliente disputa el cargo con su banco.
2. El banco envía la disputa a Google, el comerciante registrado.
3. Google revisa las señales que ya tiene sobre la compra.
4. Para las disputas que requieren revisión del desarrollador, Google envía una PendingRefundReviewNotification a través de Real-time Developer Notifications.
5. Tienes 24 horas para responder a través de la ReviewRefund API con tu preferencia y cualquier evidencia de uso.
6. Google defiende el caso ante el banco con lo que enviaste.
Ejemplo. Una notificación llega a tu tema de Pub/Sub a las 2 a. m. Nadie está vigilando la cola. A las 2 a. m. del día siguiente, la ventana ya se cerró. Si tu sistema nunca respondió, Google defiende el caso con solo la versión del cliente registrada. Puedes leer cómo lo plantea Google en su documentación oficial sobre contracargos.
¿Qué pasa después de una notificación de contracargo?
Cuando llega la notificación, empieza a correr un reloj de 24 horas, y solo se registra tu primera respuesta a través de la ReviewRefund API.
Tu respuesta puede incluir estos campos:
• pendingRefundToken: el token de la notificación. Es obligatorio, y lo devuelves tal cual para que Google pueda vincular tu respuesta con la disputa.
• sampleContentProvided: un indicador true o false que señala si ofreciste una muestra gratuita, una prueba o información clara de la funcionalidad antes de la compra.
• refundPreference: tu preferencia: APPROVE, DECLINE o NEUTRAL, según tu propia lógica.
• consumptionPercentageMilliunits: cuánto usó el cliente, en miliunidades, donde 45200 significa 45.2 por ciento.
• consumptionUsageEvents: hasta 1,000 eventos, cada uno con una marca de tiempo, una dirección IP, una ubicación aproximada y una descripción de hasta 5,000 caracteres.
Una regla que hace tropezar a los equipos. Solo se guarda tu primera llamada. Las llamadas posteriores devuelven OK pero no cambian nada. Así que una primera respuesta parcial se vuelve permanente.
Ejemplo. Tu servidor dispara una respuesta rápida sin los eventos de uso, con la idea de enviarlos en una segunda llamada. Esa segunda llamada se descarta en silencio. La respuesta incompleta es ahora la única respuesta que tiene Google. La lista completa de campos está en la referencia de la ReviewRefund API.
Cómo deben responder los desarrolladores
Responde automáticamente, dentro de la ventana, con una preferencia clara y evidencia de uso real vinculada al pedido en disputa.
Una respuesta sólida suele hacer cuatro cosas:
• Vincula la disputa con un usuario real mediante el ID de cuenta ofuscado establecido en la compra.
• Define una preferencia a partir de tu propia lógica, como un patrón de fraude o el nivel de consumo.
• Adjunta eventos de uso con marcas de tiempo, direcciones IP y ubicación aproximada.
• Indica si había disponible una muestra, una prueba o una vista previa de la funcionalidad antes de la compra.
Ejemplo. A un banco le cuesta calificar como no autorizado a un usuario con 60 sesiones registradas, una IP que coincide con su país de registro y un porcentaje de consumo claro. Esa evidencia es exactamente lo que Google reenvía en tu nombre. Una cuenta sin nada de eso no le da a Google nada con qué argumentar.
Errores comunes de los desarrolladores
Los errores más grandes son no escuchar la notificación, dejar pasar la ventana de 24 horas y no tener forma de vincular una disputa con un usuario.
El patrón se repite entre equipos:
• No suscribirse a Real-time Developer Notifications para todos los tipos de notificación.
• Tratar la ventana como horario de oficina en lugar de un reloj estricto de 24 horas.
• Nunca establecer un ID de cuenta ofuscado, por lo que las disputas no se pueden vincular con un usuario.
• Enviar una primera respuesta incompleta y asumir que una segunda la corregirá.
• Omitir la API porque técnicamente es opcional, mientras sigues asumiendo cada pérdida.
Ejemplo. Un equipo asume que una persona puede gestionar las disputas en horario laboral. Una notificación llega el viernes por la noche. Para el lunes, la ventana ya se cerró en tres casos distintos, y cada uno es ahora una pérdida silenciosa.
Acción del desarrollador | Acción de Google |
Establecer el ID de cuenta ofuscado en la compra | Lo usa para vincular la disputa con el pedido correcto |
Suscribirse a RTDN para todos los tipos | Envía PendingRefundReviewNotification para los casos en revisión |
Responder en 24 horas vía ReviewRefund | Registra solo la primera respuesta recibida |
Adjuntar evidencia de uso y preferencia | Defiende el caso ante el banco en tu nombre |
No hacer nada | Decide solo con la versión del cliente, y la pérdida se te cobra a ti |
Impacto de los contracargos en los ingresos
Cada contracargo de desarrollador de Google Play perdido te cuesta el precio de venta menos la tarifa de servicio de Google, más una comisión bancaria fija, así que las compras pequeñas pueden terminar en negativo.
Dos casos rápidos muestran el rango. Una suscripción de $40 que pierde una disputa te cuesta tus ingresos netos de esa venta más la comisión bancaria. Un paquete de monedas de $2 es peor: una comisión bancaria fija puede superar con creces la venta, así que una sola disputa borra el margen de muchas compras limpias.
La pérdida además se acumula. Ya gastaste cómputo, almacenamiento y a veces soporte para atender esa compra. Que te retiren los ingresos no te devuelve esos costos. Y quienes disputan de forma repetida te cobran más de una vez, por eso importa tanto vincular las disputas con la identidad de un usuario.
Buenas prácticas para prevenir contracargos
No puedes impedir que un cliente llame a su banco, así que la prevención de contracargos significa dos cosas: reducir las disputas que puedas y siempre impugnar las que recibas.
Una lista práctica:
• Establece un ID de cuenta ofuscado en absolutamente todas las compras.
• Suscríbete a Real-time Developer Notifications para todos los tipos de notificación.
• Registra el uso con marcas de tiempo, direcciones IP y ubicación aproximada desde el primer día.
• Deja claros los términos de facturación y los detalles de la prueba antes de la compra, lo que reduce los reclamos del tipo “no lo autoricé”.
• Automatiza la respuesta de ReviewRefund para que nada dependa de que alguien esté despierto.
Hay un paso más que los equipos olvidan. Ganes o pierdas la disputa, revocar el acceso después de una reversión es tu responsabilidad, no de Google. El movimiento del dinero y el fin del acceso son eventos separados.
Ejemplo. Una app que registra sesiones y establece IDs de cuenta desde el inicio puede responder cualquier disputa en segundos. Una app que no registró nada no tiene nada que enviar, y la ventana se cierra igual en ambos casos.
Cerrar la brecha
La brecha que arrastran la mayoría de los equipos es el espacio entre el momento en que Google pide evidencia y el momento en que una persona se da cuenta.
Las reglas son públicas. La ventana está fija en 24 horas. La única variable real es si tu sistema responde a tiempo con datos reales. La gestión manual pierde esa carrera casi siempre, porque las disputas no esperan al horario de oficina.
Los contracargos solían ser problema de Google. Ahora son tuyos, pero también lo son la evidencia y la API para usarla. Los equipos que configuran esto conservan los ingresos que los equipos silenciosos devuelven sin darse cuenta.
Dónde están documentadas estas políticas
Estas son las fuentes primarias detrás de todo lo anterior. Sin blogs de terceros, solo documentación oficial de Google.
• Google Play Billing: ayuda a Google a disputar contracargos
• Google Play Developer API: referencia de orders.reviewrefund
• Ayuda de Google Play Console: responsabilidad por los costos de reembolsos y contracargos
Referencias
Preguntas frecuentes
Un contracargo es una reversión de pago iniciada por el banco del cliente, no por Google.
Un reembolso lo gestiona Google Play; un contracargo lo gestiona el banco del cliente.
Tienes 24 horas desde que recibes la notificación.
Google continúa sin tu respuesta, y aun así se te puede cobrar si la disputa se pierde.
Sí. Responde a través de la ReviewRefund API con tu decisión y la evidencia que la respalde.
El monto de la venta (menos la tarifa de servicio de Google) más la comisión por contracargo del banco.
Sí. Los pagos de suscripciones también pueden disputarse mediante contracargos.
No puedes prevenir todos los contracargos, pero un buen registro de uso, una facturación clara y respuestas rápidas pueden reducirlos.
