Carding en Magento: cómo frenar pruebas de tarjetas robadas

• Qué es: pruebas automáticas de tarjetas robadas en tu checkout para saber cuáles siguen activas.
• Por qué te afecta: genera contracargos, sube tu tasa de rechazos y puede costarte comisiones.
• Magento 2.4.7 o superior: trae rate limiting para los endpoints de pago de REST y GraphQL. Viene apagado.
• reCAPTCHA: Magento lo trae para colocar pedido y cupones. Hyvä Checkout lo soporta desde las versiones 1.3.15 y 3.0.
• Ninguna capa basta sola: combina Magento, WAF y pasarela.

En este artículo:

• Qué es el carding
• Cómo detectar un ataque
• Qué hacer en las primeras horas
• Rate limiting nativo de Magento
• reCAPTCHA en el checkout
• reCAPTCHA en Hyvä Checkout
• WAF y Cloudflare
• El papel de la pasarela
• Checklist para el Buen Fin
• Preguntas frecuentes

Cada temporada alta pasa lo mismo: junto con los compradores llegan los bots. El carding en Magento es uno de los ataques más comunes en esas fechas. Un script usa tu checkout para probar cientos de tarjetas robadas y ver cuáles funcionan.

Importa porque el daño llega a tu cuenta de pagos, no solo a tu servidor. Contracargos, rechazos y comisiones pueden seguir semanas después del ataque. Esta guía explica cómo detectarlo y qué controles tienen Magento, Adobe Commerce y Hyvä para frenarlo antes del Buen Fin.

Si buscas la lista general de preparación (hosting, caché, inventario, pagos), está en nuestro checklist técnico del Buen Fin 2026. Aquí nos enfocamos solo en el carding.

¿Qué es el carding y por qué ataca tiendas Magento?

El carding, o prueba de tarjetas, es intentar compras o registros de tarjeta con datos robados para saber cuáles siguen válidos. Stripe lo describe así y explica que los atacantes usan scripts para probar muchas tarjetas a la vez y leer la respuesta del banco.

Adobe lo explica en su documentación de rate limiting: el atacante prueba números de tarjeta, normalmente en lotes de miles. Con la misma técnica puede adivinar datos faltantes, como la fecha de vencimiento. Agrega que las tiendas Adobe Commerce pueden ser blanco de este ataque a través de su tienda y de sus integraciones con pasarelas de pago.

Una tienda Magento es atractiva porque su checkout y sus APIs públicas permiten crear carritos y mandar datos de pago sin iniciar sesión. Eso es lo que hace cómoda la compra como invitado, y también lo que aprovecha un bot.

Según Stripe, las consecuencias más comunes son:

• Disputas: algunos cobros de prueba pasan, el titular los ve y los reporta como fraude.
• Más rechazos: muchos pagos rechazados dañan tu reputación ante los emisores, y eso puede afectar pagos legítimos incluso después del ataque.
• Comisiones extra: por autorizaciones y por disputas, según tu contrato.
• Carga en la infraestructura: miles de solicitudes que compiten con tus clientes reales.
• Datos sucios: pedidos falsos que parecen clientes nuevos en tus reportes.

¿Cómo saber si tu tienda Magento está sufriendo carding?

La señal principal es un aumento repentino de pagos fallidos. Stripe indica que la mayoría de los ataques se notan en el panel de la pasarela. Revisa estas señales:

• Picos de pagos rechazados o bloqueados en el panel de tu pasarela.
• Muchos intentos de cobro por montos pequeños.
• Nombres de cliente o correos sin sentido en pedidos o intentos de pago.
• Ráfagas de solicitudes a los endpoints de pago de Magento: /rest/V1/.../guest-carts/.../payment-information o /graphql.
• Muchos carritos de invitado creados desde pocas direcciones IP en poco tiempo.

Si ves dos o más de estas señales al mismo tiempo, trátalo como un ataque activo. Avisa a tu pasarela de inmediato.

¿Qué hacer en las primeras horas de un ataque de carding?

Primero frena el tráfico y después limpia. Este orden se basa en la guía de prueba de tarjetas de Stripe y en los controles que documenta Adobe:

1. Confirma con tu pasarela. Pide que revisen la actividad y qué bloqueos pueden activar de su lado.
2. Activa reCAPTCHA al colocar el pedido y en cupones, desde la configuración de Magento.
3. Enciende el rate limiting de pagos si tu tienda está en Magento 2.4.7 o superior.
4. Pon reglas en tu WAF o CDN para los endpoints de pago, sobre todo si estás en una versión anterior.
5. Si el ataque sigue, considera pausar la compra como invitado. Magento lo permite en la configuración de checkout. Afecta la conversión, así que úsalo como medida temporal.
6. Reembolsa los cobros sospechosos que sí pasaron. Stripe lo recomienda para evitar disputas.
7. Cuida los reintentos de cobro. Stripe advierte que muchos reintentos con baja tasa de éxito pueden parecer prueba de tarjetas.

La compra como invitado se desactiva en Stores > Configuration > Sales > Checkout > Checkout Options, con la opción Allow Guest Checkout en No, según la guía de Adobe.

¿Cómo activar el rate limiting nativo de Magento 2.4.7?

Desde Magento Open Source y Adobe Commerce 2.4.7 puedes limitar cuántas veces se envía información de pago por REST y GraphQL. Las notas de la versión 2.4.7 lo presentan como una protección contra ataques que prueban muchas tarjetas a la vez. Viene desactivado por defecto.

Según la documentación de Adobe, el límite aplica a estos puntos de entrada:

• REST: guest-carts/<cart_id>/payment-information y guest-carts/<cart_id>/order.
• REST: carts/mine/payment-information y carts/mine/order.
• GraphQL: /graphql.
• El módulo Instant Purchase.

Paso 1: conectar el registro a Redis

Magento guarda temporalmente cada solicitud en Redis para contarlas. Se configura por línea de comandos. Usa un número de base de datos distinto al de tus cachés y sesiones; los ejemplos de Adobe usan la 3:

bin/magento setup:config:set \
  --backpressure-logger=redis \
  --backpressure-logger-redis-server=127.0.0.1 \
  --backpressure-logger-redis-port=6379 \
  --backpressure-logger-redis-db=3

Cambia el servidor y el puerto por los de tu Redis. Si es un servicio administrado, tu equipo de hosting debe darte esos datos.

Paso 2: activar y ajustar los límites

Se hace en Stores > Configuration > Sales > Sales > Rate Limiting o con estos comandos. Los valores son los del ejemplo de Adobe, no una recomendación para tu tienda:

bin/magento config:set sales/backpressure/enabled 1
bin/magento config:set sales/backpressure/guest_limit 50
bin/magento config:set sales/backpressure/limit 10
bin/magento config:set sales/backpressure/period 60

Qué cuidar al configurarlo

• Sin Redis no funciona. Si lo activas sin configurar el registro, Magento no aplica el límite y deja el error "Backpressure sliding window not applied" en var/log/system.log.
• El bloqueo dura tres veces el periodo. Con 60 segundos, quien rebasa el límite espera 180 segundos.
• Los invitados se cuentan por IP. Varios compradores reales detrás de una misma red, como una oficina, cuentan como uno. Ajusta el límite con tu historial de pedidos.
• Respuestas distintas por API. REST responde 429 Too Many Requests; GraphQL responde 200 con el error en el cuerpo. Tu monitoreo debe leer ambos casos.

Si tu tienda está en una versión anterior a 2.4.7, no tienes esta función. Revisa nuestra guía de Magento 2.4.x en 2026 para planear la actualización.

¿Qué reCAPTCHA conviene usar en el checkout de Magento?

Magento y Adobe Commerce traen Google reCAPTCHA para el storefront. En la lista de formularios de Adobe aparecen, entre otros, Checkout/Placing Order, Coupon Codes, inicio de sesión, creación de cuenta y el formulario de PayPal Payflow Pro.

Se configura en Stores > Configuration > Security > Google reCAPTCHA Storefront. Adobe pide que allow_url_fopen = 1 esté activo en PHP antes de configurarlo, y que las llaves de Google correspondan al tipo de reCAPTCHA que elijas.

Adobe advierte que con v3 un cliente legítimo con puntaje bajo no puede avanzar, mientras que con v2 recibe un reto. En el checkout esa diferencia importa: un bloqueo silencioso es una venta perdida. Prueba con compras reales antes de dejar v3 en el paso de pago.

Si usas cupones en tus promociones, activa también reCAPTCHA en Coupon Codes. Los bots también prueban códigos. Aquí explicamos cómo crear y gestionar cupones en Magento.

¿Hyvä Checkout es compatible con reCAPTCHA?

Sí. Según el historial de versiones de Hyvä, Hyvä Checkout 1.3.15 y 3.0 soportan reCAPTCHA v2 casilla, v2 invisible y v3. Lo aplican en tres puntos: el inicio de sesión del invitado, el campo de cupón y la colocación del pedido. Hyvä Checkout 3.0.0 se publicó como estable el 27 de octubre de 2026.

• Usa la configuración de Magento. No hay un panel aparte: se activa en Google reCAPTCHA Storefront.
• Viene desactivado por defecto. Hay que encenderlo.
• No cubre las APIs. Hyvä aclara que los pedidos por Web API o desde el admin no pasan por ese reCAPTCHA. Por eso conviene sumar el rate limiting de Magento.
• Cuidado con flujos fuera del checkout. En 3.0 Hyvä corrigió que PayPal Express desde el carrito e Instant Purchase eran rechazados con el reCAPTCHA de pedido activo. Si tienes un módulo de pago con su propio endpoint, revisa la nota del changelog.

Si todavía estás en el checkout de Luma, compara opciones en Hyvä Checkout vs Luma.

¿Qué aporta el WAF o Cloudflare contra el carding?

Un WAF o CDN frena solicitudes antes de que lleguen a PHP. Eso protege el servidor durante un pico y te da una defensa aunque tu Magento sea anterior a 2.4.7.

Cloudflare permite crear reglas de rate limiting por ruta, por ejemplo para los endpoints de pago de /rest/ y para /graphql. Lo que puedes contar depende de tu plan. En Enterprise hay más criterios que la IP, y algunos, como la huella JA3/JA4, requieren Bot Management.

Stripe advierte que las reglas basadas en una sola señal, como la dirección IP, no suelen bastar contra la prueba de tarjetas. Usa el WAF como una capa más, no como la única.

En Panamerik trabajamos con Cloudways y su Cloudflare Enterprise, que agrega WAF y protección DDoS. Más detalle en nuestro servicio de hosting Magento.

¿Qué le toca a la pasarela de pago?

La pasarela ve la respuesta del banco, así que detecta patrones que Magento no ve. Stripe, por ejemplo, documenta que sus integraciones recomendadas incluyen limitadores de frecuencia, modelos de IA y CAPTCHA automático contra la prueba de tarjetas.

Stripe también explica que su detección mejora cuando la integración envía más datos del comprador: dirección IP, correo, nombre y dirección de facturación. Si tu módulo de pago en Magento no los manda, pídele a tu desarrollador que lo revise.

• Pregunta a tu pasarela qué controles tiene contra prueba de tarjetas y si debes activarlos.
• Revisa si puedes crear reglas propias, como límites por IP o filtros por agente de usuario. En Stripe se hace con reglas personalizadas de Radar, si tu plan lo admite.
• Confirma que tus llaves secretas no estén expuestas. Stripe advierte que una llave filtrada permite crear cobros desde fuera de tu tienda.

Si vas a ofrecer meses sin intereses en el Buen Fin, revisa también nuestra guía de meses sin intereses en Magento con Stripe, Mercado Pago y Openpay.

¿Qué capas aplicar según tu tienda?

Checklist de carding antes del Buen Fin 2026

• Confirma tu versión de Magento o Adobe Commerce y la de Hyvä Checkout.
• Activa y prueba el rate limiting de pagos con Redis configurado.
• Activa reCAPTCHA en Checkout/Placing Order y en Coupon Codes; haz compras de prueba.
• Crea reglas en tu WAF para los endpoints de pago y /graphql.
• Pregunta a tu pasarela por sus controles de prueba de tarjetas.
• Define quién vigila el panel de pagos durante el evento y qué umbral dispara una alerta.
• Ten listo el plan de respuesta: a quién llamar, qué activar y cuándo pausar la compra como invitado.

Conclusión

El carding no se resuelve con un solo ajuste. En Magento, la combinación que mejor funciona es rate limiting de pagos, reCAPTCHA al colocar el pedido, reglas en el WAF y los controles de la pasarela. Lo importante es dejarlo probado antes del Buen Fin, no activarlo a media campaña.

Para el panorama completo de seguridad, lee nuestra guía de seguridad en Magento y cómo usamos inteligencia artificial para proteger Magento. En Panamerik usamos IA en auditorías de seguridad y en la corrección de errores. Si necesitas apoyo, conoce nuestro soporte Magento y nuestro trabajo con Adobe Commerce.

Sobre el autor

Panamerik dirige Panamerik, agencia especializada en Magento y Adobe Commerce desde Guadalajara. Su equipo diseña, desarrolla, integra y da soporte a tiendas en línea.

Fuentes

• Adobe Developer: Rate limiting (consultado el 4 de noviembre de 2026)
• Adobe Experience League: Magento Open Source 2.4.7 release notes (consultado el 4 de noviembre de 2026)
• Adobe Experience League: Google reCAPTCHA V3 and V2 (consultado el 4 de noviembre de 2026)
• Adobe Experience League: Security > Google reCAPTCHA Storefront (consultado el 4 de noviembre de 2026)
• Adobe Experience League: Guest checkout (consultado el 4 de noviembre de 2026)
• Hyvä Docs: Hyvä Checkout Feature History (consultado el 4 de noviembre de 2026)
• Hyvä Docs: Checkout 3.x Changelog (consultado el 4 de noviembre de 2026)
• Stripe Docs: Protégete de las pruebas de tarjetas (consultado el 4 de noviembre de 2026)
• Cloudflare Docs: Rate limiting rules (consultado el 4 de noviembre de 2026)
• Cloudways: Cloudflare Enterprise (consultado el 4 de noviembre de 2026)