Quién paga un reembolso en tu app eres casi siempre tú, pero no por la comisión que crees estar perdiendo

Hay una creencia que no muere en los foros de desarrolladores: te quedas con el 70 por ciento de una venta, pero un reembolso te obliga a devolver el 100 por ciento, así que cada reembolso te cuesta en silencio la parte de la tienda. Es falso. Cuando Apple o Google reembolsa a uno de tus clientes, la tienda también devuelve su comisión, y tus libros revierten solo la parte que de verdad te quedaste. Así que la respuesta honesta a quién paga un reembolso en tu app eres tú, pero por una factura distinta de la que casi todos nombran. Pierdes la venta y todo lo que ya gastaste para entregarla, no un 30 por ciento extra para la tienda. Aquí tienes a dónde va de verdad el dinero, línea por línea, y por qué un tipo de reversión, el contracargo, rompe la regla.

Quién paga un reembolso, desglosado por tienda

Empecemos por la reversión en sí, antes de hablar de costes de entrega. Un reembolso en la App Store y un reembolso en Google Play deshacen la venta de la misma forma a nivel contable: la tienda deja de cobrarte su comisión y tú devuelves tus ingresos netos. El cliente recupera su precio completo en cualquier caso. Aquí tienes el desglose, por tienda.

¿Apple se queda con su comisión cuando se reembolsa a un cliente?

Esta es la pregunta que más hacen los desarrolladores, en los Apple Developer Forums y en Hacker News: si Apple reembolsa a un comprador, ¿se queda con la parte que se llevó en la venta? Lee el informe financiero y la respuesta es no. Un reembolso aparece como una fila con Sale or Return en R y una Quantity negativa, y el dinero revertido es el Extended Partner Share, Quantity por Partner Share, donde Partner Share es el precio al cliente menos impuestos y la comisión de Apple. Apple recupera lo que te pagó, tus ingresos netos, no el precio bruto. Los desarrolladores que sacaron sus propios informes detallados encontraron lo mismo: Apple descontó el importe posterior a la comisión, no la venta completa.

Hay una trampa en la letra pequeña. El Paid Applications Agreement de Apple dice que Apple tiene derecho a retener su comisión en una venta a pesar de un reembolso al usuario final. Así que la devolución es como cuadran los informes en la práctica, no una promesa. Apple conserva la opción contractual de retener su parte, y la lectura habitual es que lo hace cuando decide que un desarrollador está haciendo algo mal.

Qué devuelve Google, y qué se queda después un contracargo

Google es más explícito por escrito. Su ayuda de gestión de pedidos dice que cuando reembolsas un pedido, Google te devuelve la tarifa de servicio y la ves en tu próximo informe de ingresos. El momento está ligado a tu pago. Reembolsa un pedido antes de que Google te lo haya pagado y sencillamente nunca recibirás ese importe en tu próximo pago. Reembólsalo después de que te hayan pagado y el importe se descuenta de un pago futuro. Los reembolsos parciales escalan: reembolsa la mitad de un pedido y la mitad tanto de tu pago como de la tarifa de servicio vuelve al comprador.

Ese es el caso limpio. Un contracargo no es limpio, y es el único punto donde la tienda deja de devolver su parte como lo hace un reembolso normal.

Qué sale de verdad de tu cuenta

Entonces, si la comisión vuelve, ¿por qué sigue doliendo un reembolso? Porque el precio de venta nunca fue todo el coste de ese cliente. Sigue el dinero en dos partes.

La primera parte es la venta en sí. En un reembolso queda cerca de cero. El cliente recupera su dinero, la tienda devuelve su comisión y tú reviertes tus ingresos. Pierdes el beneficio que habías contabilizado, lo que importa a escala, pero no pagas una penalización a la plataforma.

La segunda parte es la que los informes nunca muestran. Es todo lo que ya gastaste para convertir ese pago en un producto entregado, y nada de ello se revierte cuando el pago lo hace.

• Cómputo que ya ejecutaste: los segundos de GPU detrás de una imagen, un vídeo o una respuesta del modelo que el cliente ya recibió.
• Llamadas a la API que ya pagaste: cada petición a terceros, desde una consulta de mapas hasta un token de LLM, facturada en el momento en que se disparó.
• Almacenamiento que sigues pagando: los archivos, las exportaciones y el historial que el cliente creó y que tú sigues alojando.
• Pagos que ya enviaste: la parte del creador, el conductor o el vendedor que desembolsaste por una venta que acaba de revertirse.

Suma todo eso y un cliente reembolsado puede costar más después del reembolso que un cliente que nunca compró. La venta se compensa. El gasto que hay detrás no.

Cómo se mueve un reembolso a través de tu pago

Los reembolsos no se te facturan por separado. Viajan a través de la misma liquidación mensual que tus ventas, por eso un mes con muchos reembolsos puede reducir un pago con el que ya contabas.

En la App Store

Apple genera un informe financiero por cada mes fiscal, y los reembolsos se contabilizan en el mes en que se liquidan, como líneas de Return negativas. El informe de un mes fiscal está disponible el primer viernes del siguiente. Un reembolso emitido este mes reduce los ingresos de este mes. No hay una factura aparte, solo un número más pequeño.

En Google Play

Google pone cada movimiento en tu informe de ingresos como su propia línea, una para un cargo, una para una tarifa, una para un reembolso. Si el reembolso llega antes de tu pago por ese pedido, los ingresos del pedido nunca llegan. Si llega después, el reembolso se resta de un pago posterior. En cualquier caso sale de los ingresos, no de una factura que pagues.

La única línea de tu informe que es el reembolso

En Apple, filtra por Sale or Return igual a R. Cada una de esas filas es dinero que sale. En Google, busca el tipo de transacción de reembolso en el informe de ingresos y la línea correspondiente de tarifa de servicio devuelta. Conciliar eso con tus propios eventos de reembolso es como detectas a un cliente que fue reembolsado pero nunca perdió el acceso, que es el fallo que convierte un reembolso barato en uno caro.

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

Pon los dos uno al lado del otro y la diferencia es el banco. En un reembolso normal de Google Play, la tarifa de servicio vuelve y solo pierdes tu parte de una venta que se revirtió. En un contracargo bajo la política del 3 de agosto de 2026, pierdes el precio de compra menos la tarifa de servicio, y encima la comisión de contracargo de la institución financiera. La misma venta perdida, más una comisión que existe solo porque un banco, no una tienda, gestionó la reversión.

El lado de Apple tiene su propia arista. Un contracargo, o un reembolso que Apple concede tras un CONSUMPTION_REQUEST que respondiste tarde, revierte igualmente tus ingresos, y Apple conserva el derecho contractual de retener su comisión si decide que el patrón parece un abuso. Las cuentas del reembolso normal, donde la tienda devuelve su parte, se sostienen solo mientras nada en la transacción parezca sospechoso.

Lo que sí puedes controlar

No puedes decidir si ocurre un reembolso. Ambas tiendas se reservan eso. Puedes decidir cuánto cuesta cada uno después de que se dispare.

• Corta el acceso en el momento en que llega la reversión. Un cliente reembolsado o con contracargo que sigue generando resultados, llamando a tus API y llenando tu almacenamiento convierte una reversión que quedaba a cero en una factura que crece.
• Responde a tiempo a las dos ventanas de evidencia. El CONSUMPTION_REQUEST de Apple te da 12 horas para enviar los datos de consumo. El orders.reviewrefund de Google te da 24 horas para impugnar un contracargo. Esos son los únicos momentos en que tu versión de la historia cuenta.
• Concilia los reembolsos con tus propios registros cada mes, para que una reversión que no revocó el acceso aparezca como una línea sobre la que puedes actuar, no como una fuga lenta.

Nada de eso cambia quién paga un reembolso. Cambia cuánto es la factura para cuando terminas de pagarla.