Abres WooCommerce y encuentras algo extraño: varios pedidos fallidos que nadie reconoce. Quizá todos intentan comprar el producto más barato de la tienda. Puede que aparezcan uno detrás de otro, con nombres y direcciones diferentes, o que lleves horas recibiendo avisos de pagos rechazados.
La primera reacción suele ser pensar que el checkout se ha roto o que alguien ha hackeado WordPress.
Puede ser un problema técnico, pero existe otra posibilidad que conviene descartar pronto: que estén utilizando tu tienda para realizar card testing, es decir, probar automáticamente datos de tarjetas para comprobar cuáles permiten realizar un pago.
WooCommerce identifica precisamente como una señal habitual de estos ataques un aumento repentino de pedidos en estado Fallido, normalmente asociado a muchos intentos de pago en poco tiempo. Puedes consultar su documentación sobre ataques de card testing.
Esto no significa que cualquier pedido fallido sea fraudulento.
Un cliente real puede equivocarse al introducir una tarjeta, utilizar una tarjeta caducada, quedarse sin fondos o sufrir un rechazo del banco. WooCommerce documenta diferentes causas legítimas por las que un pago puede fallar.
La clave está en el patrón.
En un ataque de card testing, alguien dispone de datos de tarjetas obtenidos fuera de tu tienda y necesita averiguar cuáles continúan siendo válidos.
Para comprobarlo puede automatizar pequeñas compras contra comercios reales. Si una operación se autoriza, obtiene una señal de que esas credenciales de pago funcionan.
Por eso el objetivo inicial no tiene por qué ser comprarte nada.
Tu checkout se está utilizando como mecanismo de comprobación.
WooCommerce explica que estos ataques suelen implicar muchas transacciones pequeñas con tarjetas diferentes y que pueden provocar costes, disputas y un aumento de los pagos rechazados.
Es importante entender también lo que no demuestra este comportamiento.
Que alguien pueda intentar pagar en tu checkout no significa, por sí solo, que haya conseguido entrar en WordPress, modificar archivos o acceder a la base de datos. Un checkout público está diseñado precisamente para que personas que no tienen acceso administrativo puedan enviar pedidos y pagos.
Por tanto, card testing contra tu tienda no equivale automáticamente a WordPress hackeado.
Si además encuentras administradores desconocidos, plugins que no reconoces, archivos modificados, redirecciones extrañas o contenido que no has publicado, entonces sí debes investigar un posible compromiso de la instalación. En ese escenario puedes continuar con nuestra guía sobre WordPress hackeado aunque estaba actualizado: cómo puede pasar y qué comprobar.
No conviene diagnosticar un ataque mirando un único pedido.
Busca coincidencias entre varios intentos:
| Lo que observas | Qué puede indicar |
|---|---|
| Un pago aislado rechazado | Puede ser completamente normal |
| Muchos pedidos fallidos en pocos minutos u horas | Requiere investigación |
| Distintos clientes intentando comprar repetidamente el mismo artículo barato | Patrón compatible con card testing |
| Numerosas tarjetas rechazadas | Señal especialmente relevante |
| Los intentos continúan aunque cambien nombres, emails o direcciones | Compatible con automatización |
| Una o varias operaciones sospechosas sí se cobran | Hay que revisar las transacciones con urgencia |
| Clientes reales también informan de que no pueden pagar | Puede existir además un problema técnico en el checkout |
El último punto es importante.
No confundas automáticamente una oleada de pedidos fallidos provocada por bots con un checkout averiado.
Pero tampoco hagas lo contrario.
Si clientes reales están intentando comprar y sus pagos legítimos fallan, hay que investigar el funcionamiento del proceso de compra. En nuestra guía sobre qué comprobar cuando el checkout de WooCommerce no funciona explicamos cómo separar problemas del método de pago, plugins, errores, registros y configuración.
Un patrón frecuente consiste en encontrar muchos intentos contra un producto económico, una donación o un artículo cuyo precio puede establecer el comprador.
Tiene sentido desde el punto de vista del atacante.
Si solo necesita comprobar si una tarjeta acepta un cargo, una operación pequeña resulta menos llamativa que una compra grande.
La propia documentación de WooCommerce señala los productos económicos y, especialmente, las donaciones o productos del tipo “paga lo que quieras” sin un mínimo como objetivos que pueden resultar atractivos para estos ataques.
Eso explica también una situación desconcertante: retirar el artículo atacado y empezar a ver los intentos sobre otro producto.
Ocultar temporalmente el producto puede ser una medida de contención, pero no corrige por sí sola el problema.
WooCommerce contempla hacer temporalmente privado un producto especialmente utilizado durante un ataque activo, pero lo combina con medidas de protección del checkout y del sistema de pagos.
Si el atacante puede seguir enviando operaciones utilizando otro artículo, el vector continúa abierto.
Sí, aunque eso no significa que debas asumir que la tienda está comprometida.
Que los intentos fallen es mejor que ver decenas de operaciones fraudulentas aceptadas, pero sigue existiendo un problema que merece atención.
WooCommerce advierte de posibles efectos como un incremento de disputas y de la tasa de rechazos. Los intentos automatizados también pueden generar cientos de pedidos, notificaciones y peticiones contra la tienda.
Y queda otro riesgo evidente: que alguna de las tarjetas termine siendo aceptada.
Por eso la pregunta importante no es únicamente:
“¿Cuántos pedidos han fallado?”
También debes comprobar:
“¿Alguna de estas operaciones sospechosas ha llegado a cobrarse?”
No instales tres plugins de seguridad, bloquees países enteros y cambies la configuración del checkout al mismo tiempo.
Primero recoge información.
Abre varios de los pedidos afectados y compara el momento en que se produjeron, el producto comprado, el método de pago, el estado del pedido y las notas que WooCommerce ha añadido.
Las notas del pedido son especialmente útiles porque pueden contener el resultado comunicado por la pasarela: rechazo, error de autenticación, problema con la tarjeta u otro motivo. WooCommerce recomienda revisar precisamente esas notas y, cuando sea necesario, los registros del método de pago para diagnosticar qué ha ocurrido con un pedido.
Después entra también en el panel de tu proveedor de pagos.
WooCommerce te muestra lo que ha ocurrido desde el punto de vista de la tienda. El proveedor de pagos dispone de la información de la transacción procesada por su sistema.
Compara ambos lados.
Si WooCommerce muestra una operación sospechosa como pagada, confirma en la pasarela si existe realmente un cargo o una autorización antes de tomar decisiones.
Esta comprobación evita otro error: asumir que cualquier pedido visible en WordPress corresponde necesariamente a dinero cobrado.
Este es el punto que requiere mayor rapidez.
Si una operación que consideras fraudulenta ha sido aceptada, no prepares ni envíes el pedido como si fuese una venta normal.
Comprueba la transacción en el proveedor de pagos y sigue su procedimiento para operaciones no autorizadas.
WooCommerce recomienda revisar las transacciones y reembolsar con urgencia aquellas que se consideren fraudulentas, precisamente para reducir el riesgo de que posteriormente se conviertan en disputas. También advierte de que las comisiones de la operación pueden no devolverse automáticamente al realizar el reembolso; eso depende del proveedor de pagos.
Si utilizas WooPayments existe además documentación específica para incidentes de card testing.
No borres los pedidos sospechosos antes de haber terminado esta revisión.
Los pedidos, las notas, las horas de los intentos y los identificadores de las transacciones pueden ser precisamente la información que necesites para reconstruir lo ocurrido o pedir ayuda al proveedor.
No existe una única protección que tenga sentido para todas las tiendas.
El checkout puede ser clásico o estar basado en bloques. Una tienda puede utilizar WooPayments, Stripe, PayPal u otra pasarela. Algunas pasan por Cloudflare y otras no. También cambian enormemente los patrones normales de venta.
Por eso resulta más útil trabajar por capas.
Tu pasarela es una pieza fundamental porque es quien procesa las operaciones.
Revisa qué mecanismos antifraude tiene activados, qué información proporciona sobre los rechazos y qué recomienda específicamente cuando detectas card testing.
WooCommerce aconseja contactar con el proveedor de pagos para revisar o reforzar sus medidas antifraude cuando se produce un ataque.
Si utilizas WooPayments, el servicio incorpora prevención de fraude apoyada en Stripe Radar y dispone además de reglas de prevención del fraude. Ningún sistema garantiza detectar todo el fraude.
Evita copiar unas reglas pensadas para otra tienda sin considerar cómo compran tus clientes.
Una regla demasiado agresiva también puede rechazar ventas legítimas.
Muchos ataques de card testing están automatizados.
Por eso WooCommerce propone mecanismos de detección de bots como CAPTCHA o Cloudflare Turnstile entre las posibles capas de protección del checkout.
Esto no significa que cualquier tienda deba instalar inmediatamente el primer plugin CAPTCHA que encuentre.
La protección tiene que funcionar en tu checkout real.
Comprueba especialmente que sea compatible con el checkout clásico o con Checkout Blocks, que proteja el punto por el que están entrando realmente los intentos y que no interfiera con tus métodos de pago.
Después realiza compras de prueba.
WooCommerce dispone de rate limiting para su Store API.
En las versiones que incluyen el control desde la interfaz, puede activarse desde:
WooCommerce → Ajustes → Avanzado → Funciones → Rate limiting Checkout block and Store API
Cuando se activa desde esta opción, WooCommerce aplica el límite al proceso de realizar el pedido del Checkout Block y al POST /checkout, con un máximo documentado de tres solicitudes por 60 segundos. Los detalles técnicos están en la documentación de rate limiting de la Store API.
Hay dos matices importantes.
El primero es que esta protección está relacionada con Checkout Blocks y la Store API. No debes asumir que activar esa opción protege cualquier posible proceso de pago de cualquier tienda WooCommerce.
El segundo es que una tienda situada detrás de un proxy, balanceador, CDN o firewall puede necesitar que la identificación del cliente esté configurada correctamente. WooCommerce contempla específicamente soporte para proxies porque aplicar límites utilizando una dirección incorrecta podría afectar a usuarios legítimos.
Si no sabes si tu tienda utiliza checkout clásico o Checkout Blocks, puedes comprobarlo antes de tocar nada en nuestra guía sobre qué revisar antes de cambiar al checkout por bloques de WooCommerce.
Si utilizas un servicio como Cloudflare, un WAF puede filtrar o limitar determinados tipos de tráfico antes de que lleguen a WordPress.
Cloudflare permite crear reglas de rate limiting para limitar solicitudes contra determinados recursos y utiliza su WAF y sus sistemas de detección de bots como capas distintas de protección.
Pero “pon Cloudflare” tampoco es una solución completa al card testing.
Una regla tiene que saber qué tráfico pretende limitar y diferenciarlo suficientemente bien del que generan compradores reales.
Bloquear indiscriminadamente por país, IP o ruta puede ser ineficaz si el atacante cambia sus características y, al mismo tiempo, puede impedir comprar a clientes válidos.
El WAF debe complementar la protección del checkout y de la pasarela, no sustituirlas.
A veces puede detener un origen muy evidente.
Como estrategia general tiene limitaciones importantes.
Los ataques automatizados pueden utilizar múltiples direcciones, cambiar de red o variar otros datos. WooCommerce permite precisamente que determinados mecanismos avanzados de limitación agrupen solicitudes mediante señales distintas de una IP simple.
Por eso no conviene interpretar:
“He bloqueado tres IP y han dejado de aparecer pedidos durante una hora”
como:
“El problema está resuelto”.
Lo que importa es comprobar si han cesado los intentos, si el checkout continúa funcionando para clientes reales y si la pasarela ya no registra la actividad sospechosa.
Solo cuando dispongas de un patrón suficientemente claro y tenga sentido para tu negocio.
Un dominio de correo gratuito, una determinada localización o una dirección IP son señales, no demostraciones de fraude.
Las herramientas antifraude pueden combinar diferentes indicadores precisamente porque una sola característica genera falsos positivos con facilidad.
Si tu empresa vende internacionalmente, bloquear un país porque varios intentos fraudulentos parecen proceder de allí puede eliminar también compradores legítimos.
Si solo vendes en una zona muy concreta, el análisis será diferente.
Las reglas deben partir de cómo funciona realmente tu tienda.
Puede ser una medida adicional en determinados ataques.
WooCommerce la menciona expresamente entre las opciones que un comercio puede considerar cuando está sufriendo card testing.
Pero tiene un coste empresarial evidente: obligar a crear una cuenta puede reducir la comodidad del proceso de compra.
No lo convertiría en la primera solución universal.
Si se utiliza durante una incidencia, debería hacerse sabiendo por qué, comprobar si realmente reduce los intentos y decidir después si tiene sentido mantener esa restricción.
Después de modificar reglas antifraude, añadir un CAPTCHA o tocar el checkout hay que comprobar que un cliente legítimo todavía puede comprar.
Hazlo utilizando el modo de pruebas o sandbox de la pasarela cuando esté disponible.
WooCommerce recomienda realizar este tipo de pruebas en modo de test y, cuando la intervención pueda afectar a otras partes de la tienda, trabajar en un entorno de staging. Puedes consultar su documentación sobre cómo probar pedidos en WooCommerce.
Esto es especialmente importante cuando tienes varias formas de pago.
Que funcione una no demuestra que sigan funcionando las demás.
Si descubres una oleada de pedidos sospechosos, este orden permite contener el problema sin empezar modificando la tienda a ciegas:
Una oleada de intentos puede inundar el correo del negocio con mensajes de pedidos fallidos.
No desactives todas las notificaciones simplemente para dejar de verlos.
El ruido es molesto, pero también puede estar avisándote de que la actividad continúa.
Si, además del ataque, detectas que las notificaciones de pedidos no se generan correctamente o algunos emails han dejado de llegar, trátalo como una incidencia diferente. Nuestra guía sobre WooCommerce no envía correos de pedidos explica cómo distinguir un problema de generación del email, de envío y de entrega.
No mezcles ambos diagnósticos.
“Estoy recibiendo demasiados emails de pedidos fraudulentos” y “WooCommerce no envía correctamente sus emails” son dos problemas diferentes.
No por el simple hecho de haber recibido pedidos fraudulentos.
El card testing puede realizarse contra un checkout público sin necesidad de comprometer WordPress.
Busca evidencias independientes de una intrusión.
Por ejemplo, administradores que nadie reconoce, plugins o temas desconocidos, cambios no autorizados, redirecciones, archivos alterados, páginas de spam o comportamiento extraño fuera del checkout.
Si existen estos indicadores, entonces ya no estás investigando únicamente fraude contra el sistema de pagos.
Estás ante una posible incidencia de seguridad de WordPress que requiere otro tipo de diagnóstico.
No tiene sentido realizar una “limpieza de malware” solo para tranquilizarse si no hay ninguna evidencia de malware. Y tampoco tiene sentido asumir que todo está bien únicamente porque hayas frenado los pedidos falsos si simultáneamente existen señales de compromiso.
Cuando el problema afecta a su capa o necesitas información que solo él puede proporcionar.
Por ejemplo, puede ser útil si existe una carga anormal del servidor, necesitas revisar determinados registros, el hosting incluye un WAF o sistema de mitigación o sospechas que la cantidad de tráfico está afectando al funcionamiento de la tienda.
Pero el hosting no sustituye al proveedor de pagos.
El alojamiento puede ver tráfico y recursos del servidor. La pasarela puede ver autorizaciones, rechazos y señales relacionadas con los pagos.
En un incidente de card testing puedes necesitar información de ambos.
No hace falta escalar cada pago fallido.
Sí merece una revisión más profunda cuando recibes una cantidad anormal de intentos durante horas, existen transacciones fraudulentas aceptadas, no sabes qué endpoint o checkout están explotando, las medidas aplicadas no reducen el ataque, el checkout empieza a fallar para clientes reales o aparecen señales adicionales de que WordPress puede estar comprometido.
También conviene pedir ayuda antes de experimentar en producción si nadie sabe qué protecciones tiene actualmente la tienda.
En una instalación con varios métodos de pago, checkout personalizado, Cloudflare, reglas antifraude, plugins de seguridad e integraciones externas, añadir otra capa sin entender las anteriores puede introducir un problema nuevo.
Si tu tienda necesita una revisión continuada de pagos, actualizaciones, seguridad y procesos críticos, nuestro servicio de mantenimiento WordPress para empresas y profesionales contempla también tiendas WooCommerce y soporte ante incidencias.
Detener los pedidos sospechosos no es el último paso.
Comprueba el recorrido de una compra legítima de principio a fin.
El producto debe poder añadirse al carrito, el checkout debe aceptar los datos, cada método de pago importante debe funcionar, el pedido debe crearse con el estado esperado, las notificaciones deben generarse y cualquier integración posterior debe seguir recibiendo la información necesaria.
No sirve de mucho detener un bot si la regla utilizada también impide comprar a parte de tus clientes.
Después revisa durante unos días los pedidos fallidos y los registros de la pasarela.
El objetivo no es conseguir que WooCommerce no vuelva a mostrar nunca un pago rechazado.
Los pagos legítimos también fallan.
El objetivo es volver a un comportamiento normal para tu tienda, poder reconocer rápidamente otro pico anómalo y disponer de varias capas de protección que no interfieran con las ventas reales.
Encontrar muchos pedidos fallidos no demuestra por sí solo que WooCommerce esté roto ni que WordPress haya sido hackeado.
Puede ser card testing.
La diferencia aparece al reconstruir el patrón: cuántos intentos se producen, en qué intervalo, qué productos utilizan, qué registra el método de pago y si alguna operación llega a autorizarse.
A partir de ahí sí puedes actuar con criterio.
Primero revisa las transacciones.
Después protege el checkout mediante las herramientas que correspondan a tu configuración: medidas del proveedor de pagos, controles antifraude, detección de bots, rate limiting o protección en el WAF.
Y después de cada cambio comprueba lo más importante: que los intentos fraudulentos disminuyan sin impedir que los clientes reales sigan comprando.
