# Protégete de las pruebas de tarjetas Obtén más información sobre esta actividad fraudulenta y sobre cómo protegerte contra ella. La prueba de tarjetas es un tipo de actividad fraudulenta en la que alguien intenta determinar si la información de una tarjeta robada es válida para poder utilizarla al hacer compras. Un actor fraudulento podría hacerlo comprando información de tarjetas de crédito robadas, para después intentar validar o hacer compras con ellas con el fin de determinar cuáles siguen siendo válidas. Otros términos comunes para referirse a la prueba de tarjetas son «carding», «account testing», «enumeration» y «card checking». Las actividades fraudulentas, como la prueba de tarjetas, son parte inevitable del comercio en línea. Sin embargo, las consecuencias de la prueba de tarjetas repercuten en todo el ecosistema de pago, así que los comerciantes, las redes de tarjetas y Stripe comparten la responsabilidad a la hora de prevenir esta actividad. En Stripe, tratamos constantemente de mejorar nuestras herramientas y sistemas para detectar y disminuir el fraude, pero debes estar siempre atento. ## Cómo funciona la prueba de tarjetas Quienes hacen pruebas de tarjetas utilizan tanto la configuración de la tarjeta como los pagos para determinar si la información de la tarjeta robada o enumerada que tienen es válida o no. Para validar rápidamente muchos números de tarjeta, los actores fraudulentos utilizan scripts a fin de probar una gran cantidad de información de tarjetas a la vez y recopilan las respuestas del 3DS o del emisor para validar qué información es válida. Una vez identificadas las tarjetas válidas, pueden cobrarlas en comercios o revenderlas en la dark web. - **Configuración de la tarjeta**: es el método preferido de los actores fraudulentos, ya que la validación y las autorizaciones durante la configuración de la tarjeta no suelen aparecer en los extractos bancarios del titular de la tarjeta. Así se reduce la probabilidad de que los titulares de las tarjetas se den cuenta de la actividad fraudulenta y la denuncien. - **Pagos**: los probadores de tarjetas realizan pagos de pequeña cuantía, que los titulares de las tarjetas tienen menor probabilidad de notar y denunciar como fraudulentos. ## Consecuencias de la prueba de tarjetas La prueba de tarjetas tiene muchos aspectos negativos, algunos de los cuales se agravan con el tiempo si las pruebas continúan: - **Disputas**: muchos tipos de pruebas de tarjetas implican pagos, algunos de los cuales se efectúan con éxito. Los clientes detectan los pagos realizados correctamente y los denuncian como fraude, lo que da lugar a [alertas tempranas de fraude](https://docs.stripe.com/disputes/measuring.md#early-fraud-warnings) o incluso [disputas fraudulentas](https://docs.stripe.com/disputes.md) que te cuestan tiempo y dinero. - **Tasas de rechazo más altas**: la prueba de tarjetas asocia un gran número de pagos rechazados a tu empresa. Una alta tasa de rechazo podría dañar la reputación de tu empresa ante los emisores y las redes de tarjetas, lo que hace que todas tus transacciones parezcan más arriesgadas. Esto puede provocar un aumento de la tasa de rechazo de los pagos legítimos, incluso después de que cese la prueba de tarjetas. - **Comisiones adicionales**: las pruebas de tarjetas pueden generar comisiones adicionales, como las comisiones por autorización para los planes de tarifas personalizadas y las comisiones por disputas. - **Saturación de la infraestructura**: las pruebas de tarjetas suelen implicar numerosas solicitudes y operaciones en la red. Este tráfico adicional puede sobrecargar tu infraestructura e interferir en la actividad legítima. - **Deterioro del ecosistema**: las pruebas de tarjetas afectan negativamente a todo el sistema financiero, por eso, tanto Stripe como nuestros socios financieros queremos ayudarte a detenerlas. Un gran volumen de pruebas de tarjetas que resulte en alertas tempranas de fraude o disputas podría, por ejemplo, hacer que se te incluya en los [programas de supervisión de tarjetas](https://docs.stripe.com/disputes/monitoring-programs.md). - **Reduce la calidad de los datos para que tu empresa funcione**: los ingresos por prueba de tarjetas pueden aparecer como buenos y nuevos clientes en tus datos, por lo que se hace difícil tener una visión clara del crecimiento real de tu negocio. ## Lista de verificación activa de pruebas de tarjetas Si estos estafadores han tenido acceso a tu integración, te recomendamos que tomes las siguientes medidas de inmediato: - [Identificar](https://docs.stripe.com/disputes/prevention/card-testing.md#identify-card-testing) la actividad de prueba de tarjetas. - [Reembolsar](https://docs.stripe.com/refunds.md) pagos fraudulentos para evitar disputas. - [Usa una integración recomendada por Stripe](https://docs.stripe.com/disputes/prevention/card-testing.md#optimize-integration) o añade [medidas de mitigación](https://docs.stripe.com/disputes/prevention/card-testing.md#control-implementation) para suprimir la prueba de tarjetas. - Supervisa tu integración para asegurarte de que las medidas de mitigación sean eficaces. ## Identificar las pruebas de tarjetas Puedes identificar la mayor parte de las pruebas de tarjetas porque se produce un aumento significativo de las autorizaciones y los pagos fallidos. La mayoría de los ataques son evidentes en el Dashboard de Stripe. Los síntomas comunes a los que hay que prestar atención son los siguientes: - **Un pico de pagos fallidos o bloqueados.** Puedes ver las tendencias en [la página de inicio del Dashboard](https://dashboard.stripe.com/dashboard), en la vista de la lista de [transacciones](https://dashboard.stripe.com/payments) y puedes examinar los motivos de los bloqueos en la página de detalles del pago. - **Un pico en las solicitudes con errores 402**. Puedes ver el pico de volumen en la página de [Desarrolladores](https://dashboard.stripe.com/developers), examinar los errores 402 en la página de [registros fallidos](https://dashboard.stripe.com/logs?error_type=card_error) o escuchar las respuestas de los webhooks y API, en particular con un [resultado de «generic_decline»](https://docs.stripe.com/declines/codes.md). - **Un aumento en los pagos sospechosos** con importes de transacción bajos, a menudo con nombres de clientes y correos electrónicos carentes de sentido. Para evitar disputas, recomendamos reembolsar estas transacciones sospechosas si logran superar las defensas existentes. ## Prevenir la prueba de tarjetas Quienes prueban tarjetas emplean una gran variedad de técnicas para dificultar que impidas su actividad. Como resultado, las reglas de firewall simples o los filtros basados en una única heurística, como las direcciones IP, normalmente no son suficientes por sí solos para prevenir las pruebas de tarjetas. Quienes prueban tarjetas pueden usar tu clave publicable y usarla para reintentar una gran cantidad de pagos en tu sitio web. Tienes dos estrategias principales de mitigación para estos ataques: - **Usa una integración recomendada por Stripe**: elige una integración recomendada por Stripe para aprovechar la protección contra la prueba de tarjetas que sabemos que funciona. - **Implementación de controles**: invierte en un conjunto de controles que impida que quienes realizan pruebas de tarjetas ataquen los puntos de conexión vulnerables. Además de implementar estrategias de mitigación, debes asegurarte de que mantienes tus claves seguras y de no publicar tu clave secreta. Cuando tus credenciales se filtran o son robadas, las personas que prueban las tarjetas pueden crear pagos y configurar tarjetas utilizando tu clave secreta. > Si no eres desarrollador o si utilizas un plugin o una plataforma, la prevención y mitigación de la prueba de tarjetas suele requerir cambios a nivel de programación. Muestra esta documentación al desarrollador o proveedor que ha escrito el código y trabaja con él para evitar la prueba de tarjetas. ### Usa una integración recomendada por Stripe Si utilizas la versión más reciente de Stripe Payment Element o de Checkout, disponemos de varios controles automatizados y manuales para mitigar la prueba de tarjetas, incluidos los limitadores de tasa, modelos de IA, activadores de CAPTCHA, revisiones continuas, etc. Cuando detectamos que estás sufriendo un ataque de prueba de tarjetas, elegimos dinámicamente las intervenciones que lo suprimen en la medida de lo posible y que, al mismo tiempo, permiten a los usuarios legítimos realizar transacciones en tu cuenta con un impacto mínimo. Verás estos pagos marcados como `Blocked by Stripe`. *Sin embargo, el funcionamiento correcto de los controles de Stripe depende de tu integración y de los factores de riesgo que nos envías*. Stripe usa muchos factores de riesgo para distinguir entre prueba de tarjetas y pagos legítimos. Aunque algunos de estos factores de riesgo se computan automáticamente, muchos otros dependen de la información proporcionada por tu integración. Por lo general, cuanto más datos proporciona tu integración, mejor es la prevención de la prueba de tarjetas. Recomendamos usar una de las [integraciones recomendadas](https://docs.stripe.com/payments/online-payments.md#compare-features-and-availability) de Stripe para aprovechar la protección automatizada establecida en [CAPTCHA](https://www.hcaptcha.com/). Las soluciones CAPTCHA modernas aplican múltiples factores de riesgo para aumentar la fricción por comportamientos de alto riesgo, al tiempo que parecen invisibles para los usuarios legítimos de tu servicio. Para cancelar nuestra integración CAPTCHA, contacta con el [soporte Stripe](https://support.stripe.com/contact/login). El uso de una de nuestras integraciones de pago recomendadas te permite sacar el máximo partido a la prevención de pruebas de tarjetas de Stripe. Si no puedes utilizar una integración recomendada, incluye tantos datos como sea posible o implementa tus propios controles. Aunque los controles de pruebas de tarjetas son independientes de la protección de Radar contra disputas por fraude, se benefician [de los mismos factores de riesgo que utiliza Radar](https://docs.stripe.com/radar/optimize-risk-factors.md). Incluir la siguiente información en tus pagos puede influir de forma significativa en el rendimiento de los modelos de prueba de tarjetas de Stripe. Nuestras integraciones recomendadas te permiten recopilar esta información, mientras que las integraciones directas pueden requerir su inclusión explícita. - [Detección avanzada del fraude](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) (Mayor impacto) - Dirección IP - Correo electrónico del cliente - Nombre del cliente - Dirección de facturación ### Implementación del control Añadir restricciones a los puntos de conexión específicos te ayuda a suprimir y prevenir la prueba de tarjetas. Las restricciones que implementes pueden hacer que la prueba de tarjetas sea inviable, y, al mismo tiempo, tener un impacto mínimo o nulo en el tráfico legítimo. Normalmente, estos estafadores tienen como objetivo puntos de conexión que les permitan hacer alguna de las siguientes operaciones: - Guarda la tarjeta. - Realizar un pago. Las medidas de seguridad específicas que añadas a tu integración varían según tu situación y las necesidades de tu empresa. A continuación describimos algunos enfoques comunes. ### Implementa el CAPTCHA Estos estafadores suelen utilizar secuencias de comandos automáticas que el CAPTCHA puede bloquear. Los scripts son especialmente eficaces si no utilizas una de las integraciones recomendadas que admita CAPTCHA. Las soluciones modernas de CAPTCHA ofrecen opciones de CAPTCHA visibles e invisibles, en función de tus necesidades. Si has añadido un CAPTCHA a tu integración, pero la prueba de tarjetas ha continuado, comprueba lo siguiente: - Asegúrate de que el CAPTCHA exija una validación en todas las solicitudes que habiliten verificaciones de tarjetas o pagos con Stripe. - Revisa la documentación de CAPTCHA para asegurarte de que lo has implementado del lado del servidor. - Si utilizas una solución de CAPTCHA que da una puntuación, ajusta el umbral a partir del cual impides que las solicitudes se realicen correctamente. - Prueba otra solución de CAPTCHA, por ejemplo, pasa de un CAPTCHA invisible a uno visible o usa una solución de CAPTCHA totalmente diferente. ### Limita el acceso a tu formulario de pago Cuanto más fácil sea para los estafadores acceder a tu formulario de pago (por ejemplo, usando el pago como invitado), más fácil les resultará hacer pruebas con tarjetas. Puedes reducir tu exposición a los probadores de tarjetas pidiendo que inicien sesión o que validen la sesión antes de que puedan hacer un pago. Algunas de [las medidas de seguridad que protegen contra los ataques de falsificación de solicitudes de sitios cruzados (CSRF)](https://owasp.org/www-project-cheat-sheets/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html) también son eficaces contra algunos tipos de pruebas con tarjetas, como los tokens CSRF. ### Añade límites de velocidad En algunos casos, puedes reducir la prueba de tarjetas añadiendo límites de velocidad de redes (por ejemplo, en la interfaz de tu tienda web). Ajusta estos límites de velocidad para detener el tipo específico de prueba de tarjetas que estés experimentando. Por ejemplo, si usan tu integración para validar tarjetas asociándolas a nuevos clientes, un impedimento eficaz podría ser limitar la cantidad de clientes nuevos que se puedan crear desde una sola dirección IP en 1 día. Además de los límites de velocidad de la red, puedes añadir límites de velocidad a tus pagos y al flujo del proceso de compra del carrito para [detectar y prevenir comportamientos inusuales](https://docs.stripe.com/disputes/prevention/card-testing.md#prevent-unusual-behavior) incluso después de iniciar sesión o registrarte. ### Detecta y prevén comportamientos inusuales Usa el Dashboard, [webhooks](https://docs.stripe.com/webhooks.md) o la monitorización continua con [Stripe Sigma o Data Pipelines](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) para hacer un seguimiento de las anomalías en tu tráfico. Puedes comparar la actividad de prueba de tarjetas con el tráfico legítimo habitual y, a continuación, crear filtros que limiten o eviten solo la actividad de prueba de tarjetas. Por ejemplo, podrías introducir cambios en tu sistema con los siguientes objetivos: - Limita la cantidad de tarjetas que se pueden añadir a una cuenta - Limitar la cantidad de clientes que se pueden crear con una misma dirección IP - Limita la cantidad de compras que se pueden hacer con el mismo producto - Limitar la cantidad de clientes del mismo tipo que se pueden crear - Filtrar las solicitudes de determinados agentes de usuario u otros parámetros Para ello, puedes usar [reglas personalizadas](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) en Radar, si [tu plan](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) admite esta función. ### Usa una combinación de las medidas de mitigación A veces, conviene combinar diversos enfoques para reducir la prueba de tarjetas y maximizar el impacto en la actividad fraudulenta sin afectar al tráfico legítimo. Por ejemplo, puedes combinar un CAPTCHA y límites de velocidad. De esta manera, el primer intento de pago desde una dirección IP se realizará correctamente y sin restricciones, pero las siguientes solicitudes que lleguen de la misma dirección IP en las horas siguientes tendrán que pasar una verificación CAPTCHA para ser aprobadas. ### Vuelve a intentarlo con cuidado Los reintentos excesivos (reclamación del pago) pueden parecer una prueba de tarjetas si se producen en picos extremos con una baja tasa de éxito. La reclamación del pago y los ataques reales de prueba de tarjetas pueden tener efectos similares en tu empresa, incluido el endurecimiento de la postura de riesgo de los emisores. Asegúrate de no seguir volviendo a intentar las tarjetas configuradas para clientes fraudulentos después de un ataque de prueba de tarjetas, porque esto repite el ataque original. [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries.md#non-retryable-decline-codes) de Stripe ya tiene esto en cuenta. ### Personaliza la protección en función de tu tolerancia al riesgo Más allá de las medidas de mitigación que se implementan, es conveniente ajustar aún más la protección con Radar. Viene con reglas integradas para bloquear en función de las [comprobaciones bancarias](https://docs.stripe.com/radar/rules.md#traditional-bank-checks), como las comprobaciones de *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number). Si entiendes el comportamiento de tus clientes y quieres personalizar la velocidad de los pagos en detalle, puedes crear [reglas personalizadas](https://docs.stripe.com/radar/rules/reference.md#velocity-rules) en Radar, si [tu plan](https://docs.stripe.com/radar/how-radar-works.md#compare-plans) admite esta función. Puedes encontrar ejemplos en la [guía de aspectos básicos de Radar](https://stripe.com/guides/radar-rules-101#rules-that-help-prevent-card-testing-or-card-cashing). ## See also - [Detección avanzada del fraude](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection.md) - [Optimiza tu integración Radar](https://docs.stripe.com/radar/optimize-risk-factors.md) - [Cómo proteger tus claves](https://docs.stripe.com/keys-best-practices.md) - [Guía de aspectos básicos de Radar](https://stripe.com/guides/radar-rules-101)