El abuso reiterado de reembolsos te cuesta dos veces, así es como las tiendas te dejan defenderte

Un solo reembolso es un costo de hacer negocios. La misma cuenta reembolsando por cuarta vez, después de usar lo que compró cada vez, es abuso de reembolsos, y es un patrón que solo puedes ver si cada compra lleva una identidad que tú controlas. Apple y Google te dan esa identidad, y ambos te dan una ventana estrecha para ponerla delante de la tienda antes de que se decida un reembolso o un contracargo. Pierde la ventana, o nunca adjuntes la identidad, y un reembolsador reincidente se ve exactamente igual que un cliente descontento por primera vez. Aquí te explicamos cómo distinguirlos, y cuánto vale esa diferencia en dinero.

Por qué el abuso de reembolsos es un problema de identidad, no de reembolsos

La tienda decide el reembolso. No puedes impedir que un cliente lo pida, y en la mayoría de los flujos no puedes impedir que la tienda lo conceda. Lo que sí puedes hacer es decidir si una cuenta determinada ya hizo esto antes, y si el contenido que compró fue realmente entregado y usado. Ambas son preguntas sobre identidad: cuál de tus usuarios está detrás de esta transacción, y cuál es su historial. Si tus compras no llevan un identificador estable de vuelta a tus propios registros de usuario, no puedes responder ninguna de las dos, y cada reembolso llega sin contexto.

Esa es la verdadera brecha. La mecánica del reembolso está fijada por la política. Las pruebas que aportas son enteramente tuyas para construir, y empiezan en el momento de la compra, no en el momento del reembolso.

Las dos ventanas donde las pruebas cambian el resultado

Hay exactamente dos flujos donde algo que envías puede mover una decisión. El CONSUMPTION_REQUEST de Apple se dispara cuando un cliente pide un reembolso de un consumible o una suscripción de renovación automática, y tienes 12 horas para responder. La revisión de contracargos de Google Play se dispara cuando un usuario disputa un cargo con su banco, y tienes 24 horas para responder mediante la Review Refund API. Cualquier otro reembolso, el reembolso de autoservicio de 48 horas de Play, un reembolso concedido por soporte, un reembolso automático por compra no reconocida, se decide sin ti.

Ambos canales de prueba son mucho más sólidos cuando la transacción ya lleva tu identificador. La información de consumo de Apple puede incluir el appAccountToken junto con el historial y el gasto de la cuenta, y la revisión de Google puede apoyarse en el ID de cuenta ofuscado que ha estado observando desde la compra. Una cuenta sin identificador es una cuenta sin historial que presentar.

Los dos campos de identidad, uno al lado del otro

Apple y Google resolvieron el mismo problema casi de la misma manera, con nombres distintos y reglas distintas. Ambos te permiten estampar una compra con un valor que apunta de vuelta a tu propio registro de usuario. Ninguno está activo por defecto. Ambos son inútiles si no los estableces en el momento de la compra.

Apple: appAccountToken

appAccountToken es un UUID que generas y pasas cuando comienza una compra. StoreKit lo asocia con la transacción resultante, y aparece en los datos de la transacción que tu servidor verifica y en la información de consumo que devuelves durante un CONSUMPTION_REQUEST. Como es tu valor, mapea una transacción de la tienda directamente sobre la cuenta en tu base de datos, sin correo electrónico ni nombre de por medio. Tiene que ser un UUID real, y cualquier otra cosa se rechaza. Apple luego añadió un endpoint Set App Account Token que puede adjuntar o actualizar el token en transacciones pasadas, incluidas compras hechas fuera de tu app, como canjes de códigos de oferta.

Google Play: el ID de cuenta ofuscado

El equivalente de Google es setObfuscatedAccountId, una cadena opcional vinculada a la cuenta compradora. La propia documentación de Google es tajante sobre su propósito: Google Play lo usa para detectar actividad irregular, como muchos dispositivos haciendo compras en la misma cuenta en un lapso breve, y para bloquear algunas transacciones fraudulentas antes de que se completen. Está limitada a 64 caracteres, y no debe llevar datos personales en texto plano. Guarda ahí un correo electrónico sin procesar y Google bloquea la compra directamente, porque el campo espera un valor cifrado o un hash de un solo sentido. Un campo hermano, setObfuscatedProfileId, existe para apps donde una cuenta contiene varios perfiles.

Cuánto cuesta realmente un reembolso de un abusador reincidente

El reembolso en sí es la parte más pequeña de la factura. Cuando una tienda concede un reembolso, devuelves los ingresos, y eso es lo visible en el libro de cuentas. Lo que no está en la línea del reembolso es todo lo que gastaste entregando el producto que ahora es gratis.

Imagina un consumible que desencadena trabajo real: una generación de imágenes, un lote de llamadas a la API de un proveedor de modelos, una exportación de video, un pago a un creador. Pagaste ese cómputo en el momento en que el cliente lo usó. El reembolso recupera el precio, pero no recupera la factura del proveedor. Un reembolsador reincidente es alguien que ha aprendido que el contenido sobrevive al reembolso, así que repite el bucle: compra, consume, reembolsa, repite. En cada ciclo, asumes el costo de entrega por segunda vez.

Luego está el propio traspaso de costos de la tienda. A partir del 3 de agosto de 2026, Google Play traslada el precio de compra y las comisiones de contracargo del banco al desarrollador para los pedidos realizados después de esa fecha. Un contracargo que antes era mayormente problema de Google se convierte en tus ingresos más una comisión, y un cargador reincidente aumenta esa cifra cada vez. Los campos de identidad son lo que te permite alimentar la Review Refund API con las pruebas para impugnar una disputa ilegítima dentro de la ventana de 24 horas.

Google plantea la escala sin rodeos: dice que bloqueó más de 2000 millones de dólares en transacciones fraudulentas y abusivas en 2022. Ese número existe porque las señales, el ID de cuenta ofuscado entre ellas, estaban rellenas. Una app que envía compras con campos de identidad vacíos renuncia a esa protección.

Cómo atrapar a los reembolsadores reincidentes antes de que la tienda decida

Etiqueta cada compra con una identidad que sea tuya

Establece appAccountToken en cada compra de StoreKit y setObfuscatedAccountId en cada compra de Play Billing, ambos generados a partir de tu propio registro de usuario. En Apple, usa un UUID real mapeado a la cuenta. En Google, aplica hash a la clave de la cuenta para que ningún dato personal viaje en texto plano. Hazlo en el momento de la compra, porque en Google es el único paso que no puedes recuperar después.

Mantén un libro de cuentas con clave en esa identidad

Guarda cada compra, entrega, evento de consumo y reembolso contra el identificador. Cuando llega un CONSUMPTION_REQUEST o una revisión de contracargo, el historial completo de la cuenta, reembolsos previos incluidos, está a una sola consulta de distancia. La información de consumo de Apple tiene campos explícitos justo para esto: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, y tu refundPreference.

Lee voidedReason y enruta a los abusadores de forma distinta

Cuando una compra de Google se anula, el campo voidedReason te dice por qué, y friendly_fraud y fraud son valores separados de un reembolso ordinario de tipo remorse. Enruta esos a una cola de revisión y a una política más estricta, no a la misma ruta automática que un reembolso por primera vez. La propia guía de Google es un modelo de varias advertencias: advierte a un primer infractor, toma medidas más firmes con los reincidentes, y desactiva las compras para una cuenta que insiste.

Responde a la ventana siempre

Las pruebas solo cuentan dentro de las dos ventanas. Automatiza la respuesta del CONSUMPTION_REQUEST para que se dispare bien dentro de las 12 horas, y la revisión de contracargo para que se dispare dentro de las 24. Un historial perfecto que envías tarde es un historial que la tienda nunca lee.

Qué harán y qué no harán las tiendas por ti

Vale la pena ser preciso sobre la división del trabajo, porque es fácil suponer que las tiendas se ocupan del abuso, y en su mayoría no te avisan cuando no lo hacen. Google usa activamente el ID de cuenta ofuscado para bloquear algún fraude antes de que se complete una compra, y sus sistemas atrapan una gran parte a nivel de plataforma. Apple decide cada reembolso por sí misma y trata tu información de consumo como una entrada, nunca un voto. Ninguna tienda mantiene tu lista de abusadores por ti, deduce un consumible reembolsado de tu saldo, ni le dice que no a un reembolsador reincidente en tu nombre. La identidad es de la tienda para actuar en los márgenes y tuya para actuar en todo lo demás.

Esta es la misma razón por la que RefundHalt basa todo en la identidad de la compra: un reembolso, una revisión de contracargo y una solicitud de consumo para la misma cuenta se resuelven en un solo historial, de modo que un reembolsador reincidente aparece como un patrón la primera vez que repite, no después de la cuarta factura que ya pagaste.