¿Tu checkout deja pasar los pedidos legítimos cuando el CAPTCHA se activa bajo carga? La forma de comprobarlo antes de un lanzamiento es automatizar la verificación del CAPTCHA contra tu propio entorno de staging. Con CaptchaAI generas tokens válidos de reCAPTCHA v2, reCAPTCHA v3 y Cloudflare Turnstile, los inyectas en tu formulario de pago y confirmas que tu backend los acepta igual que con un cliente real. Así descubres una integración rota —una sitekey mal configurada, un action equivocado, un token que caduca— en QA y no el día del lanzamiento.
Esto es especialmente útil si desarrollas el checkout de una tienda propia en Shopify o una integración a medida para el mercado español o latinoamericano. El coste mensual predecible en USD encaja bien con agencias y freelancers que facturan en monedas volátiles: un plan como BASIC ($15/mes, 5 threads) suele bastar para una suite de QA en CI.
Nota: los ejemplos asumen que pruebas contra tu propio staging o contra sistemas para los que tienes autorización explícita. No apliques estas técnicas contra sitios de terceros.
Qué tipos de CAPTCHA aparecen en un checkout
El punto de activación y la complejidad varían según el tipo. Conviene mapearlos antes del primer test:
| Tipo de CAPTCHA | Punto de activación habitual | Complejidad de integración |
|---|---|---|
| reCAPTCHA v3 | Inicio de sesión, envío de formulario | Alta (umbral de puntuación configurable) |
| reCAPTCHA v2 (casilla) | Añadir al carrito, validación final de prueba | Media |
| Cloudflare Turnstile | Acceso a página, checkout | Media |
| reCAPTCHA v2 Invisible | Envío de formulario | Alta |
Validar reCAPTCHA v2 en tu entorno de staging
Empieza por el caso más común, la casilla de reCAPTCHA v2: envía la sitekey y la URL a CaptchaAI y sondea hasta obtener el token.
import requests
import time
CAPTCHAAI_KEY = "YOUR_API_KEY"
CAPTCHAAI_URL = "https://ocr.captchaai.com"
STAGING_SITEKEY = "6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI" # sitekey de prueba de Google
STAGING_URL = "https://staging.tu-tienda.com/checkout"
def solve_recaptcha_v2(sitekey: str, pageurl: str) -> str:
resp = requests.post(f"{CAPTCHAAI_URL}/in.php", data={
"key": CAPTCHAAI_KEY,
"method": "userrecaptcha",
"googlekey": sitekey,
"pageurl": pageurl,
"json": 1,
})
resp.raise_for_status()
task_id = resp.json()["request"]
for _ in range(60):
time.sleep(5)
result = requests.get(f"{CAPTCHAAI_URL}/res.php", params={
"key": CAPTCHAAI_KEY, "action": "get",
"id": task_id, "json": 1,
})
data = result.json()
if data["request"] != "CAPCHA_NOT_READY":
return data["request"]
raise TimeoutError("Tiempo de espera agotado para resolver CAPTCHA")
token = solve_recaptcha_v2(STAGING_SITEKEY, STAGING_URL)
print(f"Token obtenido: {token[:40]}...")
Resolver reCAPTCHA v3 con un umbral de puntuación
reCAPTCHA v3 no muestra casilla: devuelve una puntuación y tu backend decide el umbral. Pasa el parámetro action que espera tu formulario.
def solve_recaptcha_v3(sitekey: str, pageurl: str, action: str = "checkout",
"""Resolver reCAPTCHA v3 solicitando puntuación mínima para staging."""
resp = requests.post(f"{CAPTCHAAI_URL}/in.php", data={
"key": CAPTCHAAI_KEY,
"method": "userrecaptcha",
"version": "v3",
"googlekey": sitekey,
"pageurl": pageurl,
"action": action,
"json": 1,
})
resp.raise_for_status()
task_id = resp.json()["request"]
for _ in range(40):
time.sleep(5)
result = requests.get(f"{CAPTCHAAI_URL}/res.php", params={
"key": CAPTCHAAI_KEY, "action": "get",
"id": task_id, "json": 1,
})
data = result.json()
if data["request"] != "CAPCHA_NOT_READY":
return data["request"]
raise TimeoutError("Tiempo de espera agotado para resolver reCAPTCHA v3")
Prueba de extremo a extremo del flujo de checkout
Encadena los solvers en un test que recorra el flujo completo: cargar la página, resolver el CAPTCHA, inyectar el token en g-recaptcha-response y comprobar la respuesta del backend.
def test_checkout_flow(staging_base_url: str, sitekey: str) -> dict:
"""Prueba completa del flujo de checkout con CAPTCHA en staging."""
session = requests.Session()
# Paso 1: Cargar página de checkout
resp = session.get(f"{staging_base_url}/checkout")
assert resp.status_code == 200, f"Error al cargar checkout: {resp.status_code}"
# Paso 2: Resolver CAPTCHA
token = solve_recaptcha_v2(sitekey, f"{staging_base_url}/checkout")
# Paso 3: Enviar formulario con token
resp = session.post(f"{staging_base_url}/checkout/submit", data={
"g-recaptcha-response": token,
"test_item": "product-staging-001",
"quantity": 1,
})
return {
"status_code": resp.status_code,
"success": resp.status_code == 200,
"response": resp.json() if resp.headers.get("content-type", "").startswith("application/json") else resp.text[:200],
}
# Ejecutar prueba
result = test_checkout_flow("https://staging.tu-tienda.com", STAGING_SITEKEY)
print(f"Resultado: {result}")
Configuración de navegador reproducible entre entornos
Usa exactamente la misma configuración de navegador en todos tus entornos de QA, staging y CI. Así evitas que un test funcione en local y falle en CI sin motivo 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 el viewport, el idioma y el user-agent idénticos en todos los runners reduce la varianza entre ejecuciones.
Cómo encaja CaptchaAI en tu pipeline de pruebas
El patrón de integración es siempre el mismo, sin importar el framework de pruebas que uses:
- Tu test detecta el widget de CAPTCHA en la página de tu propia aplicación (formulario de QA, landing de staging, endpoint de preproducción).
- Tu test envía a CaptchaAI los datos públicos del widget (
sitekey, URL de la página, tipo de CAPTCHA). - CaptchaAI devuelve un token válido para esa página.
- Tu test inyecta ese token en el campo correspondiente y envía el formulario.
- Tu backend verifica el token con el proveedor del CAPTCHA, igual que con un usuario real.
Este flujo se aplica solo a integraciones que tú controlas; no sirve para sortear las protecciones de sitios de terceros.
Qué métricas vigilar en tu QA de CAPTCHA
Instrumenta métricas para los pasos del CAPTCHA en tus pipelines de QA y detecta regresiones antes de que lleguen a producción:
- Tiempo de resolución por intento — desde la solicitud a CaptchaAI hasta la entrega del token.
- Tasa de éxito por endpoint propio — verificaciones del backend que pasan respecto al total.
- Distribución de errores — agrupados por código (
ERROR_*, timeouts internos, fallos de red). - Latencia de extremo a extremo — render de la página, resolución del CAPTCHA y respuesta del backend.
Conserva las trazas (logs, capturas, HAR) para reproducir incidentes cuando un test falle de forma intermitente.
Errores frecuentes al validar el checkout
| Problema | Causa probable | Solución |
|---|---|---|
| Token rechazado al enviar formulario | Token caducado (>120 s) | Resolver el CAPTCHA inmediatamente antes de enviar |
ERROR_ZERO_BALANCE |
Saldo de cuenta agotado | Recargar crédito en captchaai.com/account |
| Tiempo de espera agotado | Alta demanda en el servidor de resolución | Aumentar el número de reintentos y el tiempo de espera |
ERROR_WRONG_GOOGLEKEY |
Sitekey incorrecta | Verificar la sitekey en el HTML de la página |
| Token válido pero el formulario lo rechaza | El backend valida IP o action incorrecta |
Revisar el parámetro action y la configuración del backend |
Buenas prácticas para tu entorno de QA
- Prueba siempre sobre tu propia aplicación o sobre entornos explícitamente autorizados.
- Mantén una API key de CaptchaAI separada para QA, distinta de la de producción, para no mezclar métricas.
- Define timeouts y reintentos razonables (
backoffexponencial) para no acumular trabajos pendientes durante caídas. - Versiona tus snapshots de configuración (
sitekey,action, umbrales) junto al código de los tests. - Revisa el changelog de tu proveedor de CAPTCHA para anticipar cambios que afecten a tu integración.
Preguntas frecuentes
¿Qué sitekey debo usar para probar el CAPTCHA en staging?
Usa la sitekey configurada en tu propio entorno de staging. Para una prueba de integración básica puedes recurrir a la sitekey de prueba pública de Google (6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI), que siempre devuelve un token válido.
¿Puedo reutilizar el mismo token en varias ejecuciones de prueba?
No. Cada token es de un solo uso. Solicita uno nuevo en cada ejecución, justo antes de enviar el formulario, para que no caduque en el camino.
¿Cómo pruebo Cloudflare Turnstile en mi entorno de staging?
Configura la sitekey de prueba de Cloudflare (1x00000000000000000000AA) en tu staging. CaptchaAI resuelve Turnstile con el método turnstile, con el mismo patrón de envío y sondeo que reCAPTCHA.
¿Qué plan de CaptchaAI necesito para una suite de QA?
Depende de cuántas resoluciones simultáneas lance tu CI. Para una suite que corre en serie, BASIC ($15/mes, 5 threads) basta; si paralelizas muchos tests, sube a STANDARD ($30/mes, 15 threads). Consulta los precios en captchaai.com/pricing.
Guías relacionadas
- Inicio rápido de CaptchaAI
- Cómo resolver reCAPTCHA v2 con la API
- Cómo resolver Cloudflare Turnstile con la API
Integra CaptchaAI en tus pruebas de checkout y valida tu flujo de pago antes de cada lanzamiento. Obtén tu API key de CaptchaAI.