La diferencia entre un contracargo y un reembolso se reduce a quién decide, y solo uno de ellos es definitivo

Dos palabras se usan como si significaran lo mismo. El cliente recupera su dinero de cualquier forma, así que a quién le importa cuál fue. Para un desarrollador de apps que vende a través de la App Store o Google Play, la diferencia entre un contracargo y un reembolso decide quién controló el resultado, si podrías haberlo cambiado y, a partir de este mes, cuánto se lleva la reversión de tu cuenta.

Esta es la versión corta. Un reembolso es la tienda devolviendo el dinero, y la tienda lo decide. Un contracargo es el banco del cliente retirando el dinero, y el banco lo decide, sin apelación. Ocupas lugares muy distintos en cada uno. Esto es lo que parece cada uno en Apple y Google, los dos momentos en los que la tienda realmente te pide algo, y lo que cuesta ahora la diferencia entre ambos.

La diferencia entre un contracargo y un reembolso es quién decide

Quita la jerga de los pagos y una sola pregunta separa a ambos: quién toma la decisión final. Un reembolso es una decisión tomada dentro del propio sistema de la tienda. Un contracargo es una decisión tomada en el banco del cliente, una capa más allá de donde puede llegar cualquier ajuste de la tienda. Ese único hecho determina todo lo demás, desde si puedes impugnarlo hasta lo que cuesta.

Quién lo inicia y quién decide

Un reembolso puede empezar de dos formas. El cliente pide su dinero a la tienda, o tú mismo emites el reembolso. En cualquier caso la tienda, Apple o Google Play, lo aprueba y devuelve los fondos. Un contracargo empieza de una sola forma. El cliente se salta la tienda por completo y disputa el cargo con su banco o red de tarjetas, y el banco recupera el dinero del sistema de pagos de la tienda. La tienda no lo eligió, y tú tampoco.

La tienda es el vendedor, no tú

Esta es la parte que confunde a los desarrolladores que vienen del comercio electrónico clásico. Cuando vendes a través de la App Store o Google Play, no eres el comerciante oficial. Apple y Google lo son. El extracto de la tarjeta del cliente indica Apple o Google, no el nombre de tu empresa. Así que cuando ese cliente disputa el cargo, el contracargo aterriza primero en el sistema de pagos de la tienda. No estás al teléfono con el banco. Te enteras a través de la tienda, si es que la tienda te lo dice.

Los dos, uno al lado del otro

Cómo es un reembolso en la App Store y Google Play

La mayoría de los reembolsos no son una conversación en la que puedas participar. La tienda recibe la solicitud, la coteja con sus propias reglas y devuelve el dinero. Te lo comunican después, si has conectado las notificaciones que traen la noticia.

Apple decide y luego avisa a tu servidor

Un cliente de Apple solicita un reembolso en reportaproblem.apple.com, y Apple tiene hasta 90 días desde la compra para aceptar la solicitud a revisión. Apple revisa cada caso por su cuenta y decide. Cuando concede el reembolso, tu servidor recibe una notificación REFUND mediante App Store Server Notifications V2, y la transacción ahora lleva un revocationDate. Cuando deniega la solicitud, recibes REFUND_DECLINED. Si Apple después deshace un reembolso que ya había concedido, recibes REFUND_REVERSED y la venta vuelve. En ninguno de estos casos emites un voto. Reaccionas.

Google Play reembolsa la mayoría de las compras sin preguntarte

Google Play permite a un cliente autogestionar un reembolso dentro de las 48 horas de la compra, directamente desde su cuenta, sin ninguna participación del desarrollador. Pasadas las 48 horas, el cliente se dirige a ti, y puedes conceder o denegar según tu propia política. El soporte puede emitir reembolsos, y una compra no confirmada se reembolsa automáticamente tras unas 72 horas. Todo esto ocurre del lado de Google. Ves el resultado a través de una notificación de compra anulada o la Voided Purchases API, y tu tarea es revocar el acceso, no aprobar el reembolso.

Los dos flujos donde la tienda sí te pregunta

Hay exactamente dos momentos en ambas tiendas en los que la tienda se detiene y pide pruebas al desarrollador antes de decidir. Apple envía un CONSUMPTION_REQUEST cuando un cliente solicita un reembolso, y te da 12 horas para responder mediante Send Consumption Information con datos de uso. Google Play envía una revisión de contracargo y te da 24 horas para responder mediante la API orders.reviewrefund. Todo lo demás se decide sin ti. Estas dos ventanas son el único lugar donde tu aportación cambia el resultado, por lo que vale la pena automatizarlas y monitorizar el resto.

Cómo es un contracargo y por qué es definitivo

Un contracargo no es un reembolso con pasos adicionales. Es un mecanismo distinto con un responsable de la decisión distinto, y eso cambia lo que puedes hacer al respecto.

El banco retira el dinero, no el cliente

En un contracargo el cliente le dice a su banco que el cargo fue erróneo, fraudulento, no reconocido o nunca entregado. El banco se pone del lado de su titular por defecto y revierte la transacción, recuperando los fondos a través de la red de tarjetas. La tienda no lo aprobó. El dinero ya se ha ido antes de que alguien pregunte si el producto se entregó. Por eso un contracargo es lento y pesado donde un reembolso es rápido y limpio: pasa por el proceso de disputa de la red de tarjetas, que tarda semanas o meses, no minutos.

La decisión del banco es definitiva

No puedes anular un contracargo como podrías revertir un reembolso. Una vez que el banco resuelve, esa resolución se mantiene. El único lugar donde puedes influir es antes de que se decida. En Google Play una disputa iniciada por el banco puede abrir una revisión, y Google Play envía a tu servidor una notificación con un reloj de 24 horas. Responde mediante orders.reviewrefund con una preferencia de reembolso y pruebas de consumo reales, y Google Play incorpora tu aportación a cómo impugna el contracargo en tu nombre. Pierde la ventana y la disputa se resuelve sin la única parte que sabe cómo se usó el producto.

Cuánto te cuesta realmente cada uno

Durante mucho tiempo la respuesta honesta era que un contracargo y un reembolso le costaban a un desarrollador de apps más o menos lo mismo: la venta, y lo que ya hubieras gastado en entregarla. Eso dejó de ser cierto para los desarrolladores de Google Play este mes.

El reembolso nunca es la única cifra

Ya sea que la reversión sea un reembolso o un contracargo, el pago nunca fue tu único coste. Un vídeo generado, un lote de llamadas a la API de un modelo, un pago a un creador, el almacenamiento que aprovisionaste, todo ese dinero salió de tu cuenta en el momento en que entregaste el pedido, y nada de eso vuelve cuando se revierte el cargo. La venta es la cifra visible. El cómputo, las llamadas a la API, el almacenamiento y los pagos son las que ya se liquidaron. Defiende la reversión por el valor entregado, nunca por cuánto tiempo esperó el cliente, porque el tiempo transcurrido no es un coste y Apple y Google no lo tratan como tal.

Desde el 3 de agosto de 2026 un contracargo añade una comisión bancaria

Aquí es donde ambos dejan de costar lo mismo. Hasta ahora Google Play absorbía el coste posterior de un contracargo. Para los pedidos realizados después del 3 de agosto de 2026, Google Play traslada ese coste al desarrollador. En una disputa perdida devuelves el precio de compra menos la comisión de servicio de Play, y encima pagas la comisión de contracargo que cobra la entidad financiera. Google Play sigue cubriendo la parte de la comisión de servicio. Un reembolso no lleva esa comisión bancaria. Así que un cargo que termina en contracargo ahora te cuesta estrictamente más que el mismo cargo reembolsado, y el extra es la comisión del banco.

La escala detrás del cambio

Google Play afirma que bloqueó US$3.4B de fraude y abuso en 2025 y sigue añadiendo detección de fraude a lo largo de 2026. Trasladar el coste del contracargo a los desarrolladores forma parte de ese impulso. Te da una razón directa para alimentar con pruebas el flujo de revisión, para que el sistema impugne más de las disputas ilegítimas. Tus pruebas son lo que hace posible una impugnación, y una respuesta vacía es un voto para dejar que un contracargo de fraude amistoso se quede con tu dinero.

Cómo evitar que un reembolso se convierta en un contracargo

El contracargo más barato es el que nunca ocurre, porque el pedido se reembolsó primero o se impugnó con pruebas que ya estaban ahí. Nada de esto necesita a una persona despierta a la hora justa. Necesita la infraestructura montada antes de la disputa.

Reembolsa tú mismo un pedido malo antes de que lo haga el banco

Si un pedido va a ser claramente disputado, reembolsarlo tú mismo es más barato que perder el contracargo. Un reembolso que emites no lleva la comisión de contracargo del banco. En Google Play puedes reembolsar cualquier pedido de menos de tres años con una llamada a orders.refund, con o sin revocar el acceso. Llega antes de que el cliente contacte con su banco y conviertes una comisión bancaria más una venta perdida en solo una venta perdida.

Responde automáticamente a las dos ventanas de pruebas

La ventana de 12 horas de Apple y la ventana de 24 horas de Google Play son cómodas para una máquina y brutales para un humano que tiene que estar vigilando. La respuesta debería ser automática: entra la notificación, se busca la cuenta, se ensambla el consumo, una llamada de salida, ninguna persona en el bucle. Esa es la parte que RefundHalt ejecuta por ti. Escuchamos el CONSUMPTION_REQUEST y la revisión de contracargo de Google Play, hacemos coincidir el pedido con el uso que ya registramos, y respondemos dentro de la ventana con una preferencia de reembolso y pruebas de consumo reales.

Adjunta la identidad y registra el consumo desde el principio

Las pruebas que necesitas en el momento de la disputa tienen que existir antes de la disputa. Establece un identificador de cuenta en cada compra para que una notificación se asigne directamente a un usuario, un appAccountToken UUID en Apple y un setObfuscatedAccountId con hash de 64 caracteres o menos en Google Play, nunca datos personales en texto plano. Registra qué entregó cada pedido pagado, cuándo y a quién, en un formato que puedas convertir en un porcentaje de consumo cuando lo necesites. Haz eso y la estrecha ventana es suficiente, porque el caso ya está construido cuando llega el token.