DeviceCheck de Apple recuerda el teléfono de quien abusa de los reembolsos, incluso si se registra con una cuenta nueva

Bloquear la cuenta no detiene a quien abusa de los reembolsos y vuelve a registrarse en el mismo teléfono. DeviceCheck de Apple y la recuperación de dispositivos (device recall) de Google Play existen justo para ese hueco. Cada uno permite a tu servidor asociar unos pocos bits, con el significado que tú elijas, a un dispositivo físico. Se guardan en los servidores de la tienda, así que la marca sigue ahí cuando la persona vuelve con un correo nuevo. Ninguna de las dos herramientas te da un ID de dispositivo, y ninguna puede detener un reembolso. Lo que hacen es avisarte, en el registro o en el muro de pago, de que este dispositivo ya te ha costado dinero.

Esto es lo que guarda realmente cada tienda, la trampa de tiempos que decide si puedes llegar a poner la marca y lo que cuesta un abusador reincidente antes de que lo detectes.

Por qué una cuenta nueva supera cualquier defensa a nivel de cuenta

La mayoría de las defensas contra reembolsos se basan en una cuenta. El appAccountToken de Apple vincula una transacción a un usuario de tu base de datos. El ID de cuenta ofuscado de Google Play hace lo mismo en Android. Conviene establecer ambos en cada compra, y ambos describen la cuenta de una persona, no el hardware que tiene en la mano. Si borra la cuenta y se registra con un correo nuevo, tu historial sobre esa persona empieza de cero.

Las tiendas no cubren ese hueco por ti. Una notificación de reembolso del App Store te dice qué transacción se reembolsó. Una compra anulada de Google Play te da el token de compra, el ID del pedido y un voidedReason. Ninguna incluye un identificador de dispositivo. Un desarrollador de una app de citas describió el resultado en un hilo de los Apple Developer Forums: perfiles fraudulentos compraban una y otra vez una membresía premium que luego se reembolsaba, y bloquear sus dispositivos con el método propio del desarrollador no sirvió de nada.

¿Una cuenta nueva reinicia la prueba de la propia tienda?

No con la misma Cuenta de Apple. La documentación de Apple indica que las ofertas introductorias, incluidas las pruebas gratuitas, son para clientes que aún no han recibido una para ese producto ni para ningún producto del mismo grupo de suscripciones. Por eso, iniciar sesión con otra cuenta dentro de tu app no da una segunda prueba de Apple. Una Cuenta de Apple nueva sí la da, igual que todo lo que regalas tú: créditos de registro, una prueba financiada por tu servidor, un bono por referidos. Esos son los regalos que protege una marca de dispositivo.

Qué guarda realmente DeviceCheck de Apple

DeviceCheck tiene dos partes. En la app, la clase DCDevice genera un token efímero que identifica el dispositivo. En tu servidor, envías ese token a Apple junto con un JSON web token firmado con una clave de tu cuenta de desarrollador, y Apple te permite consultar o actualizar dos bits de ese dispositivo. La respuesta de la consulta devuelve bit0, bit1 y last_update_time, expresado como año y mes. Los ejemplos de uso que da Apple son un dispositivo que ya aprovechó una oferta promocional y un dispositivo que has determinado que es fraudulento.

Apple guarda los bits, pero el significado es tuyo. Su documentación dice que eres responsable de llevar el control de lo que significan los bits y de decidir cuándo restablecerlos, y pone como ejemplo un dispositivo vendido. Dos bits dan cuatro estados, así que un esquema sencillo es un bit para reembolsado tras un uso intensivo y otro para ya recibió créditos gratuitos.

• El token es de un solo uso. Apple dice que sigue siendo válido el tiempo suficiente para reintentar una petición, pero conviene generar uno nuevo para cada llamada.
• Las compilaciones de desarrollo se comunican con api.development.devicecheck.apple.com. En producción hay que usar api.devicecheck.apple.com, o tus marcas acabarán en el lugar equivocado.
• Apple describe DeviceCheck como un dato más dentro de una evaluación global de riesgo, no como un veredicto. Trata un bit activado como un motivo para mirar con más atención.

Qué añade la recuperación de dispositivos de Google en Android

La versión de Google forma parte de la Play Integrity API y sigue en beta, con acceso mediante un formulario de interés. Cuando te aprueban y la activas en Play Console, cada veredicto de integridad incluye tres bits personalizados para el dispositivo. Los escribes con una llamada de servidor al endpoint deviceRecall:write, usando un token de integridad que ya has verificado. Google dice que los datos sobreviven a una reinstalación de la app y a un restablecimiento del dispositivo, porque se guardan en los servidores de Google.

La documentación de Google es inusualmente clara sobre el caso de uso. Menciona dispositivos con pruebas de abuso grave, dispositivos que ya canjearon un artículo de alto valor como una prueba gratuita y dispositivos usados una y otra vez para crear cuentas nuevas con fines abusivos. Es igual de clara sobre el límite: device recall solo puede usarse para proteger la seguridad de la app y combatir el abuso, el fraude y el acceso no autorizado, nunca para identificar por huella digital ni rastrear a usuarios concretos, y nunca para guardar rasgos sensibles como la edad, el género o la ubicación.

El problema de los tiempos: los reembolsos llegan cuando el token ya no está

Ambas herramientas necesitan algo del propio dispositivo antes de poder marcarlo. Apple necesita un token DCDevice nuevo. Google necesita un token de integridad de ese dispositivo con un máximo de 14 días de antigüedad. El reembolso, en cambio, llega a tu servidor mediante una notificación de la tienda que no sabe nada del dispositivo. Así que la cuestión no es si marcar un dispositivo. Es si todavía tendrás forma de llegar a él cuando llegue el reembolso.

Los reembolsos de 48 horas de Google caben en la ventana de 14 días

Los reembolsos por autoservicio de Google Play solo están disponibles en las 48 horas siguientes a la compra, muy dentro de los 14 días en que un token de integridad sigue sirviendo para escribir. Haz una comprobación de integridad en el momento de la compra, guarda el token verificado junto al ID del pedido y, cuando llegue una compra anulada de ese pedido, podrás escribir el bit de inmediato. Los contracargos son el caso difícil, porque una disputa bancaria puede llegar mucho después del día 14.

Los reembolsos de Apple necesitan que el dispositivo vuelva

Un reembolso de Apple puede llegar semanas después de la compra, y un token de DeviceCheck guardado no está pensado para reutilizarse. La respuesta práctica es marcar primero la cuenta y después el dispositivo. Cuando llegue la notificación de reembolso, marca la cuenta en tu base de datos. La próxima vez que esa cuenta abra la app, pide un token de DeviceCheck y activa el bit. Quienes se quedan con el contenido tras un reembolso suelen volver, porque usarlo era el objetivo.

• En la compra, registra la transacción contra tu propia cuenta mediante appAccountToken o el ID de cuenta ofuscado.
• Ante un reembolso o una anulación, marca esa cuenta en tu servidor.
• En la siguiente sesión de la cuenta marcada, obtén un token del dispositivo y activa tu bit.
• En cada registro, consulta los bits antes de conceder algo que te cueste dinero.

Lo que te cuesta un abusador reincidente de reembolsos

El precio reembolsado es la parte visible. El resto es todo lo que la compra ya puso en marcha. Si tu app gasta dinero para entregar lo que vende, cada ciclo de comprar, consumir y reembolsar deja ese dinero gastado: tiempo de GPU para imágenes generadas, llamadas de pago a una API de modelos o de datos, almacenamiento para exportaciones que el cliente conserva y pagos a creadores calculados sobre la venta. Una cuenta nueva reabre el ciclo, y tu contabilidad lo registra como un cliente totalmente nuevo.

Los regalos gratuitos se escapan del mismo modo sin que haya reembolso alguno. Un dispositivo que acumula créditos de registro en diez cuentas consume diez veces la capacidad de cómputo que presupuestaste para una sola prueba. En Google Play, los contracargos de pedidos posteriores al 3 de agosto de 2026 también te cuestan el precio de compra menos la comisión de servicio de Google, más las comisiones del banco, así que quien disputa desde una cuenta nueva cada vez te cuesta la disputa completa de nuevo.

Qué hacer con un dispositivo marcado

Una marca responde a una sola pregunta: ¿debe este dispositivo volver a recibir algo gratis? Mantén una respuesta proporcionada, porque un bit activado es un indicio, no una prueba. Los teléfonos se revenden, las familias comparten iPads, y Google te dice expresamente que valores ignorar o restablecer los datos antiguos por ese motivo.

• Omite los créditos de registro, la prueba financiada por tu servidor o el bono por referidos en un dispositivo marcado, y ofrece el plan de pago en su lugar.
• No firmes una oferta promocional para un dispositivo marcado. En el App Store, tu servidor genera la firma que desbloquea una oferta promocional, así que la decisión es tuya.
• Exige que el pago se confirme antes de entregar consumibles caros en un dispositivo marcado.
• Usa la marca de tiempo. Una marca puesta el mes pasado pesa más que una puesta hace dos años.
• Da a las personas una vía para contactar con soporte. Quien compró un teléfono usado y fue marcado por error merece una respuesta, y puedes restablecer los bits.

¿Puedes simplemente bloquear el dispositivo?

Puedes negar tus propios extras gratuitos, y ahí es donde las marcas de dispositivo rinden. Un bloqueo total es más arriesgado. Quien tiene hoy el teléfono puede no ser quien abusó de él, y las propias condiciones de Google limitan device recall a la prevención del abuso, no al seguimiento de personas. Restringe lo que te cuesta dinero y deja abierta la vía de pago.

¿Y el Keychain (llavero) o un identificador de dispositivo?

Los desarrolladores suelen preguntar si una marca en el Keychain o un ID de hardware harían el mismo trabajo. Una marca que tu app guarda en el teléfono desaparece tras un restablecimiento del dispositivo, y Apple no da a las apps un identificador de hardware estable para esto. DeviceCheck y device recall son las respuestas avaladas por las tiendas, precisamente porque los bits están en los servidores de Apple y Google y no en el teléfono.

Dónde sigue decidiendo la tienda

Las marcas de dispositivo cambian lo que tu app regala después. No afectan al reembolso que tienes delante. Solo dos flujos de reembolso te permiten aportar pruebas antes de que la tienda decida. Apple envía un CONSUMPTION_REQUEST y pide datos de consumo en un plazo de 12 horas. Google Play abre una revisión de contracargo que respondes en 24 horas mediante orders.reviewrefund. Todo lo demás, desde los reembolsos de 48 horas de Google Play hasta los reembolsos por soporte y los reembolsos automáticos de compras no confirmadas, se decide sin ti. Los contracargos son definitivos una vez que el banco resuelve.

RefundHalt responde a cada CONSUMPTION_REQUEST y a cada revisión de contracargo de Google Play dentro de su plazo con tus datos de uso reales, y vincula cada reembolso a la cuenta que lo hizo, para que tu servidor sepa qué dispositivo marcar la próxima vez que se conecte.