Las reglas predeterminadas de Stripe usan machine learning para predecir y bloquear una cantidad sustancial de pagos fraudulentos. Para las empresas que necesitan más control sobre qué pagos se deben revisar, permitir o bloquear, las reglas son una herramienta sólida de personalización de protección contra fraudes.

En esta guía, abarcamos una variedad de temas relacionados con las reglas de Radar, incluidas más de 100 reglas de Radar que puedes usar, así como prácticas recomendadas en materia de backtesting, escritura de reglas y mucho más.

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

El orden en el que se enumeran las reglas de la página de Radar es importante. Cada pago se evalúa en función de las reglas que hayas creado y puesto en práctica en el siguiente orden:

1. Request 3DS: las reglas que solicitan una autenticación mediante 3D Secure cuando se usan con la API Payment Intents o Checkout. Independientemente de las coincidencias con esta regla las reglas permitir, bloquear o revisar se evalúan después.
   
2. Allow: reglas que permiten que se procese un pago. Estas reglas deben implementarse con muchísimo cuidado, ya que anulan todas las demás, a excepción de las de 3D Secure, 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 USD 100,000 pueden escribir reglas de permiso.
   
3. Block: reglas que bloquean un pago y lo rechazan. Si se rechaza un pago, no se evalúa en función de ninguna regla de revisión.
   
4. Review: estos pagos se siguen procesando, y se cobra al cliente, pero se marcan para que puedas revisarlos si así lo deseas.
   

Para poner esto en práctica, usemos las siguientes reglas como ejemplo. Todos los pagos inferiores de 10 dólares deberían procesarse. Esto es así porque la primera regla permite el pago de USD 1500 realizado dentro de 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 USD 1000. Esto es así por la segunda regla de la lista, que permite pagos hechos desde Estados Unidos y con un nivel de riesgo normal. Una vez que se activa una regla en particular, no se evalúa ninguna regla más.

• Allow payments less than $10 (Permitir pagos menores a USD 10).

• Allow payments within the US and with a risk level of normal (Permitir pagos dentro de EE. UU. con un nivel de riesgo normal).

• Block payments where the risk level is high (Bloquear pagos con un nivel de riesgo alto).

• Block payments greater than $1,000 (Bloquear pagos mayores a USD 1000).

• Review payments with a card issued outside the US (Revisar pagos con tarjetas emitidas fuera de EE. UU.).

Hoja de características clave del lenguaje de las reglas

Las reglas usan un lenguaje similar a SQL y hay diferentes operadores que puedes utilizar según el tipo de datos que uses para crear tu regla. A continuación encontrarás una hoja de referencias clave.

Si deseas verificar de forma explícita la existencia de un atributo o un atributo de metadatos, no uses el operador !=, sino la funciónis_missing. Proporciona esta función con la clave de metadatos o el atributo que pueda faltar. Por ejemplo, si no tienes acceso a la dirección de correo electrónico del cliente, puedes escribir una regla que coincida con todos los pagos:

• Review if is_missing(:email_domain:)
  

O bien, puedes escribir una regla que coincida con todos los pagos en los que la dirección de correo electrónico de un cliente es NOT missing:

_`Review if ismissing(:email_domain:)`

Reglas de Radar de uso frecuente

Esta lista de reglas de Radas que se usan con frecuencia se basa en diferentes objetivos.

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

Reglas que te 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 le cobra al cliente, pero se marcan para que puedas revisarlos nuevamente.

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

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

Existen tres tipos de atributos para crear reglas

Tipo 1

Atributos de posteriores a la autorización: estas reglas están disponibles para su uso general. Si usas estos atributos, debes usar dos puntos (:) antes y después del atributo posteriores a la autorización como :cvc_check:.

A continuación, encontrarás un ejemplo de cómo usar atributos posteriores a la autorización:

• Block if :address_line1_check: != 'pass' Con esta regla, se bloquearán los cargos que no pasen específicamente la verificación del emisor de la tarjeta para que la primera línea de la dirección de facturación proporcionada coincida con la información guardada del titular de tarjeta. Esto significa que si la verificación aparece como ‘unavailable’ («no disponible»); si la información aparece como ‘unchecked’ («no verificada») por el emisor, o si los datos aparecen como ‘not_provided’ («no proporcionados»), se bloqueará el pago.

• Tipo 2
  Atributos estándar: estas reglas están disponibles para su uso general. Necesitas usar dos puntos (:) antes y después de los atributos estándar, como :card_bin:. Dividimos nuestros atributos estándar en cuatro categorías:

• Atributos basados en la frecuencia: son útiles para prevenir las pruebas y los cobros 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 que otros requieren números. Aquí te presentamos un ejemplo de cada atributo para que sea más comprensible. Si el atributo requiere una cadena, como :card_bin:, verás en el ejemplo que el número aparece entre ‘ ’. Por ejemplo, :card_bin: = ‘424242’. Si bien necesita un número, no tendrá ‘ ’, como :amount_in_usd: > 250.

Atributos basados en la frecuencia

Hay cuatro tipos de atributos basados en la frecuencia que son especialmente útiles para prevenir el fraude de tarjetas robadas, la prueba y el cobro de tarjetas.

1. Authorization: atributo basado en las autorizaciones del emisor
   
2. Charge: basado en los cargos
   
3. Decline: basado en los pagos rechazados del emisor
   
4. Block: basado en los bloqueos hechos por el modelo de machine learning de Radar
   

También hay otros atributos basados en los resultados de cobro, como autorizaciones (basado en las autorizaciones exitosas del emisor), cargos (basado en los intentos de cobros), rechazos (basado en los pagos rechazados por el emisor), disputas (basado en las disputas de transacciones marcadas como fraudulentas) y bloqueos (basado en los bloqueos hechos por el modelo de machine learning de Radar. Los resultados se combinan con los datos del cliente (correo electrónico, dirección IP, nombre o ID del cliente) para conformar un atributo.

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

1. Basadas en los resultados del cargo (p. ej., authorized_charges_per_email_hourly, blocked_charges_per_email_hourly), en las que el resultado son autorizaciones, intentos de cobro, pagos rechazados, disputas y bloqueos exitosos.
   
2. Basadas en los vínculos entre la información del cliente y una tarjeta o una dirección IP (p. ej., name_count_for_card_weekly, email_count_for_ip_hourly).
   

Las reglas de frecuencia excluyen los pagos que se están procesando en el momento. Por ejemplo, authorized_charges_per_email_hourly representa la cantidad de intentos de cobro que se realizaron correctamente desde una dirección de correo electrónico en la última hora. Para el primer intento de cobro en una hora determinada para un correo electrónico, authorized_charges_per_email_hourly tiene un valor de 0. En los primeros pagos exitosos, el segundo intento de cobro de ese correo electrónico dentro de la misma hora tiene un valor de 1 y así sucesivamente.

Atributos basados en los datos de la 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, se bloquearán los cobros de una tarjeta emitida en Canadá, Alemania o los Emiratos Árabes Unidos.

Tipo 3

Atributos de metadatos: estos atributos dependerán de los metadatos que envíes a Stripe. Con estos atributos, debes usar dos puntos dobles (::) antes y después de los atributos estándar, p. ej., ::Customer Age::. Los atributos de metadatos pueden operar como cadenas o como números. Si se usan como cadenas, los atributos de metadatos distinguen entre mayúsculas y minúsculas.

Los metadatos pueden usarse para crear reglas sólidas, como colocar los cobros en revisión manual según el SKU que se compró, o reducir la fricción para los clientes frecuentes. Consulta esta guía para aprender cómo pasar más metadatos.

Los atributos de metadatos se escriben con la siguiente estructura:

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

Supongamos que tenemos pagos con los siguientes datos de clave/valor almacenados en el campo metadatos:

Puedes escribir una regla para colocar los pagos que coincidan con el siguiente criterio en revisión.

• Review if ::Customer Age:: < 30
  

Puedes escribir reglas con atributos de metadatos y otros atributos compatibles mencionados en este documento. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si el ID del ítem es 5A381D y el monto del pago supera los USD 1000.

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

Los atributos de metadatos también admiten que el operador IN coincida con varios valores. Por ejemplo, puedes escribir una regla que coloque un pago en revisión si el ID de la categoría es «almacén», «electrónicos» o «ropa».

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

El operador INCLUDES puede usarse con reglas de atributos de metadatos y otros atributos de cadena para que coincidan con cadenas secundarias. Por ejemplo, puedes escribir una regla que coloque un pago en revisión si el ID de ítem incluye la cadena A381, como «A381», «5A381D», «A381D», «5A381» y más.

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

También se puede acceder a los metadatos en los objetos destino y clientes (si son los que se usan para un pago determinado). Estos atributos se escriben con la siguiente estructura:

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

Supongamos que tienes un cliente con los siguientes metadatos:

Puedes escribir una regla que siempre permita pagos si el campo de metadatos Trusted del cliente es true.

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

O bien, si tienes un destino con los siguientes metadatos:

Puedes escribir una regla que coloque el pago en revisión si el campo de metadatos Category del 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 creadas previamente (p. ej., permitir listas o bloquear listas). Si deseas 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 desees bloquear.

Todos los alias de listas a los que se haga referencia deben comenzar con @. Para crear una regla que haga referencia a una lista, utiliza la siguiente estructura:

• {action} [attribute] in [list]
  

Por ejemplo, supongamos que tienes una lista de países emisores de tarjetas que deseas bloquear. Puedes escribir una regla con varias cláusulas OR:

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

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

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

También puedes crear una lista de países emisores de tarjetas que desees bloquear, denominada card_countries_to_block. A continuación, puedes agregar a la lista los países que elijas y hacer referencia a esta 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 mucho más fácil de editar, y puedes agregarle una gran cantidad de elementos.

¿Cómo escribir reglas complejas con varias condiciones?

Puedes diseñar condiciones complejas uniendo condiciones básicas con operadores AND, OR y NOT. También puedes usar los símbolos equivalentes: &&, || y !, respectivamente. Al igual que los lenguajes de programación como C, Python y SQL, Stripe admite la prioridad de operador estándar (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 admiten los agrupamientos subcondicionales dentro de condiciones complejas con el uso de paréntesis. Por ejemplo, en el ejemplo anterior puede modificarse para que cambie 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})

El uso de paréntesis en diferentes lugares determina que cada una de las condiciones complejas tenga diferentes resultados.

La función is_missing también puede usarse en conjunciones OR o AND:

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

También puedes usar la función is_missing aunque no falte la condición En este caso, si se bloquean los pagos cuando NO falte :ip_country: y la IP sea de Puerto Rico o los EE. UU.

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

Reglas de backtesting

Como regla general para el análisis de reglas, debe existir un equilibrio entre la prevención del fraude y el bloqueo de transacciones legítimas o falsos positivos. El backtesting ayuda a identificar las reglas que caen dentro del nivel de riesgo que una empresa puede aceptar o logran el equilibrio correcto entre la prevención de disputas y el aumento de falsos positivos. Para estimar el impacto de una regla, puedes hacer combinaciones de backtesting con datos de transacciones de los últimos seis meses a través del Dashboard de Radar y realizar análisis más específicos para comprender cómo hubiera funcionado la regla si la acabas de implementar.

¿Cómo realizar Backtesting en el Dashboard?

Las definiciones de lo que constituyen pagos fraudulentos y otros pagos realizados correctamente son diferentes según el tipo de regla que estés probando:

Reglas 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 pagos rechazados: pagos 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 se reembolsaron por fraude.

• Otros pagos realizados correctamente: cargos realizados con éxito que no se disputaron ni reembolsaron por fraude.

• Rechazados o puestos en revisión: pagos rechazados por el emisor o bloqueados por Radar, o cargos realizados correctamente puestos en revisión (independientemente de su estado de disputa o reembolsos).

Regla de permitidos

• Bloqueados 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: cargos rechazados por el emisor o 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 funcionalidad de backtesting en el Dashboard de Radar se enfocan en los últimos seis meses de transacciones e incluyen disputas, alertas de fraude preventivas y cargos reembolsados como fraudulentos.

Tal vez desees realizar un análisis más específico, por ejemplo, si estás en riesgo de que se te identifique en un Programa de monitoreo de Visa (que se enfocan exclusivamente en las advertencias de fraude preventivas) o notas un aumento repentino del fraude proveniente de un tipo de cartera digital o IP de un país en particular. Para ello, puedes crear una consulta de SQL en Sigma o exportar y analizar informes de datos de pagos en el Dashboard. El backtesting personalizado brinda flexibilidad en los períodos (más de seis meses) y análisis más enfocados (por ejemplo, puedes centrarte solo en las disputas o en las EFW). La consulta de ejemplo a continuación hace un backtest de las advertencias de fraude preventivas (EFW) en transacciones superiores a USD 100 si, en teoría, observas que el volumen de fraude aumentó recientemente en mayores valores y que las transacciones con puntuación de riesgo elevada crearon riesgos de ingresar en el programa de monitoreo:

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 el fraude se desarrolle de forma más completa.

Vectores de fraude frecuentes

La mayoría de los estafadores siguen un patrón común a la hora de cometer fraude. Primero, validan la información de pago robada (p. ej., tarjetas). Una vez que validan los datos, usan las credenciales para extraer valor en la forma de bienes físicos para uso personal o reventa (bienes de lujo o electrónicos), servicios de uso personal o reventa (servicios de entrega de alimentos) o servicios y productos que ayudan a cometer más fraudes (es decir, servicios de hosting web, servicios de mensajería de correos no deseados, etcétera).

Sigue leyendo para obtener más información sobre los vectores de fraude más frecuentes y obtener sugerencias sobre cómo usar las reglas de Radar para mitigarlos.

Pruebas

La prueba de tarjetas sucede cuando los estafadores usan códigos o procesos manuales para probar si los números de tarjetas robadas siguen activos. Esta etapa del fraude no se trata de obtener un servicio o un bien físico, sino de validar si las tarjetas están activas. Estos cargos suelen ser autorizaciones o transacciones por valores en dólares bajos. Las pruebas suelen ocurrir rápidamente. Los atributos que pueden ser útiles son las funcionalidades de velocidad y agrupamiento, tales como los siguientes:

• total_charges_per_customer

• cards_per_email_address

• cards_per_ip_address

• total_charges_per_ip

Por lo general, los estafadores intentarán evitar estos atributos con correos electrónicos falsos y direcciones diferentes. Los estafadores más experimentados enmascaran las direcciones de IP o incluso tendrán varios dispositivos para proporcionar datos de dispositivo únicos. En ese punto, es muy importante conocer los comportamientos de clientes típicos y correctos. Las funcionalidades como el dominio del correo electrónico y el país de la IP, entre otras categorías más amplias, pueden ayudar a identificar transacciones con riesgo más alto. Muchos clientes fraudulentos utilizarán dominios de correo electrónico populares de proveedores de correo electrónico establecidos, como gmail.com. Es posible que veas dominios como gmail.comms o gomail.co, que intentan enmascarar la identidad de estafadores. El país de la tarjeta y de la IP pueden usarse para segmentar clientes y garantizar que las transacciones sean de áreas típicas de tu base de usuarios. Es posible que las transacciones fuera de estas ubicaciones sean de interés para su revisión o bloqueo.

Una última funcionalidad para evitar este comportamiento de pruebas es implementar un código CAPTCHA.

En Stripe Checkout, los desafíos CAPTCHA aparecen automáticamente cuando nuestro modelo de machine learning detecta ataques de prueba de tarjetas. Para reducir las pruebas de tarjetas, Stripe usa una serie de controles manuales y automáticos, incluidos limitadores de frecuencia, alertas y revisiones continuas junto a modelos de prueba de tarjetas para detectar ataques automáticamente. Estos modelos solo muestran desafíos CAPTCHA cuando un ataque de prueba de tarjetas se encuentra en curso para que solo los bots vean un CAPTCHA y casi nunca lo hagan los usuarios reales. Gracias a esto, los ataques de prueba de tarjetas en las empresas que usan Stripe Checkout se redujeron un 80 %, una cifra espectacular, sin que prácticamente hubiese ningún efecto detectable en la conversión.

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

Extracción de valor

Tarjetas de crédito robadas (nuevo comportamiento)

En este vector de fraude, el estafador usa la tarjeta robada validada en su dispositivo personal o un dispositivo que se utiliza para cometer fraude.

Este vector suele usarse de forma abusiva a través de ataques masivos con código o, a pequeña escala, con redes y bolsillos de fraude más orientados. De todas formas, existen atributos de reglas que miden qué tan nueva es una cuenta en Stripe, como email_first_time_seen_on_stripe, que junto a risk_score y otras funcionalidades mantienen a estos nuevos titulares de tarjetas a raya. Además, las restricciones de velocidad sobre direcciones IP, correos electrónicos y tarjetas pueden proteger mejor a los comerciantes de ataques por volumen en los que los estafadores intentan monetizar credenciales robadas lo más rápido posible.

Tarjetas de crédito robadas (comportamiento de enmascaramiento)

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

El estafador intentará enmascarar su presencia a través de las siguientes acciones:

• Usando el mismo nombre que en las transacciones completadas previamente.

• Usando la misma dirección de facturación que en las transacciones completadas previamente.

• Usando una VPN para que parezca que es el titular original de la tarjeta. Es posible que configure la VPN en la misma ciudad y hasta en la misma cuadra.

• Cambiando solo un pequeño detalle, como la dirección de correo electrónico o el número de teléfono.

• Cambiando 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á realizando la transacción en realidad, ya sea el titular de la tarjeta original o un estafador 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 es la misma: el estafador intentará extraer el máximo valor posible de las credenciales robadas. Las reglas que usan funcionalidades para limitar la velocidad, junto con riskscore, los fallos de comprobaciones de cvccheck, o los fallos de comprobaciones de zip, pueden ayudarte a protegerte de este comportamiento.

¿Cómo analizar tu fraude para crear reglas acordes?

Revisión de fraude

Para crear reglas más efectivas, debes comprender profundamente la actividad de fraude en tu cuenta. Es importante caracterizar los diferentes tipos de vectores de fraude presentes. Algunas preguntas que puedes formular:

• ¿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 estafadores 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 período breve?

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 prácticas recomendadas

Estas son algunas prácticas recomendadas que te ayudarán a optimizar la elaboración de reglas de Radar.

La importancia del uso de Stripe.js

• Incluye Stripe.js en la ruta de pagos completa para marcar la mayor cantidad de 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 de 29.6 kb comprimido con gzip.
  
  • Estado futuro: Radar.js puede incluirse por separado de Stripe.js.
    

Conclusión

Las reglas pueden ser una herramienta extremadamente sólida de personalización de protección contra fraudes. A través de la implementación de una lógica única, con la información proporcionada en algunas de las prácticas recomendadas que se indican en esta guía, puedes crear una configuración de prevención de fraude en Radar específica para las necesidades de tu empresa.

Puedes obtener más información sobre Radar for Fraud Teams aquí.

Si ya eres usuario de Radar for Fraud Teams, consulta la página Reglas en el Dashboard para empezar a escribirlas.

Otras notas

Radar para plataformas

¿Tienes una plataforma que usa Stripe Connect? Si es así, las reglas que creas solo se aplican a los pagos creados en la cuenta de la plataforma (en términos de Connect, se trata de cargos de destination
o on-behalf-of). Los pagos que se crean directamente en la cuenta conectada están sujetos a las reglas de esa cuenta.

Radar for Terminal

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