Alguien que pide un reembolso por cuarta vez no es un cliente insatisfecho. Está ejecutando una rutina, y te cuesta los ingresos devueltos más todo lo que gastaste en cumplir el pedido. Apple y Google exponen cada uno un campo de identidad, appAccountToken de un lado y el ID de cuenta ofuscado del otro, que convierte esos incidentes separados en un patrón visible.
Puntos clave
Tu evidencia llega a una tienda en exactamente dos situaciones: el CONSUMPTION_REQUEST de Apple, que puedes responder dentro de 12 horas, y la revisión de contracargo de Google Play mediante la Review Refund API, que puedes responder dentro de 24. Todo lo demás se decide sin tu participación.
En Apple, un UUID que tú generas viaja con la compra como appAccountToken. StoreKit lo vincula a la transacción, lo que significa que cualquier reembolso posterior se resuelve hacia una cuenta identificable en tus propios registros.
El equivalente de Google es una cadena hasheada de no más de 64 caracteres. El propio Google la lee y usa el campo para detectar comportamientos irregulares, como una sola cuenta comprando desde una cantidad inverosímil de dispositivos en un lapso corto.
Los datos personales en texto claro en ese campo de Google bloquearán las compras directamente. Se requiere un valor cifrado o un hash de un solo sentido. Una dirección de correo electrónico sin cifrar no sirve.
El voidedReason de Play distingue friendly_fraud y fraud de un reembolso ordinario por simple cambio de opinión, lo que te da motivos para enviar a los infractores recurrentes a una cola de revisión en lugar del camino predeterminado de reembolsar y seguir adelante.
Google reporta haber detenido más de $2,000 millones en transacciones fraudulentas y abusivas durante 2022. Esas defensas funcionan con señales de identidad que solo existen si tus compras las llevan.
El acceso que sobrevive a un reembolso sigue consumiendo almacenamiento, cómputo y presupuesto de API por el que ya no te están pagando, y alguien que pide reembolsos deliberadamente está provocando exactamente ese resultado una y otra vez.
Introducción
Los reembolsos ocurren, y uno de ellos es simplemente un costo operativo. Lo que cambia el panorama es que la misma cuenta regrese por cuarta vez, habiendo consumido el producto en cada ocasión anterior. Ese comportamiento solo es legible para ti si cada transacción llega con un identificador que tú asignaste. Ambas plataformas ofrecen uno. Ambas también abren una ventana de respuesta estrecha antes de que se resuelva el resultado. Si omites el identificador, o pierdes la ventana, alguien que manipula el sistema resulta indistinguible de un cliente primerizo con una queja genuina. Lo que separa a ambos, y cuánto vale en dinero esa diferencia, es lo que sigue.
El abuso de reembolsos es en realidad un problema de identidad disfrazado de reembolso
Las decisiones de reembolso le pertenecen a la tienda. Los clientes pedirán, y en la mayoría de los flujos la tienda accederá, sin que tengas ninguna posibilidad de intervenir. Tu influencia está en otra parte: establecer si esta cuenta en particular tiene un historial de hacer esto, y si lo que compró realmente fue entregado y consumido. Ambas preguntas son preguntas de identidad. Qué usuario está detrás de esta transacción, y qué ha hecho antes. Las compras que no llevan un vínculo estable hacia tus registros de usuario dejan ambas preguntas sin respuesta, así que cada reembolso llega despojado de contexto.
Esa es la brecha que vale la pena cerrar. La política fija la mecánica y tú no puedes modificarla. La evidencia, en cambio, es tuya de reunir, y esa reunión empieza en el checkout, no en el reembolso.
Dos ventanas donde lo que envías realmente importa
Solo dos flujos tratan tu aporte como un aporte real. Un cliente que solicita un reembolso de un consumible o una suscripción de renovación automática activa el CONSUMPTION_REQUEST de Apple, y tu respuesta debe llegar dentro de 12 horas. Un cliente que disputa un cargo con su banco activa la revisión de contracargo de Google Play, que puedes responder a través de la Review Refund API dentro de 24. Fuera de esos dos casos, la decisión ocurre sin ti: el reembolso de autoservicio de 48 horas de Play, un reembolso otorgado por soporte, un reembolso automático para una compra que nunca llegaste a confirmar.
Ambos canales se vuelven considerablemente más precisos cuando la transacción ya lleva tu identificador. La información de consumo enviada a Apple puede incluir appAccountToken junto con el gasto e historial de esa cuenta, mientras que la revisión de Google se basa en un ID de cuenta ofuscado que ha estado observando desde que se completó la compra. Donde no hay identificador, no hay historial que presentar.
Los dos campos de identidad, comparados
Ambas empresas llegaron a soluciones casi idénticas bajo nombres distintos y con restricciones distintas. Cada una te permite marcar una compra con un valor que remite a tu propio registro de usuario. Ninguna viene activada para ti. Ambas son inútiles a menos que se establezcan mientras la compra está ocurriendo.
Apple: appAccountToken
Genera un UUID, pásalo cuando comienza la compra, y StoreKit lo vincula a la transacción resultante. Luego aparece en los datos de transacción que tu servidor verifica, y de nuevo en la información de consumo que devuelves durante un CONSUMPTION_REQUEST. Como el valor se originó contigo, resuelve una transacción de la tienda hacia una fila de tu base de datos sin involucrar ningún nombre o correo electrónico. Solo se aceptan UUID reales; cualquier otra cosa se rechaza. Apple desde entonces lanzó un endpoint Set App Account Token capaz de escribir o actualizar el token en transacciones que ya ocurrieron, incluyendo canjes de códigos de oferta y compras similares fuera de la app.
Google Play: el ID de cuenta ofuscado
setObfuscatedAccountId es la versión de Google, una cadena opcional vinculada a la cuenta que realiza la compra. La documentación de Google declara su propósito sin ambigüedades: Play usa el valor para detectar actividad irregular, siendo el ejemplo dado muchos dispositivos transaccionando en una sola cuenta dentro de una ventana breve, y para detener algunas compras fraudulentas antes de que se completen. El límite es de 64 caracteres, y los datos personales en texto claro están prohibidos. Coloca ahí un correo electrónico sin cifrar y la compra se bloquea, porque lo que el campo espera es un valor cifrado o un hash de un solo sentido. Las apps donde una sola cuenta contiene varios perfiles cuentan con un campo complementario, setObfuscatedProfileId.
appAccountToken es el campo de Apple. Tiene que ser un UUID y nada más, tu código lo establece durante el checkout, y está ausente a menos que tú lo agregues. Apple lo usa para anclar la transacción a tu usuario, y reaparece en las cargas útiles de transacción y de consumo.
obfuscatedAccountId es el campo de Google Play. Recibe una cadena hasheada de hasta 64 caracteres, tu código lo establece durante el checkout, y también está ausente por defecto. Google lo incorpora a su detección de actividad irregular y lo usa para detener algunas compras fraudulentas antes de que se completen.
Una asimetría importa enormemente. Google no ofrece ninguna forma de retroaplicar el identificador. Una compra de Play completada sin el identificador queda permanentemente anónima, y etiquetar las compras futuras es el único remedio disponible. El endpoint Set App Account Token de Apple puede reparar el historial, lo que lo convierte en la excepción y no en la norma.
Calculando el costo de un reembolso de alguien que lo hace repetidamente
Los ingresos devueltos son la parte visible y también la parte menor. Otorgar un reembolso devuelve el precio de venta, que tu libro contable registra. Ausente de esa línea está todo lo gastado en producir lo que el cliente ahora tiene gratis.
Considera un consumible que pone en marcha trabajo real: imágenes generadas, una serie de llamadas a un proveedor de modelos, un video exportado, un pago liberado a un creador. Ese cómputo se compró en el momento del uso. El reembolso recupera el precio de venta y deja la factura del proveedor exactamente donde estaba. Alguien que ha descubierto que el producto sobrevive al reembolso simplemente repite la secuencia: comprar, consumir, reembolsar, y cada iteración te cobra de nuevo el costo de entrega.
También está la plataforma trasladando costos hacia ti. A partir del 3 de agosto de 2026, Google Play asigna tanto el precio de compra como las tarifas de contracargo del banco a los desarrolladores, para pedidos realizados desde esa fecha. Las disputas que antes eran en gran parte un gasto de Google se convierten en tus ingresos perdidos más una tarifa, y alguien que hace contracargos habitualmente escala esa cifra con cada intento. Los campos de identidad son lo que hace posible entregarle a la Review Refund API algo que valga la pena leer dentro de la ventana de 24 horas.
Google pone una cifra a la magnitud del problema: más de $2,000 millones en transacciones fraudulentas y abusivas bloqueadas durante 2022. Esa cifra existe porque las señales subyacentes, el ID de cuenta ofuscado entre ellas, estaban realmente pobladas. Enviar compras con esos campos vacíos es una decisión de quedarte fuera de esa protección.
Detectando reembolsadores recurrentes antes de que la tienda decida
Marca cada compra con una identidad que controlas
Ninguna de las dos plataformas debería ver una compra sin uno. Las compras de StoreKit llevan appAccountToken, las compras de Play Billing llevan setObfuscatedAccountId, y ambos valores se originan en tu propio registro de usuario. Apple espera un UUID genuino vinculado a esa cuenta, Google espera la clave de la cuenta hasheada para que nada personal viaje en claro. El checkout es el momento para ambos, y en Google ese momento no se puede renegociar después.
Mantén un registro indexado por esa identidad
Registra las entregas, los eventos de consumo, las compras y los reembolsos, todo archivado bajo ese identificador. Un CONSUMPTION_REQUEST o una revisión de contracargo pone entonces todo el pasado de esa cuenta, reembolsos anteriores incluidos, a una sola consulta de distancia. La información de consumo de Apple ofrece campos dedicados precisamente para este material: consumptionStatus, deliveryStatus, playTime, accountTenure, lifetimeDollarsPurchased, y tu propio refundPreference.
Trata voidedReason como una decisión de enrutamiento
Las compras anuladas de Play llevan un voidedReason que explica la causa, y friendly_fraud y fraud se registran por separado del simple arrepentimiento habitual. Esos casos merecen una cola de revisión y una política más firme en lugar del manejo automático que recibe un reembolso de primera vez. La guía de Google describe respuestas escalonadas: una advertencia al principio, algo más firme ante la repetición, y compras deshabilitadas para las cuentas que persisten.
Nunca pierdas la ventana
La evidencia presentada tarde es como si no existiera. Automatiza la respuesta al CONSUMPTION_REQUEST para que se envíe cómodamente dentro de las 12 horas, y la revisión de contracargo dentro de las 24. Un historial de cuenta impecable presentado después del plazo es un historial que nadie en la tienda abrirá.
Para detectar una cuenta transaccionando desde una cantidad inverosímil de dispositivos a la vez, apóyate en la detección de actividad irregular de Google Play, que lee el ID de cuenta ofuscado.
Para ver un historial previo de reembolsos en esta cuenta, apóyate en tus propios registros, es decir, el libro que indexaste con el identificador de cualquiera de las plataformas.
Para confirmar que el producto realmente llegó al comprador y fue usado, apóyate en Apple, donde consumptionStatus y deliveryStatus viven dentro de la información de consumo.
Para detectar una disputa que en realidad es el comprador defraudándote, apóyate en Google Play, donde voidedReason regresa como friendly_fraud.
Dónde ayudan las plataformas, y dónde se detienen
Vale la pena ser preciso sobre la división de responsabilidades, porque es fácil suponer que las tiendas se encargan del abuso, y rara vez anuncian el punto en el que dejan de hacerlo. Google de verdad lee el ID de cuenta ofuscado para bloquear algo de fraude antes de la compra, y los sistemas a nivel de plataforma interceptan un volumen sustancial. Apple se reserva para sí cada decisión de reembolso y trata tu información de consumo como evidencia, no como un voto. Lo que ninguna tienda hace es mantener una lista de abusadores en tu nombre, acreditar de vuelta a tu saldo un consumible reembolsado, o rechazar por ti a un reembolsador recurrente. En los márgenes, la identidad es algo sobre lo que la tienda puede actuar. En todo lo demás, es tuya.
Refund Sensor está diseñado alrededor de esa identidad por la misma razón. Un reembolso, una revisión de contracargo y una solicitud de consumo que pertenecen a una misma cuenta colapsan en un solo historial, de modo que un patrón recurrente se vuelve visible en la segunda ocasión en lugar de después de que ya se haya pagado la cuarta factura.
Dónde están documentadas estas reglas
Preguntas frecuentes
Describe a un cliente que solicita reembolsos repetidamente después de recibir y usar lo que compró, conservando el beneficio mientras recupera el pago. En el contexto de una tienda de apps, esto suele presentarse como una misma cuenta reembolsando consumibles o suscripciones una y otra vez, o como fraude amistoso, donde un cargo válido se disputa a través del banco en su lugar.
En Apple generas un UUID, lo entregas como appAccountToken cuando comienza la compra, y StoreKit lo adjunta a la transacción resultante, desde donde reaparece tanto en los datos de transacción como en los datos de consumo. En Google llamas a setObfuscatedAccountId usando un valor hasheado derivado de esa cuenta. Ambos enfoques resuelven una transacción de la tienda hacia tu propio registro de usuario sin exponer nada personal.
Ninguno lo hará, al menos no directamente. Google lee el ID de cuenta ofuscado para identificar actividad irregular y detener algo de fraude antes de la compra, y Apple acepta el historial de la cuenta enviado durante una solicitud de consumo, pero ninguna de las dos empresas te devuelve una lista de infractores recurrentes. Armar esa lista te corresponde a ti, construida a partir de los registros que archivaste bajo esos identificadores.
Los datos personales en texto claro en el ID de cuenta ofuscado son la razón habitual. Colocar algo como una dirección de correo electrónico sin cifrar ahí hace que Play bloquee la compra directamente. En su lugar, proporciona un valor cifrado o un hash de un solo sentido, manteniéndote dentro del límite de 64 caracteres.
Lo reduce en lugar de detenerlo. CONSUMPTION_REQUEST es una de las únicas dos vías donde tu evidencia llega antes de la decisión, y el historial de la cuenta combinado con los datos de entrega y consumo ayuda a Apple a reconocer el abuso de devoluciones y el fraude amistoso. Sin embargo, Apple sigue siendo quien decide, y el abuso que llega a través de flujos que no puedes contestar permanece sin resolver.
