Las reglas predeterminadas de Stripe utilizan el machine learning para predecir y bloquear una cantidad sustancial de pagos fraudulentos. Para empresas que necesitan más control sobre qué pagos deben revisarse, permitirse o bloquearse, las reglas son una potente herramienta que permite personalizar su forma de protegerse contra el fraude.

En esta guía hacemos un repaso exhaustivo a los aspectos más importantes de las reglas de Radar, te presentamos más de 100 reglas que puedes usar en Radar y analizamos las prácticas recomendadas con respecto al backtesting, la escritura de reglas y mucho más.
Vamos a empezar.

La importancia del orden y la jerarquía en las reglas

El orden que siguen las reglas en tu página de Radar es importante. Cada pago se evalúa teniendo en cuenta las reglas que has creado y el proceso de evaluación se ejecuta en este orden:

1. Request 3DS: estas son las reglas que solicitan autenticación 3D Secure cuando se usan con Stripe Checkout o con la API de Payment Intents. Sean cuales sean los resultados de este paso, las siguientes reglas también se evalúan a continuación.
   
2. Allow: cuando se aplican estas reglas de «permiso», se autoriza que un pago se procese. Este tipo de reglas debe implementarse con mucha atención, ya que pasarán siempre por delante de cualquier otra regla (excepto las de 3DS), incluidos los modelos de machine learning de Stripe. Solo los comerciantes que han procesado más de 100.000 USD puede escribir reglas del tipo Allow.
   
3. Block: cuando se aplican estas reglas de «bloqueo», se rechaza el pago. Cuando se aplica un bloqueo a un pago, no se evalúa con respecto a ninguna regla de revisión.
   
4. Review: cuando se aplica una regla de «revisión», el pago se sigue procesando y se cobra al cliente, pero se asigna un mensaje a la transacción para que puedas analizarla más adelante si lo consideras necesario.
   

Para poner esto en práctica, usemos las siguientes reglas como ejemplo:

• Allow payments less than $10

• Allow payments within the US and with a risk level of normal

• Block payments where the risk level is high

• Block payments greater than $1,000

• Review payments with a card issued outside the US

En este caso, todos los pagos inferiores a 10 USD se procesarían, porque la primera regla permite la transacción y evita que se evalúen más reglas. Del mismo modo, un pago de 1500 USD realizado dentro de los Estados Unidos con un nivel de riesgo «normal» también se permitiría, a pesar de que más adelante hay una regla que bloquea pagos de más de 1000 USD. Esto es así porque la segunda regla de la lista permite pagos realizados dentro de Estados Unidos y con un nivel de riesgo normal. Cuando una regla autoriza o bloquea un pago, ya no se evalúan las reglas posteriores.

Simbología básica del lenguaje de las reglas

Las escritura de reglas funciona de forma similar a SQL: tienes acceso a distintos operadores que puedes usar en función del tipo de datos que utilizas en tu regla. Estos son algunos de los más relevantes:

Si quieres verificar de forma explícita la existencia de un atributo o atributo de metadatos, utiliza la función is_missing en lugar del operador !=. Acompaña esta función del atributo o metadato que te gustaría revisar. Por ejemplo, podrías escribir una regla para ver todos los pagos que no incluyen la dirección de correo electrónico del cliente:

• Review if is_missing(:email_domain:)
  

O podrías escribir una regla que muestre todos los pagos que sí incluyen la dirección de correo electrónico del cliente:

• Review if !(is_missing(:email_domain:))
  

Reglas de Radar de uso frecuente

Hemos preparado una lista de reglas comunes de Radar y las hemos clasificado en función del objetivo. Puedes escribir decenas de reglas mucho más específicas, pero estos ejemplos deberían darte una buena idea de lo que puedes conseguir:

Reglas que ayudan a prevenir los ataques de prueba de tarjetas y los cobros fraudulentos

Reglas que ayudan a prevenir el fraude en función del tipo de producto

Este tipo de reglas requiere usar metadatos o definir información sobre el SKU (el código único de cada producto) en la descripción del cargo. Estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que los puedas revisar.

Reglas que ayudan a evitar el fraude con tarjetas prepago

Reglas que ayudan a evitar varias disputas de una tarjeta

Los tres tipos de atributos en la creación de reglas

Tipo 1

Atributos posteriores a la autorización: este tipo de atributos está disponible para todos los usuarios. Para configurar un atributo posterior a la autorización, utiliza dos puntos antes y después del atributo que quieras usar: por ejemplo, «:cvc_check:».

Aquí tienes un ejemplo de cómo usar este tipo de atributos posteriores a la autorización:

• Block if :address_line1_check: != 'pass' Con esta regla, cualquier cargo se bloqueará si no pasa específicamente la verificación del emisor de tarjeta. Es decir, para que se pueda autorizar el pago, deberá coincidir la primera línea de la dirección de facturación que el cliente ha proporcionado con la información que el emisor tiene registrada para el titular de la tarjeta. Por lo tanto, si la verificación aparece como «no disponible» (unavailable), si el emisor «no verificó» los datos (unchecked) o si el emisor «no proporcionó» (not_provided) los datos, el pago se bloqueará.
  

Tipo 2

Atributos estándar: este tipo de atributos está disponible para todos los usuarios. Para configurar un atributo estándar, también debes utilizar dos puntos antes y después del atributo que quieras usar: por ejemplo, «:card_bin:». Hemos dividido nuestros atributos estándar en cuatro categorías:

• Atributos basados en la frecuencia (útiles para evitar ataques de prueba de tarjetas o cobros fraudulentos con tarjetas)
  
• Atributos basados en los datos de la tarjeta
  
• Atributos basados en los datos de pago
  
• Atributos basados en los datos del cliente
  

Algunos atributos requieren valores como cadenas, mientras otros requieren valores como números. Hemos incluido un ejemplo de cada atributo para que veas cómo funciona cada caso. Si el atributo requiere una cadena (como, por ejemplo, :card_bin: ), verás en el ejemplo que los números están entre comillas simples (‘ ’): :card_bin: = ‘424242’. Si el atributo requiere un número, no tendrá esas comillas: por ejemplo, :amount_in_usd: > 250.

Atributos basados en la frecuencia

Hay cuatro tipos de atributos basados en la frecuencia que son particularmente útiles para prevenir el fraude por robo de tarjetas (como, por ejemplo, los cobros fraudulentos o los ataques de prueba de tarjetas).

1. Authorization: se basa en autorizaciones del emisor
   
2. Charge: se basa en cargos
   
3. Decline: se basa en rechazos del emisor
   
4. Block: se basa en bloqueos realizados por el machine learning de Radar
   

También hay atributos basados en el resultado de cargos, como las autorizaciones (en función de si el emisor ha autorizado correctamente un cargo), cargos (en función de los intentos de cargo), rechazos (en función de los cargos que ha rechazado el emisor), disputas (en función de cuántas transacciones disputadas han sido identificadas como fraudulentas) y bloqueos (basados en los cargos bloqueados por el machine learning de Radar). Los resultados se combinan con los datos de un cliente (correo electrónico, dirección IP, nombre o ID de cliente) para formar un atributo.

Además, puedes combinar la frecuencia de los datos de un cliente (correo electrónico, nombre) con la tarjeta o dirección IP utilizada en una transacción. Dicho de otro modo, hay disponibles dos tipos de reglas de frecuencia:

1. Basadas en el resultado del cargo (p. ej., authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) donde el resultado es una autorización correcta, un intento de cargo, rechazos, disputas, bloqueos
   
2. Basadas en vínculos entre la información del cliente y una tarjeta o IP (p. ej., name_count_for_card_weekly, email_count_for_ip_hourly)
   

Las reglas de frecuencia excluyen el pago que estés procesando en ese momento. Por ejemplo, authorized_charges_per_email_hourly representa la cantidad de intentos anteriores realizados correctamente de un correo electrónico en la hora anterior. De modo que, para el primer intento de cargo en una hora dada para un correo electrónico, authorized_charges_per_email_hourly tiene un valor de 0. Si el primero se realiza correctamente, el segundo intento de cargo dentro de la misma hora de ese correo electrónico tiene un valor de 1, y así sucesivamente.

Atributos basados en los datos de tarjeta

Atributos basados en los datos de pago

Atributos basados en los datos del cliente

Aquí tienes un ejemplo de cómo usar estos atributos estándar:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Con esta regla, cualquier cargo de una tarjeta emitida en Canadá, Alemania o los Emiratos Árabes Unidos se bloqueará.

Tipo 3

Atributos de metadatos: estos atributos dependerán de qué metadatos envíes a Stripe. Con estos atributos tienes que usar dos puntos dobles, es decir, dos veces antes y dos veces después de los atributos: ::Customer Age::. Los atributos de metadatos pueden funcionar como cadenas o como números. Cuando se usan como cadenas, los atributos de metadatos distinguen entre mayúsculas y minúsculas.

Los metadatos pueden usarse para crear reglas muy potentes, como poner cargos en revisión manual según los tipos de producto que incluye el pedido o reducir la fricción en los pagos de clientes recurrentes. Para obtener más información sobre cómo definir más metadatos, consulta esta guía.

Los atributos de metadatos se escriben con la siguiente estructura:

• ::[metadata attribute name]:: [operator] [metadata_value]
  

Supongamos que tienes pagos con los siguientes datos almacenados como metadatos:

Puedes escribir una regla para enviar los pagos que coincidan a la fase de revisión manual.

• Review if ::Customer Age:: < 30
  

También puedes escribir reglas usando atributos de metadatos además de los otros tipos de atributos que hemos mencioando en este documento. Por ejemplo, puedes escribir una regla que solo ponga un pago en revisión si el identificador del artículo es 5A381D y el importe del pago es superior a 1000 USD.

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

Los atributos de metadatos también admiten el operador IN para comparar con distintos valores. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si la categoría del identificador del producto es «alimentación», «electrónica» o «ropa».

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

El operador INCLUDES puede utilizarse con reglas para los atributos de metadatos y otros atributos de cadena para coincidir con subcadenas. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si el ID de la partida incluye la cadena A381. Esto coincide con “A381”, “5A381D”, “A381D”, “5A381”, etc.

• Review if ::Item ID:: INCLUDES 'A381'
  

A los metadatos también se puede acceder en objetos de destino y cliente (si se utilizan para un pago determinado). Estos atributos se escriben con la siguiente estructura:

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

Supongamos que tienes un cliente con los siguientes metadatos:

Podrías escribir una regla que siempre permita pagos de clientes de confianza, es decir, si el campo de metadatos «Trusted» del cliente es «true».

• Allow if ::customer:Trusted:: = 'true'
  

O si tuvieras un destino con los siguientes metadatos:

Podrías escribir una regla que ponga un pago en revisión si el campo de metadatos Category de destino es new.

• Review if ::destination:Category:: = 'new'
  

Cómo usar listas guardadas en tus reglas

Puedes hacer referencia a un grupo de valores en tus reglas a través de listas creadas anteriormente. Por ejemplo, puedes usar tus listas de bloqueo (block lists) o las listas de autorización (allow lists) para incluir grupos de clientes en tus reglas. Si estás intentado bloquear una lista de correos electrónicos, te será mucho más fácil crear una lista de bloqueo en lugar de crear varias reglas para cada correo electrónico que quieras bloquear.

Toda la lista de alias referenciados en las reglas deben comenzar con @. Para crear una regla que haga referencia a una lista, debes seguir la siguiente estructura:

• {action} [attribute] in [list]
  

Por ejemplo, supongamos que tienes una lista de países de tarjetas que te gustaría bloquear. Podrías escribir una regla usando varias cláusulas OR:

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

También podrías escribir una regla usando una lista en línea:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Si lo prefieres, podrías crear una lista de países de tarjetas que te gustaría bloquear, denominada card_countries_to_block. A continuación, puedes añadir a la lista los países que elijas y hacer referencia a esa lista en una regla:

• Block if :card_country: in @card_countries_to_block
  

La regla que usa una lista no es solo más concisa, sino que es más fácil editarla y añadirle un gran número de elementos.

Cómo escribir reglas complejas con varias condiciones

Puedes crear reglas complejas combinando condiciones básicas con el uso de los operadores AND, OR y NOT. También puedes usar sus símbolos equivalentes &&, || y ! respectivamente. De forma similar a los lenguajes de programación, como C, Python y SQL, Stripe admite el operador estándar precedence (orden de las operaciones). Por ejemplo, la condición compleja:

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

se interpreta como:

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

También se pueden agrupar subcondiciones dentro de condiciones complejas con paréntesis. De hecho, el ejemplo anterior puede modificarse para cambiar explícitamente el orden de evaluación de los subpredicados:

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

Al usar paréntesis en diferentes posiciones, cada una de estas condiciones complejas genera resultados distintos.

También puedes usar la función is_missing en las conjunciones OR o AND:

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

O puedes usar la función is_missing cuando no falte; en este caso, si bloquea pagos en caso de que :ip_country: NO falte y de que la dirección IP sea de EE. UU. o PR.

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

Reglas de backtesting

Una pieza fundamental del análisis de reglas es encontrar el equilibrio entre prevenir el fraude y bloquear transacciones legítimas o falsos positivos. El backtesting ayuda a identificar reglas que coincidan con el riesgo que quieres asumir o que consigan el equilibrio adecuado entre las disputas evitadas y cualquier aumento de falsos positivos. Para calcular el impacto de una regla, puedes realizar este backtesting combinando datos de transacciones de los últimos seis meses a través del Dashboard de Radar y realizar análisis más específicos para calcular cuáles hubiesen sido los resultados de una regla si se hubiera aplicado recientemente.

Cómo realizar el backtesting desde el Dashboard

Las definiciones de qué es lo que constituye un pago fraudulento y otros pagos realizados correctamente difieren según el tipo de regla que estés probando:

Regla de bloqueo

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude o cargos realizados correctamente puestos en revisión que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente: cargos realizados correctamente que no se disputaron ni reembolsaron por fraude o cargos realizados correctamente puestos en revisión y que no se disputaron ni reembolsaron por fraude

• Intentos de pago fallidos: rechazados por el emisor o bloqueados por Radar

Regla de revisión

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente: cargos realizados correctamente que no se disputaron ni reembolsaron por fraude

• Fallido o puesto ya en revisión: rechazado por el emisor, bloqueado por Radar, o cargos realizados correctamente puestos en revisión (independientemente de si el estado es en disputa o reembolsado)

Regla de permiso

• Bloqueado por Stripe o por tus reglas personalizadas: cargos bloqueados por Radar

• Disputados, con alerta de fraude preventiva recibida o reembolsados por fraude: cargos realizados correctamente que se disputaron o reembolsaron por fraude o cargos realizados correctamente puestos en revisión que se disputaron o reembolsaron por fraude

• Otros pagos realizados correctamente o rechazados por el banco: rechazados por el emisor, cargos realizados correctamente que no se disputaron ni reembolsaron por fraude, o cargos realizados correctamente puestos en revisión y que no se disputaron ni reembolsaron por fraude

Cómo realizar análisis de backtesting personalizados

La función de backtesting del Dashboard de Radar se centra en los últimos seis meses de transacciones e incluye disputas, alertas de fraude preventivas y cargos reembolsados como fraudulentos.

Quizá quieras realizar un análisis más específico si, por ejemplo, estás en riesgo de ser identificado en un programa de Visa para la supervisión del fraude (centrado exclusivamente en advertencias de fraude preventivas) o has notado un pico reciente de fraude procedente de un país de IP o tipo de monedero concretos. Para ello, puedes crear una consulta SQL en Sigma o exportar y analizar informes de datos de pagos en el Dashboard. El backtesting personalizado ofrece flexibilidad en las franjas de tiempo (más de seis meses) y análisis más específicos (por ejemplo, puedes centrarte únicamente en disputas o en alertas de fraude preventivas (AFP) La consulta de ejemplo que aparece a continuación realiza backtesting en las alertas de fraude preventivas (AFP) de Visa en transacciones que superen los 100 dólares si has detectado que el volumen de fraude ha estado aumentando últimamente y que las transacciones de puntuación de riesgo elevado crearon el riesgo de entrar al programa de supervisión:

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

El backtesting de los últimos 60 días mediante la creación de una fecha de alerta de fraude preventiva (AFP) se centra en el fraude más reciente, mientras el backtesting de los últimos 60-120 días de ventas no fraudulentas permite que un análisis más general del fraude.

Vectores de fraude habituales

La mayoría de los estafadores siguen un patrón común a la hora de cometer un fraude. En primer lugar, validan la información de pago robada (por ejemplo, los datos de las tarjetas). Una vez que se ha validado que funcionan, usan estas credenciales para comprar productos físicos para uso personal o para la reventa (artículos de lujo o aparatos electrónicos), servicios (como pedidos de comida a domicilio) o, incluso, herramientas que les ayuden a seguir cometiendo fraude (como servicios de alojamiento web, servicios de envío de SMS, etc.).

Sigue leyendo para conocer más detalles sobre algunos de los vectores de fraude más comunes y obtener sugerencias sobre cómo usar las reglas de Radar para mitigarlos.

Ataques de prueba de tarjetas

Los ataques de prueba de tarjetas tienen lugar cuando los estafadores usan scripts o procesos manuales para probar si los números de tarjetas robadas sin procesar aún están operativos. Esta fase del fraude no pretende conseguir un servicio o producto físico, sino validar que las tarjetas están activas. Estos cargos suelen corresponderse con autorizaciones o transacciones de menos de un dólar. Por lo general, las pruebas se llevan a cabo con una secuencia rápida y a gran velocidad. Los atributos que pueden ser útiles son las funciones de agrupación y velocidad, como las siguientes:

• total_charges_per_customer

• cards_per_email_address

• cards_per_ip_address

• total_charges_per_ip

Los estafadores normalmente intentan eludirlas creando correos electrónicos falsos con patrones reconocibles. Los estafadores con más experiencia enmascaran las direcciones IP o incluso cuentan con varios dispositivos. Por tanto, es importante reconocer el comportamiento típico de un cliente legítimo. Algunas características (como el dominio del correo electrónico o el país de la dirección IP, entre otras) pueden ayudar a identificar transacciones que plantean más riesgos. Muchos cliente fraudulentos usan dominios de correo electrónico populares de proveedores consolidados, como gmail.com. Puede que veas dominios como gmail.comms o gomail.co, que tratan de enmascarar la identidad de los estafadores. El país de la tarjeta y el de la IP también pueden servir para segmentar clientes y garantizar que las transacciones proceden de las regiones típicas de tu cartera de usuarios. Es conveniente que revises o bloquees las transacciones que no procedan de dichas regiones.

Una última funcionalidad para frenar este comportamiento de prueba es implementar CAPTCHA.

En Stripe Checkout, los desafíos de CAPTCHA se activan automáticamente cuando el machine learning detecta un ataque de prueba de tarjetas. Para mitigar la prueba de tarjetas, Stripe usa una serie de controles automatizados y manuales, como limitadores de velocidad, alertas y revisiones continuas con modelos de entrenamiento de prueba de tarjetas para detectar los ataques automáticamente. Estos modelos solo activan este tipo de comprobaciones cuando hay un ataque de prueba de tarjetas en curso, por lo que esos usuarios reales casi nunca ven un CAPTCHA. Gracias a esto, la prueba de tarjetas en las empresas que usan Checkout se ha reducido un 80 %, una cifra espectacular, sin percibir prácticamente ningún impacto en la conversión.

Ten en cuenta que también puedes escribir reglas personalizadas como «Bloquear si se rechaza más de 3 veces desde una dirección IP dada» para reducir los ataques de pruebas de tarjetas.

Obtención de valor

Tarjetas de crédito robadas (nuevos usos de una tarjeta)

En este vector de fraude, el actor fraudulento usa la tarjeta robada validada en su dispositivo personal o en un dispositivo utilizado para cometer fraude.

Se suele hacer un uso abusivo de este vector ya sea a través de ataques masivos generados por scripts o, a una escala más pequeña, con objetivos de fraude más pequeños. En cualquier caso, usar atributos de reglas que miden la novedad de una cuenta en Stripe, como email_first_time_seen_on_stripe, en combinación con risk_score y otras funciones, mantienen a raya a estos nuevos titulares de tarjetas. Además, las restricciones de velocidad en IP, correos electrónicos y tarjetas pueden proteger más a los comerciantes de ataques más grandes donde los actores fraudulentos estén intentando monetizar las credenciales robadas lo más rápido posible.

Tarjetas de crédito robadas (enmascaramiento de los datos)

En este vector de fraude, el actor fraudulento usa la tarjeta robada validada en su dispositivo personal o en un dispositivo utilizado para cometer fraude o el actor fraudulento ha vulnerado una cuenta de suscripción y accedido a la información de la tarjeta de crédito almacenada en la cuenta.

El actor fraudulento intentará hacer lo posible por enmascarar su presencia al:

• usar el mismo nombre que en anteriores transacciones completadas;

• usar la misma dirección de facturación que en anteriores transacciones completadas;

• usar una VPN para intentar que se parezca a la del titular de la tarjeta original. Pueden tener una VPN en la misma ciudad y, en ocasiones, en la misma calle;

• cambiar solo pequeños detalles, como la dirección de correo electrónico o el número de teléfono;

• cambiar la dirección de envío de transacciones previas, para un producto físico, potencialmente con una gran diferencia en la distancia entre la dirección de facturación y la de envío. Esta es una señal no estricta.

El comportamiento de enmascaramiento descrito anteriormente dificulta analizar quién está realmente realizando la transacción, ya sea el titular de la tarjeta original o un actor fraudulento que ha vulnerado la cuenta. Esto suele significar que este tipo de fraude pasa desapercibido durante más tiempo, tanto para el comerciante como para el titular original de la tarjeta.

Aquí la estrategia sería la misma: el actor fraudulento intentará extraer el máximo valor posible de las credenciales robadas. Las reglas que usan funciones para limitar la velocidad, junto con riskscore, cvccheck o fallos en comprobaciones de zip, pueden ayudar a protegerse de este comportamiento.

Cómo analizar tu fraude para crear las reglas adecuadas

Revisiones de fraude

Para elaborar reglas más eficaces, debes comprender al detalle la actividad fraudulenta de tu cuenta. Es importante caracterizar los diferentes tipos de vectores de fraude presentes. Puedes hacerte las siguientes preguntas:

• ¿Las cuentas se registran y comienzan de inmediato a realizar compras fraudulentas mediante correos electrónicos y nombres de titular de cuenta nuevos?

• ¿Están los actores fraudulentos accediendo a cuentas antiguas y realizando compras de cantidades inusualmente grandes?

• ¿Hay variaciones en el fraude dependiendo de las redes de tarjetas o países de tarjetas específicos?

• ¿Se produce fraude a gran velocidad, lo que significa que se hacen varios intentos con la misma tarjeta, correo electrónico o dirección IP en un breve espacio de tiempo?

Si revisamos la alta velocidad en la que tiene lugar el fraude en la captura de pantalla anterior, las reglas que utilizan authorized_charges_per_card_number_hourly o authorized_charges_per_ip_address_hourly podrían detener este vector de fraude.

Otras prácticas recomendadas

Aquí tienes algunos consejos para mejorar la redacción de reglas en Radar:

La importancia de usar Stripe.js

• Incluye stripe.js en la ruta de pagos para señalizar el fraude al máximo
  
• Para sacarle todo el partido a Radar sin que ello en el tiempo de carga de las páginas, carga stripe.js de forma asíncrona en las páginas que no sean de pago
  
• Lo más sencillo es ponerlo junto a las etiquetas de script de Google Analytics
  
• El tamaño completo de stripe.js es de 29,6 kb (comprimido mediante gzip)
  
  • En un futuro, radar.js se podrá incluir de forma separada de stripe.js
    

Conclusión

Las reglas pueden ser una herramienta extraordinariamente poderosa para ayudarte a personalizar tu protección contra el fraude. Al implementar una lógica única, con la información proporcionada en algunas de las mejores prácticas que se indican en esta guía, puedes crear una configuración de prevención del fraude en Radar específica para las necesidades de tu empresa.

Si quieres consultar más información sobre Radar for Fraud Teams, puedes hacerlo aquí.

Si ya utilizas Radar for Fraud Teams, echa un vistazo a la página Reglas de tu Dashboard para comenzar a escribir reglas.

Otras notas

Radar para plataformas

¿Eres una plataforma que usa Stripe Connect? Si es así, cualquier regla que crees solo se aplicará a los pagos creados en la cuenta de la plataforma (en los términos de Connect, estas son cargos destination o on-behalf-of).
Los pagos creados directamente en la cuenta conectada están sujetos a las reglas de la cuenta.

Radar for Terminal

Radar no detecta los cargos de Terminal. Esto quiere decir que si usas Terminal, puedes escribir reglas basadas en la frecuencia de IP sin tener que preocuparte de que se bloqueen tus pagos en persona.