La prevención del fraude en pagos en línea no es un solo control. Es una cadena de ellos, repartida en tres momentos: antes de la transacción, durante ella y después de que llega el contracargo semanas más tarde. La mayoría de los comercios tienen algo en cada ventana y huecos entre ellas, y los defraudadores viven en los huecos. Esta guía recorre los principales tipos de fraude en pagos en línea, las capas de prevención que frenan cada uno y dónde encaja una fuente de señales a nivel de navegador dentro de una arquitectura que probablemente ya utilizas.
El planteamiento que más importa: una transacción fraudulenta y una legítima se ven idénticas en tu base de datos. El número de tarjeta se validó, la dirección coincidió, el CVV era correcto y el pedido se envió. La diferencia solo aparece después, cuando el titular real la disputa. Una prevención eficaz consiste en capturar las señales que distinguen a las dos mientras la sesión sigue abierta, porque una vez que se cierra esas señales desaparecen.
Qué se considera fraude en pagos en línea
El fraude en pagos en línea es cualquier transacción en la que quien paga no está autorizado a usar el medio de pago, o en la que una compra legítima se disputa después de forma falsa. Abarca tarjetas robadas, card testing automatizado, apropiación de cuentas y abuso de contracargos. No incluye errores genuinos de procesamiento ni devoluciones legítimas, aunque estos se enredan en el mismo canal de disputas.
La razón por la que es difícil frenarlo solo con datos de transacción es que el payload que recibe tu proveedor de servicios de pago (PSP) es escaso. Lleva el número de tarjeta, el importe y la dirección, pero no el dispositivo que lo envió, la forma en que se rellenó el formulario ni si la conexión estaba oculta tras un proxy. Eso vive en el navegador durante la sesión y nunca llega al PSP. Ese es el hueco de evidencia que el resto de esta guía busca cerrar.
Los cuatro principales tipos de fraude en pagos en línea
Card testing (carding)
El card testing es la fase de reconocimiento. Los atacantes que han comprado un lote de números de tarjeta robados necesitan saber cuáles siguen funcionando, así que ejecutan pequeños cargos, a menudo un dólar o una donación, entre cientos de números para separar las tarjetas vivas de las muertas. Las tarjetas validadas se usan luego para compras reales o se revenden a un precio más alto.
El card testing casi siempre está automatizado. Nadie teclea mil números de tarjeta a mano. Esa automatización es la debilidad: el ataque es rápido, repetitivo y guiado por máquina de una forma en que nunca lo es un checkout humano. Las reglas de velocidad atrapan la versión burda, pero los operadores sofisticados reparten los intentos para no superar los umbrales. El caso de uso de card testing cubre el patrón de detección en profundidad.
Fraude con tarjeta robada (transacción no autorizada)
Una vez validada una tarjeta, se usa. El fraude con tarjeta robada es el caso clásico: alguien compra bienes con una tarjeta que no le pertenece, los envía a una dirección de reenvío o a una mula, y el titular real lo descubre en su extracto. Este es fraude de terceros genuino, y es lo que la mayoría imagina al oír "fraude en pagos".
La señal que ayuda aquí es la continuidad de dispositivo. Una tarjeta usada desde un dispositivo que nunca se ha asociado con ese titular, o desde un dispositivo ya vinculado a fraude previo, es un riesgo materialmente distinto de la misma tarjeta usada en el teléfono conocido del titular. Los datos de transacción no pueden ver el dispositivo. Una huella a nivel de navegador sí.
Contracargos y fraude amistoso
No todos los contracargos son delictivos. Una gran parte son "fraude amistoso", en el que un titular real disputa un cargo que de hecho realizó, a veces por error (no reconoció el descriptor del comercio) y a veces de forma deliberada (quiere los bienes y el reembolso). Las estimaciones varían según la fuente y el sector, pero las encuestas del sector sitúan de forma consistente el fraude amistoso en la mayoría de los contracargos de comercio electrónico y no en una minoría.
El fraude amistoso es un problema de prevención que se gana después de la transacción, en la disputa. El comercio que puede demostrar que el propio dispositivo del titular estaba presente, y que la sesión se comportó como humana, tiene evidencia de que una reclamación de "yo nunca hice esta compra" es falsa. Esa evidencia debe capturarse durante el checkout y exportarse en un formato que las redes de tarjetas acepten. La exportación de evidencia de contracargo de cside está construida exactamente para esto.
Apropiación de cuentas en el checkout
La apropiación de cuentas (ATO) se sitúa en la intersección del fraude en pagos y el fraude de identidad. En lugar de usar una tarjeta robada en bruto, el atacante toma el control de la cuenta de un cliente legítimo, normalmente mediante credential stuffing, y paga con las tarjetas guardadas ya registradas. Esto es más difícil de atrapar porque la cuenta, la dirección y el medio de pago cuadran. Lo único que está mal es quién está detrás del teclado.
La huella de dispositivo es la señal principal previa a la autenticación aquí: un inicio de sesión o un checkout desde un dispositivo que nunca ha tocado esta cuenta es la pista, incluso cuando todas las credenciales son correctas. El caso de uso de apropiación de cuentas profundiza en el patrón de credential stuffing que lo alimenta.
Las capas de la prevención del fraude en pagos en línea
Ninguna herramienta única cubre todo el recorrido. Una arquitectura eficaz en 2026 combina varias, cada una cerrando una ventana distinta.
- Controles de las redes de tarjetas y emisores. 3-D Secure (3DS2), las verificaciones de CVV y AVS y la monitorización a nivel de red son la base. Trasladan parte de la responsabilidad y atrapan el fraude obvio, pero añaden fricción y no pueden ver la sesión del navegador.
- Puntuación de fraude nativa del PSP. Herramientas como Stripe Radar o Adyen RevenueProtect puntúan la transacción con aprendizaje automático. Son genuinamente útiles y en su mayoría gratuitas a bajo volumen, pero solo ven lo que ve el PSP: las señales de navegador previas a la autorización y la reutilización de dispositivos entre PSP quedan fuera de su ventana.
- Un motor de puntuación o de reglas. Una plataforma dedicada ingiere el historial de transacciones y devuelve una decisión de aprobar/bloquear/desafiar. Esta es tu capa de decisión, y es tan buena como las señales que le proporciones.
- Una fuente de señales a nivel de navegador. Esta es la capa que a la mayoría de las arquitecturas les falta. Se ejecuta en la página de pago y captura las señales de dispositivo, de comportamiento y de red que el registro de transacción nunca lleva: huella de dispositivo, marcas de automatización y de agentes de IA, estado de VPN y proxy y comportamiento de sesión.
- Automatización de disputas de contracargo. A posteriori, empaqueta la evidencia en los formatos requeridos por las redes de tarjetas y presenta la respuesta. Sin buena evidencia capturada, solo automatiza el perder.
El sentido de las capas es que la detección previa a la transacción reduce tu tasa de fraude y de disputas, mientras que la evidencia posterior a la transacción recupera dinero que de otro modo perderías. Invertir solo en automatización de disputas recupera ingresos que ya perdiste; invertir en la capa de navegador frena la pérdida antes y produce la evidencia que la capa de disputas necesita.
Dónde encaja cside en una arquitectura de prevención del fraude en pagos
cside es la fuente de señales a nivel de navegador de esa lista. Se despliega como un único fragmento de JavaScript de origen propio cargado desde tu propio dominio, así que no hay dominio de recolección de terceros que una lista de filtros o un atacante puedan bloquear. No se sitúa delante de tu tráfico y no es un proxy; lee la sesión de checkout y devuelve un veredicto. Hay tres partes del problema del pago donde más aporta.
Inteligencia de dispositivo en el checkout. cside construye una huella de dispositivo a partir de más de 250 señales de navegador, de dispositivo y de red por sesión, y mantiene esa identidad estable entre el modo incógnito, las conexiones VPN y el borrado de cookies. Eso es lo que hace utilizable la continuidad de dispositivo: puedes distinguir una tarjeta usada en el dispositivo conocido de su dueño de la misma tarjeta en un dispositivo que nunca has visto. La solución de inteligencia de dispositivo cubre cómo se construye la huella.
Detección de card testing y automatización. Como el fragmento también lee canales de comportamiento, cside ejecuta modelos separados para el movimiento del cursor, la cadencia de tecleo y el comportamiento más amplio en la sesión, y luego combina sus veredictos. Marca sesiones automatizadas y de agentes de IA, incluidos marcos de automatización como Playwright, Puppeteer y Selenium y navegadores agénticos como OpenAI Operator y Claude for Chrome. Una tanda de carding guiada por uno de ellos es visible incluso cuando cada cargo individual es demasiado pequeño para activar una regla de velocidad.
Evidencia de contracargo. El mismo ID de huella indexa la exportación de evidencia de contracargo de cside, que empaqueta la prueba a nivel de dispositivo en el formato Compelling Evidence 3.0 de Visa para las respuestas a disputas. Cuando aterriza una disputa de fraude amistoso, la evidencia que puntuó la transacción se convierte en la evidencia que gana la disputa, en lugar de pudrirse en un archivo de registro.
En móvil, cside ejecuta el mismo motor a través de SDK nativos de iOS y Android, actualmente en beta (acceso anticipado), que capturan el mismo conjunto de señales que el cliente web más señales que solo una app puede ver. Habla con el equipo si la cobertura móvil está en tu alcance.
Dos cosas que cside deliberadamente no es: no es una plataforma de decisión (combínala con tu motor de puntuación o de reglas, que consume su veredicto como características adicionales), y no impide que una tarjeta sea robada en primer lugar. Lo que hace es cerrar el hueco de evidencia entre la sesión de checkout y todo lo que viene después.
Cómo construir tu plan de prevención
Si estás montando o afinando una arquitectura de prevención del fraude en pagos en línea, trabaja en este orden:
- Cubre la base. Confirma que 3DS2, CVV y AVS están activados y que la puntuación de fraude nativa de tu PSP está habilitada y ajustada. Esto es lo mínimo indispensable y en su mayoría gratuito.
- Captura evidencia de navegador en el checkout. Añade la capa a la que tu plataforma de puntuación y tu PSP están ciegos, para que las señales de dispositivo, automatización, VPN y comportamiento se registren durante la sesión, no se reconstruyan después.
- Alimenta las señales en tu capa de decisión. No sustituyas tu motor de puntuación; pásale las señales de navegador como características adicionales para que mejoren las decisiones de aprobar/bloquear.
- Automatiza la evidencia CE 3.0 para las disputas. Cuando salta un contracargo, las señales que puntuaron la transacción deben fluir directamente a la respuesta de la disputa en el formato que las redes de tarjetas aceptan.
Para un análisis más profundo del hueco de evidencia en el checkout y de por qué los datos de sesión deben capturarse en vivo, consulta detección de fraude en pagos: el hueco de evidencia en el checkout. Si estás eligiendo entre proveedores, el mejor software de detección de fraude en pagos en 2026 clasifica las plataformas y muestra dónde una fuente a nivel de navegador se combina con una plataforma de puntuación.
