Las reglas predeterminadas de Stripe usan machine learning para predecir y bloquear un número 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 para personalizar su protección contra el fraude.

Esta guía cubre diferentes temas relacionados con las reglas de Radar, incluidas más de 100 reglas de Radar que puedes usar, además de mejores prácticas con respecto al backtesting, escritura de reglas y mucho más.

Vamos a empezar.

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

El orden en el que las reglas se ordenan en tu página de Radar es importante. Cada pago se evalúa teniendo en cuenta las reglas que has creado y realizado en el siguiente orden:

1. Request 3DS: las reglas que solicitan autenticación 3D Secure cuando se usan con la API Payment Intents o Checkout. Independientemente de las coincidencias con esta regla, las reglas para permitir, bloquear o revisar se evalúan después.
   
2. Allow: reglas que permiten que un pago se procese. Las reglas de permiso deben implementarse con mucha atención, ya que sobrescriben cualquier otra regla excepto las reglas de 3DS, incluidos los modelos de machine learning de Stripe, y deben usarse con la máxima precaución. Solo los comerciantes que han procesado más de 100.000 USD puede escribir reglas de permiso.
   
3. Block: reglas que bloquean un pago y lo rechazan. Si un pago se rechaza, no se evalúa con respecto a ninguna regla de revisión.
   
4. Review: estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que puedas echarle otro vistazo si quieres.
   

Para poner esto en práctica, usemos las siguientes reglas como ejemplo. Todos los pagos inferiores a 10 USD deberían procesarse. Esto es así porque la primera regla permite el pago, por lo que no se evalúan más reglas. Del mismo modo, si seguimos estas reglas, un pago de 1.500 USD realizado dentro de los Estados Unidos con un nivel de riesgo normal también se permitiría, a pesar de la regla de bloquear pagos de más de 1.000 USD. Esto es así por la segunda regla de la lista, que permite pagos realizados dentro de Estados Unidos y con un nivel de riesgo normal. Una vez que se activa una regla determinada, no se evalúa ninguna regla más.

• 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

Hoja de características clave del lenguaje de las reglas

Las reglas son similares a SQL y hay diferentes operadores que puedes usar en base al tipo de datos que estás usando para crear tu regla. A continuación encontrarás una hoja con las características clave.

Si te gustaría verificar de forma explícita la existencia de un atributo o atributo de metadatos, no uses el operador !=, sino la función is_missing. Proporciona esta función con el atributo o clave de metadatos que pueda faltar. Por ejemplo, podrías escribir una regla para comparar con todos los pagos donde no tienes acceso a la dirección de correo electrónico de un cliente:

• Review if is_missing(:email_domain:)
  

O podrías escribir una regla para coincidir con todos los pagos en los que la dirección de correo electrónico de un cliente es NOT missing:

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

Reglas de Radar de uso frecuente

Esta lista de reglas de Radar de uso frecuente, que no es exhaustiva, se basa en diferentes objetivos.

Reglas que ayudan a prevenir la prueba de tarjetas o cobro de tarjetas

Reglas que ayudan a prevenir el fraude con SKU de riesgo conocidos

Esta regla requiere metadatos o definir información de SKU como descripción del cargo. Estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que puedas echarle otro vistazo.

Reglas que ayudan a evitar el abuso de pruebas de tarjetas prepago

Reglas que podrían ayudar a evitar varias disputas de una tarjeta

Hay tres tipos de atributos para crear reglas

Tipo 1

atributos posteriores a la autorización: están disponibles para que cualquiera los use. Cuando se usan estos atributos, hay que usar dos puntos antes y después de los atributos posteriores a la autorización como :cvc_check:.

A continuación, te indicamos un ejemplo de cómo usar 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 de modo que coincida la primera línea de la dirección de facturación proporcionada con la información que se tiene registrada del titular de la tarjeta. Esto quiere decir que si esta verificación “no está disponible” (‘unavailable’), si el emisor “no verificó” (‘unchecked’) los datos o si el emisor “no proporcionó” (‘not_provided’) los datos, el pago se bloqueará.
  

Tipo 2

atributos estándar: están disponibles para que cualquiera los use. Debes usar dos puntos antes y después de los atributos estándar, como :card_bin: Hemos dividido nuestros atributos estándar en cuatro categorías:

• Atributos basados en la frecuencia: útiles para evitar la prueba de tarjetas o el cobro de 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. A modo de aclaración, hemos incluido un ejemplo para cada atributo. Si el atributo requiere una cadena como :card_bin: necesita, verás en el ejemplo que los números están dentro de ‘ ’. Por ejemplo, :card_bin: = ‘424242’, mientras que si requiere un número, no tendrá ‘ ’ como en :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, pruebas de tarjeta y cobro de tarjetas.

1. Autorización: se basa en autorizaciones del emisor
   
2. Cargo: se basa en cargos
   
3. Rechazos: se basa en rechazos del emisor
   
4. Bloqueo: se basa en bloqueos realizados por el machine learning de Radar
   

También hay atributos basados en el resultado de cargos, incluidas autorizaciones (basadas en autorizaciones correctas del emisor), cargos (basados en los intentos de cargos), rechazos (basados en los rechazos del emisor), disputas (transacciones anteriores disputadas como fraudulentas) y bloqueos (basados en bloqueos realizados 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

A continuación, encontrarás un ejemplo de cómo usar 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 dos veces, antes y después de los atributos estándar, como ::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 el SKU comprado o reducir la fricción para clientes que vuelven. 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 de valor de clave almacenados en el campo de metadatos:

Una regla puede escribirse para colocar pagos que coincidan con los siguientes criterios en la revisión.

• Review if ::Customer Age:: < 30
  

Además, puedes escribir reglas usando atributos de metadatos así como otros atributos admitidos mencionados en este documento. Por ejemplo, puedes escribir una regla que solo ponga un pago en revisión si el ID de la partida coincide con 5A381D y el importe del pago es superior a 1.000 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 el ID de la categoría 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 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 (p. ej., permitir listas, bloquear listas)

Puedes hacer referencia a un grupo de valores en tus reglas a través de listas que previamente hayas creado (p. ej., permitir listas o bloquear listas). Si estás intentado bloquear una lista de correos electrónicos, debes 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')
  

También 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.

Escribe reglas complejas con varias condiciones

Puedes crear condiciones complejas al unir condiciones básicas mediante 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 precedencia (orden de 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 admite la agrupación de subcondiciones dentro de condiciones complejas mediante el uso de paréntesis. Así, 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 ubicaciones, cada una de estas condiciones complejas lleva a distintos resultados.

La función is_missing también puede usarse 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 si el :ip_country: NO falta y la IP es de US o PR.

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

Reglas de backtesting

Como filosofía general para el análisis de reglas, existe un equilibrio entre prevenir el fraude y bloquear transacciones válidas o falsos positivos. Realizar el backtesting ayuda a identificar reglas que coincidan con el riesgo que quieres asumir o que lleguen al equilibrio adecuado entre prevenir disputas y cualquier aumento de falsos positivos. Para calcular el impacto de una regla, puedes realizar backtesting de combinaciones con el uso de datos de transacciones de los últimos seis meses a través del Dashboard de Radar y realizar más análisis específicos para comprender cómo se hubiera comportado la regla de haberse aplicado recientemente.

Cómo realizar backtesting en 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 en el 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, si 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 > $100 si hipotéticamente has detectado que el volumen de fraude ha estado aumentando últimamente y que las transacciones de puntuación de riesgo elevado crearon riesgo 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

Realizar backtesting en 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 que realizar backtesting de los últimos 60–120 días de ventas no fraudulentas permite que el fraude se desarrolle de forma más completa.

Vectores de fraude habituales

La mayoría de los actores fraudulentos siguen un patrón común a la hora de cometer fraude. En primer lugar, validan la información de pago robada (p. ej., las tarjetas). Una vez que se ha validado que funcionan, usan estas credenciales para extraer valor en forma de productos físicos para uso personal o reventa (aparatos electrónicos o productos de lujo), servicios para uso persona lo reventa (servicios de entrega de comida a domicilio) o servicios y productos que ayuden a seguir cometiendo fraude (es decir, servicios de alojamiento web, servicios de envío de SMS no deseados, etc.).

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

Pruebas

Las pruebas de tarjeta tienen lugar cuando los actores fraudulentos usan scripts o procesos manuales para probar si los números de tarjetas robadas sin procesar aún están activos. Esta fase del fraude no tiene como objetivo conseguir un servicio o producto físico, sino validar que las tarjetas están activas. Estos cargos suelen ser de autorizaciones o transacción de menos de un dólar. Por lo general, las pruebas tienen lugar en una rápida sucesión y a gran velocidad. Los atributos que pueden ser útiles son funciones de agrupamiento y velocidad, tales como:

• charge_attempts_per_customer

• cards_per_email_address

• cards_per_ip_address

• charge_attempts_per_ip

Los actores fraudulentos suelen intentar esquivarlas inventando correos electrónicos falsos y usando direcciones de correo electrónico distintivas. Aquellos actores fraudulentos más avanzados enmascararán las direcciones IP o, incluso, tendrán varios dispositivos para proporcionar datos de un único dispositivo. En este punto, resulta importante conocer los comportamientos buenos y habituales de los clientes. Funciones como el dominio del correo electrónico o el país de la dirección IP, entre otras categorías más amplias, puede ayudar a identificar transacciones de alto riesgo. Muchos clientes fraudulentos usarán dominios populares de correo electrónico de proveedores establecidos, como gmail.com. Es posible que veas dominios como gmail.comms, o gomail.co, que tratan de enmascarar la identidad de los actores fraudulentos. El país de la tarjeta y el de la IP también pueden usarse para ayudar a segmentar clientes y asegurar que las transacciones son de áreas típicas de tu base de usuarios. Las transacciones que no estén dentro de estas ubicaciones podrían resultar de interés para su revisión o bloqueo.

Otra ú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 tarjeta. Para atenuar esta prueba de tarjetas, Stripe usa una serie de controles automatizados y manuales, incluyendo limitadores de velocidad, alertas y revisiones en curso junto con modelos de formación de pruebas de tarjetas para detectar automáticamente los ataques. Estos modelos solo activan desafíos cuando hay en curso un ataque de prueba de tarjeta, por lo que esos usuarios reales casi nunca ven un CAPTCHA, solo los bots. Esto ha reducido la prueba de tarjetas para las empresas que usan Stripe Checkout en un impresionante 80 % con un impacto apenas perceptible 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.

Extracción de valor

Tarjetas de crédito robadas (nuevo comportamiento)

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. Sea como fuere, 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 (comportamiento de enmascaramiento)

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 el mismo bloque;

• 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 reglas acordes

Revisiones de fraude

Para elaborar reglas más eficaces, debes comprender en profundidad 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 un sesgo 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 abordar potencialmente este vector de fraude.

Otras mejores prácticas

A continuación, te indicamos otras mejores prácticas que te ayudarán a optimizar la elaboración de reglas en Radar.

La importancia de usar Stripe.js

• Incluye stripe.js en la ruta de pagos completa para señalizar al máximo el fraude
  
• Para aprovechar Radar al máximo sin que ello influya en el tiempo de carga de las páginas, carga stripe.js asíncrono en las páginas que no sean de pago
  
• Es lo más sencillo de poner junto a las etiquetas de script de Google Analytics
  
• El tamaño de agrupación completo de stripe.js es 29,6 kb comprimido mediante gzip.
  
  • Estado 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.