La mayoría de los contracargos en apps se pueden evitar antes de que intervenga el banco, y detener uno ahora ahorra más que la propia venta

Un contracargo no es un reembolso, y tratar ambos por igual es la forma en que los estudios de apps pierden dinero que nunca tuvieron por qué perder. Un reembolso pasa por la tienda: el cliente se lo pide a Apple o a Google, el dinero vuelve, y ahí acaba todo. Un contracargo se salta la tienda y va al banco. El cliente le dice al emisor de su tarjeta que el cargo era erróneo, el emisor retira el dinero, y a menudo lo acompaña una comisión aparte. En los pedidos de Google Play realizados después del August 3, 2026, esa comisión y la venta perdida recaen sobre el desarrollador, no sobre Google. Ese único cambio es la razón por la que ahora merece la pena evitar los contracargos en apps, y por la que la mayoría se pueden detener mucho antes de que un banco llegue a intervenir.

Esta es la parte que te ayuda. Una gran parte de los contracargos en apps no son fraude sofisticado. Empiezan con un cliente que no sabe a qué corresponde un cargo, o con una compra que nunca debió haberse aprobado. Sobre ambas cosas puedes actuar. El resto es un manual de actuación: lo que de verdad cuesta una disputa perdida, las disputas que puedes evitar, el fraude que puedes bloquear en el origen, y las dos ventanas breves que son tu única voz cuando un banco ya está decidiendo.

Por qué un contracargo cuesta más que un reembolso

Tanto un reembolso como un contracargo terminan con el dinero del cliente devuelto, así que los estudios los meten en el mismo cajón mental. Los costes no son iguales. Un reembolso devuelve el importe de la venta y nada más. Un contracargo devuelve el importe de la venta y añade la comisión de disputa del banco, y esa comisión es fija mientras que tus precios no lo son.

La App Store y Google Play reparten la factura de formas distintas

En la App Store, un contracargo de tarjeta se resuelve entre el banco y Apple, y Apple asume la mecánica. En Google Play, las reglas cambiaron. En los pedidos realizados después del August 3, 2026, Google cubre solo la comisión de servicio que ya cobró, y el desarrollador absorbe el precio de compra menos esa comisión de servicio, más la comisión de contracargo que cobre el banco. Google describe el cambio como una forma de alinear Play con el resto del sector de pagos.

Los costes que ya gastaste no vuelven

El importe reembolsado o disputado es solo la pérdida visible. Ya pagaste por atender esa compra. El cómputo que ejecutó la generación, las llamadas a APIs de terceros que se te facturaron, el almacenamiento que aprovisionaste y cualquier pago que enviaste a un creador no se revierten cuando lo hace el cargo. En un consumible de bajo precio, la comisión fija de contracargo de un banco por sí sola puede superar lo que pagó el cliente, y el coste de servicio ya gastado se suma encima. Por eso un contracargo evitado vale más que su precio de etiqueta.

Cómo evitar los contracargos antes de que intervenga el banco

No puedes detener todas las disputas, pero sí puedes eliminar las dos razones más comunes por las que se presenta una: el cliente no reconoció el cargo, y la compra fue fraudulenta desde el principio. Encárgate de esas y el volumen baja.

La confusión genera más disputas que el fraude

Cuando un cliente repasa un extracto y no ubica una línea, muchos llaman al banco antes de pensar en contactarte. La etiqueta que puedes controlar es escasa. Apple imprime apple.com/bill en cada compra y no te da ningún ajuste para cambiarlo, así que el nombre de tu app nunca aparece. Google Play antepone GOOGLE y luego muestra el nombre de extracto que configuraste en Play Console, que es el único campo de descriptor que cualquiera de las dos tiendas te ofrece. Ponle un nombre que tus clientes reconozcan.

Haz que el cargo sea reconocible en todo lo demás

Como no puedes arreglar el descriptor de Apple, arregla todo lo que lo rodea. Un cargo sorpresa es una disputa clásica, así que elimina la sorpresa antes de que llegue a un extracto.

• Un recibo con tu marca en la app y por correo electrónico que nombre el producto y el importe, enviado en cuanto se aprueba la compra.
• Un recordatorio de renovación antes del cargo en las suscripciones anuales y de precio alto, para que la renovación nunca sea un susto.
• Gestión de la suscripción dentro de la app y una forma de pedir un reembolso con un solo toque, para que el cliente acuda a ti primero.
• Una respuesta de soporte dentro de la ventana de disputa, ya que una respuesta rápida a menudo evita que un cliente escale al banco.

Cada una de estas convierte un posible contracargo en una conversación de soporte o en un reembolso corriente, y un reembolso no lleva comisión bancaria.

Detén la compra fraudulenta en el origen

Las disputas de las que no puedes salir hablando son aquellas en las que la compra fue fraudulenta desde el principio. Esas las bloqueas antes de que se aprueben, en tu servidor, con herramientas que ambas tiendas documentan.

Verifica cada compra en tu propio servidor

Nunca concedas un permiso por la palabra del cliente. Envía el token de compra a tu backend, confírmalo contra la tienda y guárdalo. Google Play hace que el purchaseToken sea único a nivel global, así que puedes usarlo como clave primaria y rechazar cualquier token que ya hayas visto, lo que acaba con la reutilización y el uso compartido de recibos. Verifica con la Play Developer API antes de desbloquear nada, y en la App Store valida la transacción firmada de la misma manera.

Nunca entregues una compra que sigue pendiente

Una compra pendiente no es dinero en mano. Google Play te dice que concedas un permiso solo cuando el estado de la compra es PURCHASED, nunca mientras sea PENDING, porque un cargo pendiente todavía puede fallar. Si entregas antes de tiempo, has regalado el producto sobre un pago que quizá nunca llegue, lo que es una pérdida que creaste tú, no una disputa que puedas pelear.

Asocia cada compra al comprador

Ambas tiendas te permiten adjuntar un identificador de cuenta a una compra, lo que las ayuda a detectar patrones sospechosos y te ayuda a asociar una disputa a un usuario. En Google Play, fija el id de cuenta y de perfil ofuscados en el flujo de facturación con setObfuscatedAccountId y setObfuscatedProfileId. En la App Store, fija un appAccountToken, que debe ser un UUID. Dale buenas señales a la tienda y bloqueará parte del fraude antes de que se complete la transacción.

Recupera y corta el acceso a los abusadores reincidentes

Cuando una compra se anula, se revoca o sufre un contracargo, la Voided Purchases API de Google Play te lo comunica, así que puedes recuperar el artículo no usado o dejar un saldo en negativo. Advierte a quien lo hace por primera vez, y luego desactiva las compras o el acceso de una cuenta que lo repita. Un reembolsador en serie que conserva su acceso es una invitación a la siguiente disputa.

Cuando una disputa ya está presentada, responde en la ventana

Una vez que un contracargo está en marcha, no puedes revertirlo por tu cuenta. Lo que sí puedes hacer es entregar pruebas a la tienda, dentro de una ventana breve, y dejar que la tienda pelee contra el banco con ellas.

Apple te da 12 horas

Cuando un cliente solicita un reembolso de un consumible o de una suscripción de renovación automática, Apple envía a tu servidor un CONSUMPTION_REQUEST y espera hasta 12 horas los datos de consumo: si entregaste, cuánto se usó y si preferirías que el reembolso se conceda o se rechace. Apple sigue decidiendo, pero tu respuesta es una aportación documentada a esa decisión.

Google Play te da 24 horas

Para una compra de Play disputada que necesita revisión, llega una PendingRefundReviewNotification a través de Real-time Developer Notifications y arranca un reloj de 24 horas. Responde mediante la API orders.reviewrefund con tu preferencia y tus pruebas, y Google la usa para impugnar contracargos ilegítimos ante el banco en tu nombre. Deja que la ventana se cierre en silencio y la disputa avanza sin ti.

Por qué no puedes presentar tú mismo las pruebas ante el banco

Los equipos de pagos hablan de Compelling Evidence 3.0 de Visa, una regla que permite a un comerciante ganar una disputa de fraude amistoso mostrando dos transacciones previas sin disputar con las mismas credenciales, cada una de entre 120 y 365 días de antigüedad, con datos coincidentes como la dirección IP o el id del dispositivo. En tus ventas dentro de la app, tú no eres el comerciante de registro. Lo son Apple y Google. Así que es la tienda, y no tú, quien reúne ese tipo de pruebas, y la única manera de que tus datos lleguen a la pelea es a través de la ventana de revisión anterior. Esa es la razón práctica por la que los relojes de 12 horas y 24 horas importan tanto. Son todo tu asiento en la mesa.

La lista de comprobación previa a la disputa

Nada de esto es exótico. Es una lista corta que puedes poner en marcha antes de tu próximo ciclo de facturación.

• Configura un nombre de extracto reconocible en Google Play, y envía recibos con tu marca en todo lo demás.
• Envía recordatorios de renovación antes de los cargos anuales y de precio alto.
• Pon la gestión de la suscripción y las solicitudes de reembolso a un toque dentro de la app.
• Verifica cada compra en tu servidor y guarda el token como clave única.
• Concede permisos solo con un estado PURCHASED, nunca con PENDING.
• Adjunta un id de cuenta o un appAccountToken UUID a cada compra.
• Aprovisiona los feeds de notificaciones de Apple y de Google y responde a cada solicitud de consumo y a cada revisión de reembolso dentro de la ventana.