Los pedidos falsos son uno de los problemas más frustrantes a los que se enfrenta un propietario de tienda WooCommerce. Bots que colocan cientos de pedidos fraudulentos, ataques de card-testing que vacían las comisiones del gateway, y clientes fantasma atascando tu listado de pedidos. Recientemente lidiamos con una oleada persistente de pedidos falsos en la tienda de un cliente — y ganamos. Aquí está todo lo que aprendimos.
El problema: bots que no paran
Nuestro cliente, un minorista de equipamiento comercial, empezó a detectar un patrón: pedidos desde orígenes desconocidos, a menudo por importes específicos, realizados con correos que no se correspondían con ningún cliente real. Los pedidos o bien fallaban en la pasarela de pago (card-testing) o se colaban con datos de tarjeta robados.
La instalación estándar de WooCommerce apenas tiene protección integrada contra esto. Las pasarelas de pago detectan algunas tarjetas malas, pero para entonces ya has pagado comisiones y tu listado de pedidos es un caos.
Capa 1: Bloquear a los reincidentes conocidos en el checkout
La primera y más eficaz capa es detener a los estafadores conocidos antes de que hagan siquiera un pedido. Eso significa mantener listas negras de:
- Direcciones de correo — direcciones o patrones concretos que han aparecido en fraudes
- Direcciones IP — admite IPs individuales y rangos CIDR (p. ej.,
192.168.1.0/24) - Números de teléfono — con soporte de comodines para bloquear prefijos enteros
Estas comprobaciones se ejecutan durante la validación del checkout de WooCommerce — el pedido se rechaza con un mensaje genérico de «motivos de seguridad» antes de intentar siquiera el pago. El cliente nunca sabe qué comprobación lo atrapó, lo que dificulta que los bots se adapten.
Capa 2: Análisis de fraude post-pago
Algunas comprobaciones no se pueden ejecutar en el checkout sin causar falsos positivos. La más importante: origen de pedido desconocido.
WooCommerce sigue el origen de los pedidos mediante una cookie de atribución. Los pedidos realizados a través del flujo normal de checkout se etiquetan con una fuente. Los pedidos colocados por bots suelen aparecer como «unknown» porque los bots no ejecutan el JavaScript que establece esa cookie.
Lección crítica: inicialmente bloqueamos los pedidos con origen desconocido en el checkout. Esto provocó de inmediato que se bloqueara a clientes legítimos — cualquiera que usara Safari con ITP (Intelligent Tracking Prevention), extensiones centradas en la privacidad o sitios con caché agresivo perdía la cookie de atribución. La solución: comprobar el origen solo después del pago y marcar el pedido para revisión en lugar de bloquear al cliente por completo.
El análisis post-pago revisa todo: origen, importes sospechosos, listas negras, detección de proxy y tasas de repetición de IP. Los pedidos sospechosos se mueven automáticamente a un estado personalizado «Fraude — cancelado automáticamente» y disparan un aviso por correo al administrador de la tienda.
Capa 3: Capturar también los pedidos fallidos
Hay algo fácil de pasar por alto: los pedidos de card-testing de los bots siempre fallan en la pasarela de pago. El bot envía números de tarjeta robados para ver cuáles son válidos. La pasarela rechaza la mayoría, así que el pedido acaba en estado «Failed».
¿El problema? Los pedidos fallidos nunca llegan a la página de agradecimiento, así que tu detección de fraude post-pago no se dispara. Tu detección de fraude está completamente ciega a esos pedidos.
La solución: engancharse a las transiciones de estado «Failed» y «Cancelled» — pero solo para pedidos realizados vía Store API. ¿Por qué la distinción? Los clientes legítimos cuya tarjeta es rechazada volverán a intentarlo, a menudo varias veces desde la misma IP. Si analizas todos los pedidos fallidos, esos reintentos disparan tu detección de repetición por IP y, de repente, un cliente real queda marcado como fraude. Al limitar el análisis de pedidos fallidos a los de la Store API (canal que los clientes legítimos del checkout clásico nunca producen), atrapas a los bots sin castigar a personas reales por tener un mal día con su tarjeta.
Capa 4: Endurecer la REST API
Esta fue la mayor lección de todas. El WooCommerce moderno utiliza la Store API para su Block Checkout. Es un endpoint REST público que acepta envíos de pedidos — y los bots se dieron cuenta de que podían hacer POST directamente a ella, saltándose por completo tu página de checkout.
La solución: interceptar las peticiones a la REST API y bloquear los intentos de creación de pedidos no autenticados. Pero hay que ser inteligente respecto a qué se permite:
- Usuarios administradores con capacidad de gestión de WooCommerce — siempre permitidos
- Autenticación con claves API de WooCommerce — para integraciones de terceros
- Autenticación OAuth/Bearer token — para apps móviles y servicios externos
- Nonce válido de la Store API — así es como funciona el Block Checkout legítimo
La trampa del nonce
Esto es crítico y merece su propia sección. Cuando implementamos por primera vez el endurecimiento REST, verificábamos los nonces de forma estricta con la verificación de nonces de WordPress. Luego nos preocuparon los casos límite y lo relajamos a una mera comprobación de presencia — simplemente verificar que exista una cabecera nonce, sin validarla.
En cuestión de horas, los bots se adaptaron. Empezaron a enviar peticiones con una cabecera nonce falsa con valores basura. Nuestra comprobación de solo presencia les dejó pasar directamente.
Lección aprendida: verifica siempre los nonces de forma estricta. El Block Checkout legítimo siempre tiene un nonce válido porque el JavaScript de WooCommerce lo genera de forma fresca en cada carga de página. Los bots pueden falsificar cabeceras, pero no pueden falsificar nonces válidos de WordPress — necesitarían ejecutar JavaScript en tu propio sitio para obtenerlos.
Capa 5: Límite de frecuencia por IP
Incluso con todo lo anterior, un atacante decidido puede rotar correos y detalles. Lo que no pueden rotar fácilmente es su dirección IP (o al menos su pool de IPs es limitado). Hacer seguimiento de pedidos por IP dentro de una ventana de tiempo configurable añade otra red de seguridad.
Si la misma IP hace más de X pedidos en Y minutos, todos los pedidos posteriores desde esa IP quedan marcados. Esto captura el patrón de tiro rápido que usan los bots de card-testing.
Hacerlo manejable: la experiencia del administrador
Todo esto es inútil si el administrador de la tienda no puede ver lo que está pasando. Algunas cosas que marcaron la diferencia:
- Filtro de estado de pedido personalizado — Una pestaña «Fraude» en la lista de pedidos, justo al lado de Procesando, Completado y Cancelado. Un clic para ver todos los pedidos marcados.
- Alertas por correo — Notificación instantánea cuando se detecta un pedido sospechoso, con detalles del pedido, información de facturación y los indicadores concretos que lo dispararon.
- Interruptores configurables — Cada regla de detección puede activarse o desactivarse de forma independiente. El endurecimiento REST tiene su propio interruptor. Esto permite afinar el equilibrio adecuado para cada tienda.
Lo que hicimos mal por el camino
La transparencia importa. Estos son los errores que cometimos para que usted no tenga que repetirlos:
- Bloquear el origen desconocido en el checkout — Provocó falsos positivos con usuarios de Safari y cualquiera con extensiones de privacidad. Pasamos a comprobarlo solo post-pago.
- Relajar la verificación de nonces — Los bots explotaron de inmediato la comprobación de solo presencia. Nunca comprometa la validación de nonces.
- Asumir que los pedidos fallidos no importan — Los bots de card-testing generan cientos de pedidos fallidos que eran invisibles a nuestras comprobaciones. Hay que analizar los pedidos fallidos — pero de forma selectiva (ver el siguiente punto).
- Analizar todos los pedidos fallidos de la misma manera — Nuestra solución inicial aplicaba cada comprobación a todos los pedidos fallidos. Eso atrapaba bots, pero también a clientes legítimos que reintentaban tras una tarjeta denegada. Varios reintentos desde la misma IP disparaban nuestro límite de frecuencia, y clientes reales empezaron a aparecer en el informe de «correos de fraude más frecuentes». La solución: ejecutar el análisis de fraude solo en los pedidos fallidos llegados por la Store API — el canal que usan los bots. Los pedidos fallidos de la página de checkout normal se dejan en paz.
- HTML en correos de texto plano — Las funciones de formato de precio de WooCommerce devuelven HTML con etiquetas
<span>. En un correo de texto plano, eso queda ilegible. Retire siempre el HTML cuando construya contenido de texto plano.
Los resultados
Tras implementar las cinco capas, la tienda pasó de decenas de pedidos falsos al día a cero. Los clientes legítimos no se vieron afectados — la única comprobación que podía causar falsos positivos (origen desconocido) se ejecuta post-pago y marca para revisión en lugar de bloquear.
La conclusión clave: ninguna comprobación por sí sola basta. Los bots se adaptan. Lo que los detiene es una defensa por capas — cada capa atrapa lo que las otras pasan por alto. Las listas negras detienen a los reincidentes conocidos. El análisis post-pago atrapa patrones nuevos. El endurecimiento REST bloquea el vector de abuso de la API. El límite de frecuencia captura los ataques automatizados de alto volumen. Juntas forman una red muy difícil de atravesar.
¿Lo quiere para su tienda?
Lo hemos construido como un plugin de WordPress llamado WC Antifraud. Es Open Source y está disponible en GitHub. Si su tienda WooCommerce está lidiando con pedidos falsos, ataques de card-testing o abuso por bots, puede ser justo lo que necesita.
El plugin cubre las cinco capas descritas arriba, con una interfaz de ajustes clara, alertas por correo, registro de actividad y un panel de informes. Funciona con el checkout clásico y el nuevo Block Checkout, y es compatible con HPOS (High-Performance Order Storage) de WooCommerce.
Véalo en GitHub — y si necesita ayuda para instalarlo o personalizarlo para su tienda, póngase en contacto.
