Lee el código de motivo de reembolso que tu servidor ya recibe, y te dice si debes corregir tu app o disputar con el cliente

Cuando Apple o Google reembolsan a uno de tus clientes, el dinero suele haberse ido antes de que tengas voto. Lo que llega a tu servidor después parece un recibo, y la mayoría de los equipos lo tratan como tal. Es más que eso. Cada reembolso lleva un código de motivo de reembolso, y es la única parte de un reembolso que aún puedes leer una vez tomada la decisión. Google Play te dice que el reembolso fue un contracargo, o una solicitud por arrepentimiento, o una compra que tu propia app nunca confirmó. Apple te dice si el reembolso culpó a algo dentro de tu app. Lee ese código y un reembolso deja de ser una línea en un informe y se convierte en una instrucción: corrige esto, disputa esto o deja pasar este. Aquí tienes lo que significa cada código, cómo clasificarlos y cuánto cuesta cada uno.

Qué es realmente un código de motivo de reembolso

Un código de motivo de reembolso es la etiqueta propia de la tienda para explicar por qué se revirtió una compra. Tú no lo estableces y no puedes discutirlo. Llega adjunto al reembolso después del hecho, y las dos tiendas lo exponen en formas distintas y con una resolución muy diferente.

Google Play marca cada anulación con un motivo y una fuente

La Voided Purchases API de Google Play devuelve un registro por cada compra revertida, y cada registro lleva dos enteros que importan. El voidedReason dice por qué se anuló la compra. El voidedSource dice quién lo puso en marcha. Juntos convierten un reembolso escueto en una frase: este pedido se anuló por un contracargo, iniciado por Google, o se anuló por arrepentimiento, iniciado por el usuario. Los lees sondeando la API o suscribiéndote a la notificación de desarrollador en tiempo real que se dispara cuando llega una anulación. En cualquier caso, los dos números son la carga útil que vale la pena conservar.

Apple te da una señal más estrecha, pero precisa

Apple no te entrega un motivo de nueve valores. En una transacción reembolsada, Apple establece revocationReason en uno de dos valores. Un 1 significa que la App Store reembolsó la transacción debido a un problema real o percibido dentro de tu app. Un 0 significa que reembolsó por otro motivo, por ejemplo una compra accidental. El campo aparece solo en transacciones que fueron reembolsadas o revocadas, junto a un revocationDate, dentro de la información firmada de la transacción de la App Store Server Notification REFUND. Dos valores no es mucho, pero el que importa, un 1, es Apple diciéndote que el reembolso fue por tu producto, no por las dudas del cliente.

Los nueve motivos que te da Google Play

El voidedReason de Google es el más rico de los dos, y cada valor vale la pena conocerlo de un vistazo porque cada uno apunta a un lugar distinto. Aquí tienes el conjunto completo, directamente del recurso VoidedPurchase, con lo que cada código te está diciendo realmente que hagas.

voidedSource te dice quién apretó el gatillo

Junto al motivo se encuentra voidedSource, y responde a una pregunta distinta: quién revirtió esto. Un 0 significa que lo hizo el usuario, mediante autoservicio o un banco. Un 1 significa que lo hizo el desarrollador, que eres tú o tus propias herramientas emitiendo un reembolso. Un 2 significa que lo hizo Google, por su propio criterio, incluido el reembolso automático de una compra sin confirmar. Cuando veas un pico de anulaciones, la fuente es el primer corte. Un muro de fuente 2 es Google actuando sobre tu cuenta, y eso suele ser una señal que apunta de vuelta a tu integración en lugar de a tus clientes.

Clasifica cada reembolso en corregir, disputar o aceptar

La razón por la que un código es útil es que te dice cuál de tres respuestas merece un reembolso. La mayoría de los equipos tratan todos los reembolsos igual y gastan esfuerzo en los que nunca pueden ganar. Los códigos se dividen con claridad.

Corregir: los reembolsos que causó tu producto

Algunos códigos son informes de errores disfrazados de reembolso. Defectuoso (3) y no recibido (2) en Google, y un revocationReason de 1 en Apple, dicen todos lo mismo: el cliente pagó y tu app no entregó. La compra sin confirmar (8) es el más agudo de estos porque la culpa está enteramente en tu código de facturación. Estos son los reembolsos más baratos de eliminar, porque los eliminas corrigiendo algo que es tuyo, no persuadiendo a nadie. Un recuento creciente en este grupo es un defecto del producto con una cifra en dólares adjunta.

Disputar: los reembolsos que alguien está trabajando

Fraude (5), fraude amistoso (6) y contracargo (7) son las disputas. El fraude puro (5) no es tu cliente ni ingresos que ibas a conservar. El fraude amistoso (6), donde el comprador obtuvo exactamente lo que pagó y luego lo disputó, es la única disputa que tu evidencia aún puede mover, y el contracargo (7) es donde se presenta esa evidencia. Cuando uno de estos llega, revocas el acceso si no lo has hecho ya, y donde haya una ventana de revisión abierta la respondes con lo que sabes sobre la cuenta.

Aceptar: los reembolsos que nunca estuvieron en tus manos para detenerlos

El arrepentimiento (1) y la compra accidental (4) son el propio cambio de opinión del cliente. El revocationReason de 0 de Apple también entra aquí. Ninguna función falló y no hubo fraude. Puedes suavizar el grupo de accidentales con una confirmación de compra más clara, pero no puedes disputar un reembolso por arrepentimiento, y el tiempo dedicado a intentarlo es tiempo quitado del grupo de corregir, donde está realmente el dinero.

La trampa de los 30 días que hace fácil perder los códigos de motivo

Hay un límite estricto por el lado de Google que convierte esto de una función de informes en una fecha límite. Si no estás capturando los códigos de forma continua, los estás perdiendo.

La Voided Purchases API solo mira 30 días hacia atrás

Google es explícito en que la API solo puede mostrar compras anuladas de los últimos 30 días. Las anulaciones más antiguas no se devuelven sin importar qué startTime pases, y el propio valor de startTime no puede establecerse antes de hace 30 días. Peor para una integración ingenua, la ventana de 30 días se mide por cuándo los sistemas de Google ven una compra como anulada, no por cuándo se hizo la compra ni siquiera por el voidedTimeMillis del registro. Así que un código de motivo de reembolso que no extraigas dentro de esa ventana desaparece, y un trabajo de exportación mensual con cualquier hueco descartará silenciosamente las anulaciones que fue demasiado lento para captar.

Cuánto valen los códigos de motivo en dinero

Dos códigos llevan un precio específico, y leerlos es cómo pones un número a problemas que de otro modo se esconden dentro de una tasa de reembolso agregada.

Un código es una factura que te escribiste a ti mismo

voidedReason 8, compra sin confirmar, es el ejemplo más claro de un reembolso que causaste. Google Play requiere que tu app confirme una compra dentro de los tres días de otorgar la habilitación, y si no lo haces, Google reembolsa automáticamente el pedido y revoca el artículo. Cada anulación marcada con 8 es una venta real, de un cliente que quería el producto, devuelta porque una llamada para confirmar la compra nunca se disparó. El monto perdido es el precio de venta completo más el cómputo, las llamadas a la API y el almacenamiento que ya gastaste entregándolo. Este no es un reembolso que negocias. Es un error que cierras, y el código es cómo lo encuentras.

El código de contracargo ahora lleva una tarifa

voidedReason 7, contracargo, cambió de costo el 3 de agosto de 2026. Para los pedidos de Google Play realizados a partir de esa fecha, un contracargo perdido le cuesta al desarrollador el precio de la compra menos la tarifa de servicio de Play, más la tarifa de contracargo del banco, mientras que Google cubre solo su propia tarifa de servicio. Como las tarifas de contracargo son fijas y los precios de los productos no, en una compra dentro de la app barata la tarifa por sí sola puede superar lo que el cliente pagó. Contar tus anulaciones con código 7 es ahora contar una partida, no solo una venta perdida, que es exactamente por qué el grupo de contracargos merece su propia fila en cualquier informe de reembolsos que construyas.

Cómo se alinean Apple y Google

Las dos tiendas responden a la misma pregunta con resoluciones distintas, así que un informe de reembolsos entre tiendas tiene que normalizarlas en lugar de esperar que coincidan.

Las tiendas nunca te darán el mismo código para el mismo reembolso, y está bien. Lo que importa es que ambas te entregan un motivo legible por máquina, y ambas recompensan a un equipo que lo lee. El único bit de Apple te dice cuándo un reembolso es culpa de tu producto. Los nueve motivos de Google y su indicador de fuente te dicen qué error de producto, qué disputa y qué brecha de facturación autoinfligida estás mirando. Ningún código detiene un reembolso. Ambos te dicen qué hacer para que el próximo no ocurra.

RefundHalt captura el código de motivo en cada reembolso en el momento en que llega, en ambas tiendas, y lo retiene bien dentro de la ventana de 30 días de Google para que nada se escape. Clasifica cada anulación en corregir, disputar o aceptar, así que un pico en el código 3 defectuoso te llega como una alerta de producto y un pico en el código 8 sin confirmar te llega como un error de integración, no como una vaga caída en los ingresos. Responde el CONSUMPTION_REQUEST de Apple en 12 horas y la revisión de contracargo de Google Play en 24, y revoca el acceso en el momento en que llega un reembolso o un contracargo. No puedes cambiar el código que una tienda estampa en un reembolso. Puedes asegurarte de leer cada uno y actuar sobre los que realmente te corresponde corregir.