Por qué reCAPTCHA v3 devuelve puntajes bajos en tu app

Alcance seguro: esta guía cubre solo tus propios entornos de QA, staging y preproducción autorizados. Trata el diagnóstico de tu integración de CAPTCHA, no de sitios de terceros.

Si tu integración de reCAPTCHA v3 recibe puntajes bajos de forma constante, la causa casi nunca es que Google te haya "detectado": suele ser configuración, sesión o cómo declaras el action. reCAPTCHA v3 no muestra un desafío; asigna un puntaje de 0.0 (tipo bot) a 1.0 (tipo humano) y tu backend lo verifica al validar el token. Cuando queda por debajo del umbral que fijaste, la solicitud se rechaza sin aviso visible. Estas son las causas más frecuentes en entornos propios y cómo aislarlas.

Por qué reCAPTCHA v3 devuelve un puntaje bajo en tu integración

Las causas que más se repiten en integraciones propias:

• Action names genéricos o inconsistentes. Si las llamadas usan submit o un action distinto al que valida el backend, el token no cuadra.
• Locale inconsistente. Un runner de CI en inglés y un test local en es-ES generan señales distintas para la misma prueba.
• Sesión que caduca. Si pides el token en la carga y envías el formulario minutos después, llega vencido.
• Varios widgets v3 en la misma página. Ejecutar v3 repetidamente en segundos baja el puntaje en cada llamada.
• Navegador dispar entre entornos. Un viewport o user-agent que cambia entre local y CI introduce varianza difícil de reproducir.

Solución de problemas

Cómo evitar puntajes bajos de reCAPTCHA v3 en QA

• Define action names limpios por funcionalidad (login, checkout_qa, signup) y valida ese valor en el backend.
• Fija umbrales por acción: no exijas 0.7 en un formulario poco crítico si 0.3 basta para tu QA.
• Solicita el token justo antes del envío, no durante la carga.
• Prevé un fallback o un reintento controlado cuando el puntaje cae, sin dar el test por fallido.
• Iguala idioma, viewport y user-agent en todos los entornos.

Iguala la configuración del navegador entre entornos

Usa la misma configuración de navegador en QA, staging y CI. Así evitas que un test funcione en local y falle en CI sin razón aparente:

from selenium import webdriver

def make_driver(headless: bool = True) -> webdriver.Chrome:
    options = webdriver.ChromeOptions()
    if headless:
        options.add_argument('--headless=new')
    options.add_argument('--window-size=1280,800')
    options.add_argument('--lang=es-ES')
    return webdriver.Chrome(options=options)

Mantener viewport, idioma y user-agent idénticos en los runners reduce la varianza entre ejecuciones.

Reproduce el flujo en tu propio staging con CaptchaAI

CaptchaAI reproduce el flujo de CAPTCHA en tu staging sin depender de tráfico de producción. Resuelve reCAPTCHA v3 en un navegador real y devuelve un token que suele puntuar alrededor de 0.3, suficiente para la mayoría de umbrales de prueba. Así validas que tu backend acepta el token y que el action coincide, igual que con un usuario real.

Cómo encaja CaptchaAI en tu pipeline propio

El patrón es siempre el mismo, sea cual sea tu framework de pruebas:

1. Tu test detecta el widget de CAPTCHA en tu propia aplicación (formulario de QA, staging o preproducción).
2. Tu test envía a CaptchaAI los datos públicos del widget (sitekey, URL de la página, tipo de CAPTCHA y el action).
3. CaptchaAI devuelve un token válido para esa página.
4. Tu test inyecta el token en el campo correspondiente y envía el formulario.
5. Tu backend verifica el token con el proveedor, como con un usuario real.

Este flujo solo aplica a integraciones que tú controlas.

Buenas prácticas y observabilidad en QA

• Prueba siempre sobre tu propia aplicación o entornos explícitamente autorizados.
• Usa una API key de CaptchaAI separada para QA, distinta de producción, para no mezclar métricas.
• Mide tiempo de resolución por intento, tasa de éxito por endpoint y distribución de errores (ERROR_*, timeouts, red) para detectar regresiones antes de producción.
• Define timeouts y reintentos con backoff exponencial, y versiona tus snapshots de configuración (sitekey, action, umbrales) junto al código de los tests.

Un escenario real: estabilizar el CI

Un equipo en Ciudad de México mantiene un portal de alta protegido con reCAPTCHA v3. En local el registro pasa siempre; en CI el mismo test falla de forma intermitente con puntajes bajo el umbral. No era "detección": el runner de CI arrancaba Chrome sin fijar idioma ni viewport. Al igualar la configuración y reproducir el flujo con CaptchaAI en staging, el equipo aisló el problema a su propio CI. El mismo patrón sirve para portales de cita previa o formularios de alta que tu organización opera y está autorizada a probar.

Preguntas frecuentes

¿Por qué el mismo test pasa en local pero falla en CI?

Casi siempre es configuración de navegador: idioma, viewport o user-agent distintos. Iguálalos en todos los runners y compara los puntajes antes de asumir que hay "detección".

¿Esta guía sirve para sitios de terceros?

No. Está pensada para tu propia aplicación o entornos de QA, staging y preproducción autorizados. Resolver CAPTCHA en sitios que no controlas puede infringir sus términos de servicio.

¿Qué tipos de CAPTCHA puedo resolver en mi pipeline de QA?

CaptchaAI resuelve reCAPTCHA v2 y v3, Cloudflare Turnstile y Challenge, GeeTest v3, imagen/OCR, grid y BLS; CaptchaFox, Friendly Captcha y Lemin están en beta. hCaptcha y FunCaptcha no son compatibles por ahora.

Guías relacionadas seguras

• Inicio rápido de CaptchaAI
• QA de CAPTCHA en entornos autorizados
• Probar endpoints de CAPTCHA en formularios propios
• Depurar tests de navegador cuando la API sí funciona
• Resolver reCAPTCHA v2 con la API
• Resolver Cloudflare Turnstile con la API

Valida tus integraciones de CAPTCHA en entornos propios con CaptchaAI.