Etiqueta cada compra de Google Play con un id de cuenta ofuscado, o llegará un contracargo sin forma de rastrearlo

Una revisión de contracargo de Google Play aparece nombrando un pedido y un token de compra. No te dice quién es el cliente. Si nunca estampaste tu propio identificador en esa compra, ahora estás emparejando un simple id de pedido contra tu tabla de usuarios bajo un reloj de 24 horas, y tienes que responder con evidencia de uso que quizás no puedas encontrar. El id de cuenta ofuscado es la solución. Es una cadena corta que adjuntas en el pago que Google Play almacena con la compra y te devuelve más tarde, de modo que cada pedido puede rastrearse hasta el usuario exacto que lo realizó. Esto es lo que es el campo, por qué decide si puedes responder o no a una disputa, y qué cuesta omitirlo ahora que un contracargo perdido es una factura.

Qué es realmente el id de cuenta ofuscado

El id de cuenta ofuscado es una cadena opcional que pasas al flujo de facturación de Google Play cuando un cliente compra algo. Lo configuras con setObfuscatedAccountId en el constructor de BillingFlowParams, y Google lo almacena junto a la compra. No es el nombre del cliente, ni su correo electrónico, ni su cuenta de Google. Es tu propio identificador para tu propio usuario, escrito en una forma que Google puede conservar sin saber quién es la persona.

Es una cadena que configuras en el pago, no un nombre

En palabras de Google, setObfuscatedAccountId especifica una cadena ofuscada opcional que está asociada de forma única con la cuenta de usuario del comprador en tu app. La palabra ofuscada cumple un papel real. Google no quiere tu id de usuario en crudo ni nada que identifique a la persona. Quiere un token estable que se asigne uno a uno a un usuario de tu lado, y nada más. El campo está limitado a 64 caracteres, lo que aloja un hash cómodamente y poco más.

Google lo lee primero para su propio filtrado de fraude

Antes de que te sea útil, el campo cumple una tarea para Google. La documentación de facturación dice que Google Play puede usar este valor para detectar actividad irregular, como muchos dispositivos que realizan compras en la misma cuenta en un lapso breve, y que Google usa estos datos para detectar comportamiento sospechoso y bloquear algunos tipos de transacciones fraudulentas antes de que se completen. Así que el primer beneficio de configurarlo está aguas arriba, en compras más limpias y menos de las fraudulentas que se convierten después en anulaciones y disputas. Google lista el id de cuenta ofuscado y la Voided Purchases API juntas como sus dos herramientas centrales contra el abuso por una razón.

Por qué importa cuando llega una revisión de contracargo

Un reembolso que puedes ver venir es fácil. El caso difícil es el contracargo bancario, porque no empieza con tu cliente hablando contigo. Empieza con el banco, y Google Play te lo reenvía como una revisión con un reloj adjunto.

La disputa nombra un pedido, no a una persona

Cuando un cliente disputa un cargo con su banco y Google necesita tu aporte, Google Play envía una PendingRefundReviewNotification. Ese mensaje identifica el pedido. No lleva tu id de usuario, porque Google nunca tuvo tu id de usuario. Solo tenía lo que hayas estampado en la compra. Si eso fue nada, ahora estás buscando a la inversa un simple id de pedido y token de compra contra tus propios registros, esperando haber registrado el token en el momento de la compra y esperando que la coincidencia sea inequívoca. Si configuraste un id de cuenta ofuscado, la compra lleva tu propio hash, buscas al usuario en una sola consulta, y pasas a construir evidencia en lugar de buscar la identidad.

Qué te pide realmente orders.reviewrefund

Responder a la disputa significa llamar al método orders.reviewrefund dentro de 24 horas. Google registra tu primera llamada e ignora el resto, así que la primera respuesta es la única respuesta. Estos son los campos que quiere, y cada uno de los campos de evidencia asume que ya sabes a qué usuario pertenece el pedido.

Qué cuesta realmente omitirlo

Durante la mayor parte de la historia de Google Play, un contracargo que no podías defender era una venta perdida y un encogimiento de hombros. Eso cambió. Para pedidos realizados a partir del 3 de agosto de 2026, un contracargo perdido factura al desarrollador el precio de compra menos la tarifa de servicio de Google, más la tarifa de contracargo del banco. La disputa que no puedes responder es ahora una partida de gasto.

Sigamos un pedido. Un cliente disputa una compra de $9.99 con su banco. Google Play envía la revisión, y tienes 24 horas. Si etiquetaste la compra, encuentras al usuario, ves que consumió la mayor parte de lo que compró, y respondes reviewrefund con una preferencia DECLINE y la evidencia de consumo, dándole a Google un caso real para impugnar una disputa ilegítima. Si no la etiquetaste, o no puedes identificar el pedido a tiempo o respondes sin nada, la disputa se decide sin tu versión, y en un pedido posterior al 3 de agosto pagas los $9.99 menos la tarifa de Google de vuelta, más una tarifa fija de contracargo bancario que a menudo ronda los $20. En una venta pequeña, esa tarifa fija por sí sola puede ser mayor que lo que ganaste neto.

• Los ingresos perdidos: tu parte neta de la venta, revertida.
• La tarifa de contracargo del banco: un costo fijo que fija la red de tarjetas, cobrado adicionalmente en pedidos realizados después del 3 de agosto de 2026, que un simple reembolso nunca lleva.
• El gasto desperdiciado: el cómputo, las llamadas a API de terceros y el almacenamiento que la cuenta ya usó, perdidos hayas podido responder o no.
• El patrón que no puedes ver: sin un id de cuenta estable tampoco puedes saber que el mismo usuario está disputando una y otra vez, así que el abuso en serie se lee como pérdidas aisladas no relacionadas.

Cómo configurarlo sin que se bloqueen las compras

Dos reglas cubren casi todos los errores que cometen los equipos con este campo. Aplica hash al id, y configúralo en todas partes.

Aplica hash a tu id de usuario, nunca envíes PII

No pongas un correo electrónico, un número de teléfono ni ningún dato personal en crudo en este campo. Google es explícito en que almacenar PII como correos electrónicos en texto claro hace que las compras se bloqueen, y recomienda un hash unidireccional o cifrado para generar el valor. El patrón limpio es un hash unidireccional de tu id de usuario interno, calculado de la misma forma cada vez para que el mismo usuario siempre produzca la misma cadena de 64 caracteres. Tampoco uses el id de cuenta de Google de la persona ni tu id de desarrollador. El valor debería significar algo solo para tu sistema.

Configúralo en cada compra, y léelo de vuelta en tu servidor

Adjunta el id a cada flujo de facturación, tanto productos de pago único como suscripciones, para que ninguna compra quede sin etiquetar. Después de la compra, léelo de vuelta en dos lugares. En el cliente, Purchase.getAccountIdentifiers devuelve un objeto cuyo getObfuscatedAccountId te da la cadena que configuraste. En tu backend, el registro de compra del lado del servidor lo lleva como el campo obfuscatedExternalAccountId, y la copia del servidor es la que hay que confiar, porque una disputa llega a tu servidor, no al dispositivo.

Usa setObfuscatedProfileId cuando una cuenta tiene muchos perfiles

Si tu app permite que una cuenta tenga varios perfiles, un hogar de streaming o un juego con varios personajes, configura también setObfuscatedProfileId. Es el mismo tipo de cadena con hash, de 64 caracteres y sin PII, acotada al perfil que realizó la compra. Google señala que configurar un id de perfil también requiere que se pase el id de cuenta, así que envía ambos. El resultado es que una disputa se asigna no solo a la cuenta sino al perfil exacto que gastó el dinero.

El paralelo de iOS, en una línea

La App Store tiene la misma idea bajo un nombre diferente. En iOS adjuntas un appAccountToken, un UUID, a una compra, y vuelve en la transacción y en la CONSUMPTION_REQUEST que Apple envía cuando un cliente pide un reembolso. La forma del problema es idéntica en ambas tiendas. El flujo de disputa o reembolso hace referencia a una transacción, y tu propio identificador es lo que la vincula de vuelta a un usuario cuya actividad puedes reportar.

Nada de esto es difícil de construir. Es fácil de omitir, porque el día en que escribes el código de pago no es el día en que llega un contracargo, y el costo de omitirlo es invisible hasta entonces. RefundHalt configura y rastrea el identificador de cuenta en ambas tiendas, mantiene el vínculo compra-usuario para que una disputa siempre se resuelva a un cliente real, y responde a orders.reviewrefund de Google Play y a la CONSUMPTION_REQUEST de Apple dentro de sus ventanas con la evidencia de consumo registrada en el momento de la venta. El reloj de 24 horas no es el momento de descubrir que no puedes saber quién compró la cosa.