Cómo proteger tu WooCommerce de cargos fraudulentos y carding

El carding es uno de los ataques más frecuentes contra tiendas WooCommerce y pasa inadvertido durante días o semanas hasta que la pasarela de pago empieza a mandar alertas de chargebacks en lote. Los bots prueban decenas de miles de números de tarjeta robados en el checkout de la tienda, en transacciones de 1-5 euros con artículos de bajo precio o importes mínimos, para verificar cuáles son válidas y cuáles no antes de usarlas para compras grandes en otras plataformas.

El coste directo para la tienda no es el euro de cada transacción de prueba: es la tasa de reversión de cargo (chargeback fee), que en Stripe es de 15 euros por chargeback aunque ganes la disputa. Si la tasa de chargebacks supera el 1% del volumen de transacciones, la pasarela puede sancionar la cuenta, reducir los límites de procesamiento, o en casos graves cerrarla. Un ataque de carding no detectado durante una semana puede generar suficientes chargebacks para poner en riesgo la capacidad de procesar pagos del negocio.

1. Cómo funciona un ataque de carding en la práctica

Los grupos de carding compran bases de datos de números de tarjeta robados en mercados del dark web. Esas bases de datos contienen millones de números, pero no todas las tarjetas son válidas: algunas han sido canceladas, algunas tienen saldo insuficiente, otras han sido marcadas como comprometidas por los bancos. El objetivo del carding es verificar cuáles funcionan todavía.

El checkout de una tienda WooCommerce es el verificador perfecto para eso: si el pago de 1 euro pasa, la tarjeta es válida y tiene fondos. Los bots usan herramientas automatizadas que pueden probar miles de tarjetas por hora, distribuyendo los intentos entre múltiples IPs para evitar el bloqueo simple por IP. Una tienda WooCommerce sin protección específica es un destino frecuente porque WordPress y WooCommerce son sistemas conocidos y las URL del checkout son predecibles.

Las señales más tempranas de un ataque activo: pico inusual de pedidos fallidos en el panel de WooCommerce, múltiples pedidos completados de importes muy bajos con emails de aspecto generado automáticamente (cadenas de caracteres aleatorios), alertas del sistema de fraude de Stripe, y en algunos casos aumento notable del tráfico en la página de checkout sin aumento correspondiente en las páginas de producto. Para tiendas con volumen bajo, incluso 50-100 intentos en un día pueden ser suficientemente visibles para detectarlos a tiempo.

2. 3D Secure 2: la primera barrera efectiva

3D Secure 2 (3DS2) añade una verificación adicional del banco emisor de la tarjeta en compras online de alto riesgo. Cuando está activo, el banco puede solicitar al comprador que confirme la transacción mediante la app del banco, un código SMS u otro método de autenticación fuerte. Para el carding, esto es efectivo porque el atacante tiene el número de tarjeta, la fecha de expiración y el CVV, pero no tiene acceso al banco del titular ni a su móvil para completar la verificación.

La versión 3DS2 (la actual, implementada en cumplimiento de PSD2 en Europa) usa autenticación adaptativa: solo activa el paso de verificación adicional cuando detecta riesgo elevado, no en todas las transacciones. Para compradores de bajo riesgo con comportamiento normal (dispositivo conocido, geolocalización consistente, historial de compras), la mayoría de transacciones pasan sin el paso adicional. Esto reduce el impacto en conversión que tenía la versión 3DS1 anterior.

Stripe aplica 3DS2 automáticamente según las reglas de PSD2 para transacciones europeas. Verifica que tu configuración no tiene el 3DS desactivado o ignorado: algunos plugins de WooCommerce de pasarela tienen opciones que permiten saltarse 3DS "para mejorar la conversión", lo que elimina esta barrera completamente. Esa configuración raramente justifica el riesgo de fraude adicional que abre.

3. Rate limiting y CAPTCHA: cortar el volumen de bots

El rate limiting en el checkout es la medida más efectiva para cortar ataques de carding de alto volumen. Si una IP intenta procesar 50 pagos en 5 minutos, es un bot: los compradores legítimos no hacen eso en ningún escenario real. Un límite de 5 intentos de pago fallidos por IP en 10 minutos con bloqueo temporal de 30 minutos corta el ataque automatizado sin afectar a compradores reales.

La implementación más robusta del rate limiting es en el WAF de Cloudflare, no a nivel de plugin de WordPress. Cloudflare opera antes de que la petición llegue al servidor, lo que significa que bloquea el tráfico de bot antes de que consuma recursos del servidor y antes de que el bot llegue siquiera al checkout. La regla se configura en Cloudflare → Firewall → Rate Limiting → Create Rate Limiting Rule, apuntando a la URL de checkout (/checkout, /wp-json/wc/ o las URL equivalentes según la configuración de la tienda).

El CAPTCHA en el formulario de pago o en el paso previo eleva el coste del ataque para el bot. Las opciones con menor impacto en compradores legítimos:

• Google reCAPTCHA v3: completamente invisible para el usuario. Opera en segundo plano analizando el comportamiento de navegación y asignando una puntuación de confianza. Si la puntuación es baja (comportamiento de bot), se puede bloquear la transacción o exigir confirmación adicional.
• Cloudflare Turnstile: alternativa a reCAPTCHA con mejor privacidad (no usa cookies de Google) y baja fricción para usuarios reales. Compatible con GDPR sin configuración adicional compleja.
• Plugin WooCommerce Anti-Fraud: analiza múltiples señales de cada pedido (país de IP vs país de tarjeta, velocidad de llenado del formulario, patrón de navegación) y asigna una puntuación de riesgo. Los pedidos de riesgo alto van a revisión manual en lugar de procesarse automáticamente.

4. Comparativa de capas de protección contra carding

5. Reglas de Stripe Radar: configuración práctica

Stripe Radar con sus reglas por defecto es un buen punto de partida, pero las reglas personalizadas son donde se consigue protección específica para el perfil de negocio de cada tienda. En Stripe Dashboard → Radar → Rules puedes crear reglas con condiciones combinadas:

Las reglas más útiles para pymes con WooCommerce: bloquear pedidos donde el país de la tarjeta es diferente al país de envío y el importe es menor de 10 euros (patrón muy habitual en carding de verificación); requerir revisión manual para el primer pedido de más de 150 euros de un cliente nuevo sin historial; bloquear tarjetas emitidas en países donde la tienda no opera y no tiene clientes históricamente; bloquear cuando la velocidad de CVC es alta (el atacante probó múltiples CVC para el mismo número de tarjeta). Las reglas se aplican de forma instantánea y pueden modificarse sin cambios en el código de la tienda.

Una precaución importante al configurar reglas de Radar: calibrar los umbrales para no generar demasiados falsos positivos. Un cliente legítimo que viaja y paga con su tarjeta española desde el extranjero puede activar la regla de país de IP diferente al país de tarjeta. Empieza con reglas en modo "Review" (no bloquean, solo marcan para revisión) antes de pasarlas a modo "Block", para verificar que no estás rechazando pedidos legítimos. La seguridad de WordPress en general, que incluye protección del admin panel que sirve de backend de WooCommerce, está cubierta en el artículo sobre cómo proteger WP-admin contra bots de fuerza bruta.

6. Caso real: 340 pedidos de carding en 6 horas

Una tienda de productos artesanales de Valladolid con WooCommerce sufrió un ataque de carding en un domingo por la tarde. La tienda no tenía ninguna protección específica: Stripe con configuración por defecto, sin CAPTCHA, sin rate limiting. El bot comenzó a probar tarjetas a las 15:30.

A las 21:45, cuando el propietario revisó el panel por la noche, encontró 340 pedidos de un artículo de 0,90 euros, con 287 en estado "failed" y 53 en estado "completed". Las 53 tarjetas verificadas habían sido usadas para compras reales en otras plataformas antes de que los bancos las cancelaran. Stripe envió alerta de tasa de fraude elevada el lunes siguiente.

El daño directo: 47,70 euros de ventas a reembolsar (los 53 completados fueron chargebacks al final), más 15 euros de tasa de chargeback por cada uno = 795 euros en tasas solo de chargebacks. Más las horas del propietario en gestionar las disputas y el riesgo real de sanción de la cuenta de Stripe. La solución implantada: Cloudflare Pro (rate limiting en la URL de checkout) + reCAPTCHA v3 de Google + activación de las reglas básicas de Radar + una regla personalizada bloqueando tarjetas de países fuera de España con importe menor a 10 euros. Un ataque similar ocurrió tres semanas después y ningún pedido fraudulento completó el proceso. Para entender las implicaciones de seguridad más amplias de WooCommerce, el artículo sobre mantenimiento y seguridad de WooCommerce cubre el conjunto de medidas de seguridad para tiendas en producción.

7. Alertas tempranas y respuesta a un ataque activo

La detección temprana de un ataque en curso es la diferencia entre mitigarlo con pocos daños y descubrirlo cuando ya hay cientos de chargebacks. Configura alertas proactivas antes de que ocurra un ataque, no después.

En Stripe: habilita las notificaciones por email o webhook de Radar cuando hay "unusual payment activity" o cuando la tasa de fallo supera el umbral configurado. En WooCommerce: el plugin WooCommerce Anti-Fraud puede enviar alertas cuando detecta pedidos de puntuación de riesgo alta. En Cloudflare: configura alertas cuando la regla de rate limiting se activa más de N veces en un periodo, lo que indica un ataque en curso.

Si detectas un ataque activo: en Cloudflare, activa temporalmente el modo "Under Attack" que añade un challenge a todos los visitantes durante la duración del ataque. En Stripe, puedes crear una regla temporal que bloquee todas las transacciones de determinados países o rangos de importe mientras dura el ataque. Notifica a Stripe del ataque: tienen equipos de respuesta al fraude que pueden ayudar con el análisis. Y revisa que los pedidos completados durante el ataque no sean tarjetas verificadas que hayan pasado: esos pedidos son fraudulentos y deben cancelarse y reembolsarse proactivamente antes de que los titulares reclamen, lo que reducirá las tasas de chargeback. Para mantener la seguridad del servidor web que aloja la tienda actualizada frente a vulnerabilidades de WordPress, el artículo sobre vulnerabilidades de plugins de WordPress cubre cómo los bots explotan plugins desactualizados para comprometer tiendas.

Por dónde empezar mañana

1. Verifica en Stripe que 3DS2 está activo y no deshabilitado: en Stripe Dashboard → Configuración → Pagos → 3D Secure. Si hay alguna opción que permite bypass de 3DS, desactivarla. Esto no requiere cambios en el código de la tienda.
2. Activa reCAPTCHA v3 o Cloudflare Turnstile en el checkout de WooCommerce: hay plugins gratuitos para integrar ambos con WooCommerce sin código. El impacto en la tasa de conversión es prácticamente nulo y la protección contra bots básicos es inmediata.
3. Configura al menos dos reglas en Stripe Radar: una que requiera revisión manual para primer pedido de más de 150 euros de cliente nuevo, y una que bloquee pedidos de menos de 5 euros de países fuera de tu mercado habitual. Empieza en modo "Review" para calibrar los umbrales durante dos semanas antes de pasar a modo "Block".

Preguntas frecuentes