Radar for Fraud Teams: introducción a las reglas de Radar

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 las prácticas recomendadas con respecto al backtesting, la escritura de reglas y mucho más.

Radar
Radar

Combate el fraude con la solidez de la red de Stripe.

Más información 
  1. Introducción
  2. La importancia del orden y la jerarquía en las reglas
  3. Simbología básica del lenguaje de las reglas
    1. Redactar reglas con lenguaje natural
  4. Reglas de Radar de uso común
    1. Reglas que contribuyen a evitar las pruebas de tarjetas o el cobro de tarjetas
    2. Reglas que ayudan a prevenir el fraude en función del tipo de producto
    3. Reglas que ayudan a evitar el fraude con tarjetas prepago
  5. Analizar la situación de fraude que sufres antes de crear reglas
    1. Revisión de los fraudes
    2. Conoce mejor cuáles son los motores del fraude
  6. Los tres tipos de atributos en la creación de reglas
    1. Tipo 1
    2. Tipo 2
    3. Atributos basados en la frecuencia
    4. Atributos basados en los datos de tarjeta
    5. Atributos basados en los datos de pago
    6. Atributos basados en los datos del cliente
    7. Tipo 3
  7. Cómo usar listas guardadas en tus reglas
  8. Cómo escribir reglas complejas con varias condiciones
  9. Reglas de backtesting
    1. Cómo hacer el backtesting desde el Dashboard
    2. Cómo realizar análisis de backtesting personalizados
  10. Vectores de fraude habituales
    1. Pruebas
    2. Extracción de valor
  11. Otras prácticas recomendadas
    1. La importancia de usar Stripe.js
  12. Conclusión
    1. Otras notas

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). 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:

Operador
Cadena
Metadatos
País
Numérico
Descripción
Ejemplo
=
Igual a

:card_country: = 'us'

!=
No igual a

:card_funding: != 'prepaid'

<
Menor que

:amount_in_gbp: < 10.00

>
Mayor que

:amount_in_usd: > 500.00

<=
Inferior o igual a

:amount_in_eur:<= 100.00

>=
Superior o igual a

:amount_in_cad: >= 10.00

IN
Está en el grupo

:card_country: IN ('gb', 'ie')

INCLUDES
Contiene la cadena

:ip_address: INCLUDES '192.168'

LIKE
Coincide con el patrón indicado

:email: LIKE 'fraud%@stripe.com'

Si quieres comprobar específicamente si existe un atributo o un atributo de metadatos, no utilices el operador !=, sino la función is_missing. Debes introducir en esta función el atributo o la clave de metadatos que pueda faltar. Por ejemplo, puedes escribir una regla que coincida con todos los pagos en los que no tengas acceso a una dirección de correo electrónico del cliente:

  • Review if is_missing(:email_domain:)

También podrías escribir una regla que coincida con todos los pagos para los cuales NO falte la dirección de correo electrónico del cliente:

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

Redactar reglas con lenguaje natural

Si prefieres escribir las reglas de una manera más sencilla o no sabes con seguridad qué atributos hay que usar para actuar sobre una situación de fraude específica, el Asistente de Radar, que funciona gracias a la IA, se ocupará de traducir tus solicitudes escritas en lenguaje natural y las transformará en reglas expresadas en la sintaxis de Radar. También puedes hacer el backtesting de la regla antes de implementarla directamente desde el Asistente de Radar, para comprobar qué resultados habría obtenido respecto a un historial de datos.

Reglas de Radar de uso común

Esta lista contiene algunas las reglas más habituales en Radar, enfocadas a distintos objetivos.

Reglas que contribuyen a evitar las pruebas de tarjetas o el cobro de tarjetas

Block if :total_charges_per_ip​_address_hourly: > 1

Esta regla es útil con los ataques de prueba de tarjetas. Bloqueará los cargos si una dirección IP ya se ha autorizado más de una vez en la última hora.

Block if :blocked_charges_per_ip​_address_hourly: > 1

Si quieres evitar de forma más agresiva los ataques de prueba de tarjetas, utiliza esta regla junto con :total_charges_per_ip_address_hourly:

Block if :total_charges_per​_card_number_hourly: > 1

Esta regla es útil para evitar cobros fraudulentos de tarjetas. Bloqueará los cargos si se ha autorizado correctamente un número de tarjeta en tu cuenta más de una vez en la última hora.

Block if :blocked_charges_per_card​_number_hourly: > 1

Si quieres evitar de forma más agresiva los cobros fraudulentos de tarjetas, utiliza esta regla junto con :total_charges_per_card_number_hourly:

Block if :address_zip_check: != 'pass'

Asegúrate de que recopilas los códigos postales en tu formulario del proceso de compra para usar esta regla. Esta regla bloqueará los cargos si el emisor de la tarjeta no puede validar el código postal proporcionado con el que tienen registrado para la tarjeta.

Block if :cvc_check:: != 'pass'

Asegúrate de que recopilas el CVC en tu formulario del proceso de compra para usar esta regla. Esta regla bloqueará los cargos si el emisor de la tarjeta no puede validar el código CVC (o CVV) proporcionado con el que tienen registrado para la tarjeta.

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.

Review if ::SKU Category:: IN ('baby formula', 'personal hygiene')

Supongamos que eres un supermercado y nos envías metadatos con la categoría de SKU. Has observado que los pedidos que contienen artículos de higiene personal o fórmula para bebés (es decir, los productos marcados con la categoría de SKU «personal hygiene» o «baby formula») tienden a presentar más riesgos. Esta regla colocará cualquier pedido que contenga esos artículos en la lista de revisión manual del Dashboard de Stripe para que puedas hacer un seguimiento. Ten en cuenta que estos pagos siguen procesándose y que se cobra al cliente a menos que canceles manualmente el pedido.

Review if :charge_description: = 'Trial class'

Supongamos que das clases online y ofreces clases de prueba o paquetes de diez clases (es decir, has configurado dos productos: «Trial class» y «10 class package») y que envías a Stripe el nombre del producto como la descripción del cargo. Esta regla colocará todos los pedidos en los que la descripción del cargo sea exactamente «Trial class» en la lista de revisión manual del Dashboard de Stripe para que puedas hacer un seguimiento. Ten en cuenta que estos pagos siguen procesándose y que se cobra al cliente a menos que canceles manualmente el pedido.

Reglas que ayudan a evitar el fraude con tarjetas prepago

Block if :card_funding: = 'prepaid' OR :card_funding: = 'unknown'

Supongamos que eres un comercio minorista que ofreces la posibilidad de que el cliente pruebe el artículo en su casa antes de pagar. En las últimas semanas, has observado un aumento de casos de fraude que utilizan tarjetas prepago en las que luego no puedes efectuar cargos. Esta regla bloqueará cualquier pedido que no se pague con una tarjeta de crédito o débito.

Analizar la situación de fraude que sufres antes de crear reglas

Revisión de los fraudes

Si aspiras a diseñar reglas verdaderamente eficaces, tienes que conocer a fondo la actividad fraudulenta que se desarrolla en tu cuenta. Es fundamental que conozcas los rasgos característicos de cada vector de fraude que haya presente. Plantéate estas cuestiones:

  • ¿Resulta que hay cuentas que se ponen a hacer compras fraudulentas nada más crearse, utilizando direcciones de correo electrónico y nombres de titulares nuevos?

  • ¿Hay estafadores que acceden a cuentas ya veteranas y hacen compras con importes inusualmente elevados?

  • ¿El fraude se centra sobre todo en redes de tarjetas concretas o en países determinados?

  • ¿Detectas fraudes a alta velocidad, con varios intentos desde la misma tarjeta, dirección de correo o dirección IP durante intervalos de tiempo muy cortos?

Si revisamos el fraude a alta velocidad que se produce en la captura de pantalla anterior, veremos que las reglas que utilizan authorized_charges_per_card_number_hourly o authorized_charges_per_ip_address_hourly podrían actuar sobre este vector de fraude.

Conoce mejor cuáles son los motores del fraude

La información sobre los métodos de fraude te ayudará a detectar rápidamente los orígenes de cada fraude y actuar sin que sea necesario analizar manualmente los datos de las transacciones. La pestaña Insights tab del Dashboard te presenta los atributos más destacados asociados a transacciones fraudulentas. A continuación, puedes agregar una regla que actúe sobre cada atributo afectado, directamente desde la pestaña Insights.

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:».

Atributos
Descripción

:address_line1_check:

El emisor de la tarjeta verifica la primera línea de la dirección de facturación (que, normalmente, será el nombre de la calle y el número) con la información que tiene registrada para el titular de la tarjeta.

:address_zip_check:

El emisor de la tarjeta verifica el código postal con la información que tiene registrada para el titular de la tarjeta.

:cvc_check​:

El emisor de la tarjeta compara el CVC proporcionado (que a veces se conoce como CVV) con la información que tiene registrada para el titular de la tarjeta.
Posibles valores
Descripción

pass

Los datos proporcionados son correctos.

fail

Los datos proporcionados no son correctos.

unavailable

El emisor de la tarjeta del cliente no verificará los datos proporcionados. No todos los emisores de tarjetas ni todos los países admiten la verificación de la dirección.

unchecked

Se han proporcionado los datos, pero aún no se han verificado. El emisor de la tarjeta del cliente finalmente verificará los datos proporcionados.

not_provided

No se han proporcionado los datos a Stripe.
Los valores distinguen entre mayúsculas y minúsculas.

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.

Atributo
Descripción

:authorized_charges_per​_card_number_all_time:

El número de cargos autorizados para esta tarjeta en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:authorized_charges_per​_card_number_weekly:

El número de cargos autorizados para esta tarjeta en tu cuenta durante la última semana. (Nota: límite superior ≤25)

:authorized_charges_per​_card_number_daily:

El número de cargos autorizados para esta tarjeta en tu cuenta durante el último día. (Nota: límite superior ≤25)

:authorized_charges_per​_card_number_hourly:

El número de cargos autorizados para esta tarjeta en tu cuenta durante la última hora. (Nota: límite superior ≤25)

:authorized_charges_per​_email_all_time:

El número de cargos autorizados para este correo electrónico en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:authorized_charges_per​_email_weekly:

El número de cargos autorizados para este correo electrónico en tu cuenta durante la última semana. (Nota: límite superior ≤25)

:authorized_charges_per​_email_daily:

El número de cargos autorizados para este correo electrónico en tu cuenta durante el último día. (Nota: límite superior ≤25)

:authorized_charges_per​_email_hourly:

El número de cargos qautorizados para este correo electrónico en tu cuenta durante la última hora. (Nota: límite superior ≤25)

:authorized_charges_per​_ip_address_all_time:

El número de cargos autorizados para esta dirección IP en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:authorized_charges_per​_ip_address_weekly:

El número de cargos autorizados para esta dirección IP en tu cuenta durante la última semana. (Nota: límite superior ≤25)

:authorized_charges_per​_ip_address_daily:

El número de cargos autorizados para esta dirección IP en tu cuenta durante el último día. (Nota: límite superior ≤25)

:authorized_charges_per​_ip_address_hourly:

El número de cargos autorizados para esta dirección IP en tu cuenta durante la última hora. (Nota: límite superior ≤25)

:authorized_charges_per​_customer_daily:

La cantidad de veces que un cliente fue autorizado con éxito en tu cuenta en las últimas 24 horas. (No se incluye el pago que se encuentra actualmente en evaluación).

:authorized_charges_per​_customer_hourly:

La cantidad de veces que un cliente fue autorizado con éxito en tu cuenta en la última hora. (No se incluye el pago que se encuentra actualmente en evaluación).

:blocked_charges_per​_card_number_daily:

La cantidad de veces que un número de tarjeta fue bloqueado por los modelos de *machine learning* de Stripe en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:blocked_charges_per​_card_number_hourly:

La cantidad de veces que un número de tarjeta fue bloqueado por los modelos de *machine learning* de Stripe en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:blocked_charges_per​_customer_daily:

La cantidad de veces que un cliente fue bloqueado por los modelos de *machine learning* de Stripe en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:blocked_charges_per​_customer_hourly:

La cantidad de veces que un cliente fue bloqueado por los modelos de *machine learning* de Stripe en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:blocked_charges_per​_ip_address_daily:

La cantidad de veces que una dirección de IP fue bloqueada por los modelos de *machine learning* de tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:blocked_charges_per​_ip_address_hourly:

La cantidad de veces que una dirección de IP fue bloqueada por los modelos de *machine learning* de tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_card_number_daily:

La cantidad de veces que se ha intentado efectuar un cargo en una tarjeta en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_card_number_hourly:

La cantidad de veces que se ha intentado efectuar un cargo en una tarjeta en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_customer_daily:

La cantidad de veces que un cliente ha intentado efectuar un cargo en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_customer_hourly:

La cantidad de veces que un cliente ha intentado efectuar un cargo en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_ip_address_daily:

La cantidad de veces que una IP ha intentado efectuar un cargo en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:total_charges_per​_ip_address_hourly:

La cantidad de veces que una IP ha intentado efectuar un cargo en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_card_number_daily:

La cantidad de veces que un número de tarjeta fue rechazado por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_card_number_hourly:

La cantidad de veces que un número de tarjeta fue rechazado por el emisor de la tarjeta en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_customer_daily:

La cantidad de veces que un cliente fue rechazado por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_customer_hourly:

La cantidad de veces que un cliente fue rechazado por el emisor de la tarjeta en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_ip_address_daily:

La cantidad de veces que una dirección de IP fue rechazada por el emisor de la tarjeta en tu cuenta en las últimas 24 horas. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_ip_address_hourly:

La cantidad de veces que una dirección de IP fue rechazada por el emisor de la tarjeta en tu cuenta en la última hora. No se incluye el pago que se encuentra actualmente en evaluación (p. ej., 4).

:declined_charges_per​_email_all_time:

El número de cargos rechazados para este correo electrónico en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:declined_charges_per​_email_weekly:

El número de cargos rechazados para este correo electrónico en tu cuenta durante la última semana. (Nota: límite superior ≤25)

:declined_charges_per​_email_daily:

El número de cargos rechazados para este correo electrónico en tu cuenta durante el último día. (Nota: límite superior ≤25)

:declined_charges_per​_email_hourly:

El número de cargos rechazados para este correo electrónico en tu cuenta durante la última hora. (Nota: límite superior ≤25)

:dispute_count_on_ip_all_time:

Número de disputas fraudulentas asociadas a cargos desde esta dirección IP en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante. (Nota: límite superior ≤25).

:dispute_count_on_ip_weekly:

Número de disputas fraudulentas asociadas a cargos desde esta dirección IP en tu cuenta en la última semana. (Nota: límite superior ≤25).

:dispute_count_on_ip_daily:

Número de disputas fraudulentas asociadas a cargos desde esta dirección IP en tu cuenta en el último día. (Nota: límite superior ≤25).

:dispute_count_on_ip_hourly:

Número de disputas fraudulentas asociadas a cargos desde esta dirección IP en tu cuenta en la última hora. (Nota: límite superior ≤25).

:email_count_for​_card_all_time:

Número de correos electrónicos asociados a esta tarjeta procedentes de transacciones en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25).

:email_count_for​_card_weekly:

Número de correos electrónicos asociados a esta tarjeta de las transacciones de tu cuenta durante la última semana. (Nota: límite superior ≤25).

:email_count_for​_card_daily:

Número de correos electrónicos asociados a esta tarjeta de las transacciones de tu cuenta durante el último día. (Nota: límite superior ≤25).

:email_count_for​_card_hourly:

Número de correos electrónicos asociados a esta tarjeta de las transacciones de tu cuenta durante la última hora. (Nota: límite superior ≤25).

:email_count_for​_ip_all_time:

Número de correos electrónicos asociados a esta IP procedentes de transacciones en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25).

:email_count_for​_ip_weekly:

Número de correos electrónicos asociados a esta IP de las transacciones de tu cuenta durante la última semana. (Nota: límite superior ≤25).

:email_count_for​_ip_daily:

Número de correos electrónicos asociados a esta IP de las transacciones de tu cuenta durante el último día. (Nota: límite superior ≤25).

:email_count_for​_ip_hourly:

Número de correos electrónicos asociados a esta IP de las transacciones de tu cuenta durante la última hora. (Nota: límite superior ≤25).

:name_count_for​_card_all_time:

Número de nombres asociados a esta tarjeta procedentes de transacciones en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25).

:name_count_for​_card_weekly:

Número de nombres asociados a esta tarjeta de las transacciones de tu cuenta durante la última semana. (Nota: límite superior ≤25).

:name_count_for​_card_daily:

Número de nombres asociados a esta tarjeta de las transacciones de tu cuenta durante el último día. (Nota: límite superior ≤25).

:name_count_for​_card_hourly:

Número de nombres asociados a esta tarjeta de las transacciones de tu cuenta durante la última hora. (Nota: límite superior ≤25).

:total_charges_per​_card_number_all_time:

Número total de cargos desde esta tarjeta en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:total_charges_per​_card_number_weekly:

El número total de cargos de esta tarjeta en la última semana en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_card_number_daily:

El número total de cargos de esta tarjeta en el último día en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_card_number_hourly:

El número total de cargos de esta tarjeta en la última hora en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_email_all_time:

Número total de cargos desde este correo electrónico en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:total_charges_per​_email_weekly:

El número total de cargos de este correo electrónico en la última semana en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_email_daily:

El número total de cargos de este correo electrónico en el último día en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_email_hourly:

El número total de cargos de este correo electrónico en la última hora en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_ip_address_all_time:

Número total de cargos desde esta dirección IP en tu cuenta. Considera los pagos de 2020 en adelante. (Nota: límite superior ≤25)

:total_charges_per​_ip_address_weekly:

El número total de cargos de esta dirección IP en la última semana en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_ip_address_daily:

El número total de cargos de esta dirección IP en el último día en tu cuenta. (Nota: límite superior ≤25)

:total_charges_per​_ip_address_hourly:

El número total de cargos de esta dirección IP en la última hora en tu cuenta. (Nota: límite superior ≤25)

Atributos basados en los datos de tarjeta

Atributo
Descripción

:card_bin:

El número de identificación bancaria (BIN) de la tarjeta que se está usando para efectuar el pago. Se trata de los primeros seis dígitos del número de la tarjeta (p. ej., '424242').

:card_brand:

La marca de la tarjeta que se está utilizando para hacer el pago. Los valores admitidos son: 'amex' (American Express), 'visa' (Visa), 'mc' (Mastercard), 'dscvr' (Discover), 'diners' (Diners Club), 'interac' (Interac), 'jcb' (JCB) y 'cup' (UnionPay).

:card_country:

El código de dos letras correspondiente al país en el que se emitió la tarjeta (p. ej., 'US'). Para ver la lista de códigos de países, consulta esta página. Para especificar varios países, utiliza el operador IN: IN ('GB', 'DE', 'AE').

:card_fingerprint:

La huella de la tarjeta que se está usando para hacer el pago. La huella de la tarjeta es el identificador único de un número de tarjeta en particular. Puedes encontrar este número en Pagos e inspección de un pago, en la sección del Método de pago (p. ej., 'VfE3rx3VlaQhS8Lp'). Distingue mayúsculas y minúsculas.

:card_funding:

Si la tarjeta es de prepago, de débito o de crédito. Los valores admitidos son: 'credit', 'debit', 'prepaid', 'unknown'.

:card_3d_secure_support:

El nivel de soporte de 3D Secure de la tarjeta que se usa para hacer el pago. Los valores admitidos son: required', 'recommended', 'optional' y 'not_supported'.

Atributos basados en los datos de pago

Atributo
Descripción

:amount_in_xyz:

El importe de pago, convertido a la divisa especificada (que sustituiría el valor «xyz» del atributo: amount_in_usd). Especifica una de las siguientes divisas admitidas y Stripe calcula automáticamente el importe convertido que se vaya a utilizar: aud, brl, cad, chf, dkk, eur, gbp, hkd, inr, jpy, mxn, nok, nzd, ron, sek, sgd o usd. No se deben utilizar subunidades de divisas (es decir, puedes determinar la cantidad de euros, pero no de céntimos: por ejemplo :amount_in_usd: > 250).

:average_usd_amount​_attempted_on_card_all_time:

El importe medio (en USD) de intentos de transacciones de la tarjeta en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:average_usd_amount​_successful_on_card_all_time:

El importe medio (en USD) de transacciones que tuvieron como resultado la autorización de la tarjeta en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:risk_level:

El nivel de riesgo de un pago concreto, según lo determine Stripe. Los valores admitidos son: ‘normal’, ‘elevated’, ‘highest’ y ‘not_assessed’.

:risk_score:

La puntuación de riesgo de un pago en concreto, según lo determine Stripe (p. ej., >50). El rango de valores oscila entre 0 (riesgo más bajo) y 100 (riesgo más alto). Una puntuación de riesgo de 65 o más corresponde a un nivel de riesgo ‘elevated’, mientras que una puntuación de riesgo de 75 corresponde a un nivel de riesgo ‘highest’.

:charge_description:

La descripción proporcionada con el pago (p. ej., ‘Class trial’).

:is_recurring:

Identifica si el pago es recurrente (como, por ejemplo, el pago de una suscripción). Se trata de un parámetro booleano, así que debes usar :is_recurring: para casos en los que es verdadero o NOT :is_recurring: para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:is_off_session:

Identifica el momento en el que un pago de Stripe Billing no se activa por la acción directa del usuario o cuando se establece el indicador de off_session en la confirmación del PaymentIntent. Se trata de un parámetro booleano, así que debes usar :is_off_session: para casos en los que es verdadero o NOT :is_off_session: para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:digital_wallet:

El tipo de monedero digital usado para almacenar la información de pago. Los valores admitidos son: ‘android_pay’, ‘amex_express_checkout’, ‘apple_pay’, ‘masterpass’, ‘samsung_pay’, ‘unknown’, ’visa_checkout’, ‘none’.

:destination:

Para los usuarios Connect que crean cargos indirectos, la cuenta de destino a nombre de la que se hace el cargo (p. ej., ‘acct_19KCB9AlaaEw6AgR’). Distingue entre mayúsculas y minúsculas.

:is_checkout:

Identifica si el pago se procesa mediante Checkout. Este atributo solamente se aplica para los pagos procesados a través de la nueva versión de Checkout y no captura los pagos a través de Checkout heredado. Se trata de un parámetro booleano, así que debes usar :is_checkout: para casos en los que es verdadero y NOT :is_checkout: para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:is_3d_secure​_authenticated:

Identifica si el pago sigue la verificación con autenticación de 3D Secure completada satisfactoriamente. (La autenticación puede estar basada en basadas en análisis de riesgo mediante comprobación. Se trata de un parámetro booleano, así que debes usar :is_3d_secure_authenticated: para casos en los que es verdadero o NOT :is_3d_secure_authenticated: para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:is_3d_secure:

Identifica si el pago utiliza una fuente 3D Secure. Se trata de un parámetro booleano, así que debes usar :is_3d_secure: para casos en los que es verdadero o NOT :is_3d_secure para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:has_liability_shift:

Verdadero si se ha cambiado la responsabilidad del fraude de este pago. Se trata de un parámetro booleano, así que debes usar :has_liability_shift: para casos en los que es verdadero o NOT :has_liability_shift para casos en los que no es verdadero. No debes usar el símbolo negativo «!=».

:seconds_since_card​_first_seen:

El número de segundos desde que la tarjeta del pago se vio por primera vez en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:seconds_since_first_successful​_auth_on_card:

El número de segundos desde que tuvo lugar la primera autenticación satisfactoria para la tarjeta asociada al pago en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:total_usd_amount_failed​_on_card_all_time:

El importe total (en USD) de transacciones de esta tarjeta que han fallado (se han bloqueado o rechazado) en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:total_usd_amount_successful​_on_card_all_time:

El importe total (en USD) de transacciones que han tenido como resultado la autorización de la tarjeta en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

Atributos basados en los datos del cliente

Atributo
Descripción

:ip_country:

El código de dos letras correspondiente a la geolocalización por países de la dirección IP desde la que se origina el pago (p. ej., 'GB'). Para ver la lista de códigos de países, consulta esta página. Para especificar varios países, utiliza el operador IN: IN ('GB', 'DE', 'AE').

:ip_address:

La dirección IP desde la que se origina el pago (p. ej., '192.168.0.1' para especificar una única IP, o si quieres ampliar la red, puedes utilizar INCLUDES '192.168' para incluir todas las IP que compartan los seis primeros dígitos).

:is_anonymous_ip:

Identifica si la dirección IP desde la que se origina el pago es un proxy conocido o un nodo de salida Tor. Esta información se actualiza a diario. (Se trata de un parámetro booleano para que puedas usar :is_anonymous_ip: para casos en los que es verdadero y NOT :is_anonymous_ip: para casos en los que no es verdadero. No puedes usar !=).

:is_my_login_ip:

Identifica si la dirección IP desde la que se origina el pago se usó para iniciar sesión en tu cuenta de Stripe. Este atributo puede usarse como proxy para «es mi dirección IP». (Se trata de un parámetro booleano para que puedas usar :is_my_login_ip: para casos en los que es verdadero y NOT :is_my_login_ip: para casos en los que no es verdadero. No puedes usar !=).

:email:

La dirección de correo electrónico proporcionada con el pago (p. ej., 'user@example.com').

:email_domain:

El dominio de la dirección de correo electrónico proporcionada con el pago (p. ej., 'example.com').

:is_disposable_email:

Identifica si la dirección de correo electrónico proporcionada con el pago es una que se utiliza con el denominado proveedor de dirección de correo electrónico desechable. Stripe tiene una lista de dominios que corresponden a direcciones de correo electrónico desechable para proporcionar este atributo. (Se trata de un parámetro booleano para que puedas usar :is_disposable_email: para casos en los que es verdadero y NOT :is_disposable_email: para casos en los que no es verdadero. No puedes usar !=).

:billing_address:

La dirección de facturación completa del titular de la tarjeta proporcionada (p. ej., '510 Townsend, San Francisco, CA 94110').

:billing_address_line1:

La primera línea de la dirección de facturación proporcionada del titular de la tarjeta, generalmente el nombre y número de la calle (p. ej., '510 Townsend').

:billing_address_line2:

La segunda línea de la dirección de facturación del titular de la tarjeta proporcionada, generalmente el número de apartamento o puerta (p. ej., 'Apt 5b').

:billing_address_postal_code:

El código postal de la dirección de facturación del titular de la tarjeta proporcionada (p. ej., '94110').

:billing_address_city:

La ciudad de la dirección de facturación del titular de la tarjeta proporcionada (p. ej., 'San Francisco').

:billing_address_state:

El estado de la dirección de facturación del titular de la tarjeta proporcionada (p. ej., 'CA').

:billing_address_country:

El código de dos letras correspondiente al país de la dirección de facturación del titular de la tarjeta proporcionada (p. ej., 'US'). Para ver la lista de códigos de países, consulta esta página. Para especificar varios países, utiliza el operador IN: IN ('US', 'DE', 'AE').

:seconds_since​_email_first_seen:

El número de segundos desde que la dirección de correo aportada con el pago se vio por primera vez en tu cuenta. Tiene en cuenta los pagos de 2020 en adelante.

:seconds_since​_email_first_seen_on_stripe:

El número de segundos desde que la dirección de correo aportada con el pago se vio por primera vez en el total de Stripe. Tiene en cuenta los pagos de 2020 en adelante.

:shipping_address:

La dirección de envío completa proporcionada (p. ej., '510 Townsend, San Francisco, CA 94110').

:shipping_address_line1:

La primera línea de la dirección de envío proporcionada, generalmente el nombre y número de la calle (p. ej., '510 Townsend').

:shipping_address_line2:

La segunda línea de la dirección de envío proporcionada, generalmente el número de apartamento o puerta (p. ej., 'Apt 5b').

:shipping_address_postal_code:

El código postal de la dirección de envío proporcionada (p. ej., '94110').

:shipping_address_city:

La ciudad de la dirección de envío proporcionada (p. ej., 'San Francisco').

:shipping_address_state:

El estado de la dirección de envío proporcionada (p. ej., 'CA').

:shipping_address_country:

El código de dos letras correspondiente al país de la dirección de envío proporcionada (p. ej., 'US'). Para ver la lista de códigos de países, consulta esta página. Para especificar varios países, utiliza el operador IN: IN ('US', 'DE', 'AE').

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:

Nombre de los metadatos
Valor de los metadatos
Customer age
22
Item ID
5A381D
Category ID
groceries

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:

Nombre de los metadatos
Valor de los metadatos
Trusted
true

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:

Nombre de los metadatos
Valor de los metadatos
Category
new

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.

Nota: los comerciantes europeos deben tener en cuenta el reglamento que prohíbe el bloqueo de pagos de clientes que residen en estados miembros de la Unión Europea. Más información sobre este reglamento.

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 hacer 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 hacer 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 alertas 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 hace un 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 que 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 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, las tarjetas). Una vez que se ha validado que funcionan, usan estas credenciales para obtener valor en forma de productos físicos para uso personal o reventa (artículos de lujo o aparatos electrónicos), servicios para uso personal o 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 sobre cómo usar las reglas de Radar para mitigarlos.

Pruebas

La prueba de tarjetas tiene 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

  • card_count_for_email

  • card_count_for_ip_address

  • total_charges_per_ip

Los estafadores normalmente intentan eludirlas creando correos electrónicos falsos y usando direcciones de correo electrónico características. Los estafadores con más experiencia enmascaran las direcciones IP o incluso cuentan con varios dispositivos para proporcionar datos de un único dispositivo. Por tanto, es importante reconocer el comportamiento típico de un cliente que actúa de buena fe. Hay funciones, como el dominio del correo electrónico o el país de la dirección IP, entre otras categorías más amplias, que 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 desafíos cuando hay un ataque de prueba de tarjetas en curso, por lo que esos usuarios reales casi nunca ven un CAPTCHA, solo los bots. 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.

Tras añadir las comprobaciones CAPTCHA gestionadas por Stripe para todos los usuarios de Checkout, se sufrieron un 80 % menos de ataques de prueba de tarjetas y el impacto sobre las tasas de autorización fue inferior a 2bps (0,02 %).

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 (comportamiento de usuario nuevo)

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

Este vector se suele explotar mediante un uso abusivo, 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, existen atributos de reglas que miden la antigüedad de una cuenta en Stripe, como hours_since_email_first_seen_on_stripe, que junto a risk_score y otras funciones mantienen a raya a esos nuevos titulares de tarjetas. Además, las restricciones de velocidad sobre direcciones IP, correos electrónicos y tarjetas pueden reforzar la protección para los comerciantes frente a ataques por volumen donde los estafadores intentan monetizar las credenciales robadas lo más rápido posible.

Tarjetas de crédito robadas (comportamiento de enmascaramiento)

En este vector de fraude, el estafador se sirve de la tarjeta robada validada en su dispositivo personal o en un dispositivo utilizado para cometer fraude, o bien 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.

A continuación, intentará enmascarar su presencia de la mejor forma posible con estas tres estrategias:

  • Usar el mismo nombre que en las transacciones efectuadas anteriormente.

  • Usar la misma dirección de facturación que en las transacciones efectuadas anteriormente.

  • Usar una VPN para que parezca que se trata del titular original de la tarjeta. Es posible que configure la VPN en la misma ciudad e incluso en el mismo bloque.

  • Modificar tan solo un detalle mínimo, como la dirección de correo electrónico o el número de teléfono.

  • Cambiar la dirección de envío respecto a transacciones anteriores (si la transacción implica productos físicos), que implica una distancia potencialmente llamativa entre la dirección de envío y la dirección de facturación. Esta no se puede considerar una señal absolutamente fiable.

El comportamiento de enmascaramiento que acabamos de describir provoca que resulte difícil analizar quién realiza realmente la transacción, ¿será el titular original de la tarjeta o un estafador que se ha adueñado de la cuenta? Lo que suele suceder a menudo es que este tipo de fraude pasa desapercibido durante largos períodos de tiempo, sin que lo detecten el comerciante ni el titular original.

Aquí la estrategia es similar: lo que busca el estafador es obtener el máximo valor en el mínimo tiempo posible con esas credenciales robadas. Las reglas que usan funciones para limitar la velocidad, junto con riskscore, fallos en cvccheck o fallos en comprobaciones del código postal, pueden ayudar a protegerse de este comportamiento.

Otras prácticas recomendadas

Te proponemos las mejores prácticas complementarias para que optimices cómo escribes las reglas en Radar.

Flujo del proceso de compra
Incluye una referencia explícita de tus condiciones de servicio en el flujo del proceso de compra.
En caso de contracargo, envía una captura de pantalla bien clara de las condiciones de servicio, tal como aparecen en el flujo del proceso de compra. Esto mejorará tus posibilidades de ganar.
Valida el CVS y el código postal
Permite que la empresa emisora valide al titular de la tarjeta. Puede aumentar la posibilidad de que ganes disputas y suele mejorar las tasas de autorización. Considera bloquear las verificaciones que fallen.
Recopila toda la información del cliente que puedas
Recopilar esta información ayuda a que los emisores evalúen tu caso si se produce algún contracargo, lo que aumenta tus posibilidades de ganar. Se considera una diligencia debida.
El estándar de referencia incluye lo siguiente: CVC y código postal, nombre del cliente, dirección de correo electrónico del cliente, dirección de facturación completa, dirección IP, información del dispositivo, etc.
La implementación de Stripe.js proporciona a Radar información sobre la dirección IP, el dispositivo y su comportamiento para mejorar la detección del fraude.
Interacciones de clientes
Añade a tu lista de bloqueo las tarjetas con contracargos fraudulentos
Si un cliente disputa un cargo como fraudulento, es posible que los siguientes cargos sean disputados.
Reembolsa los pagos fraudulentos/sospechosos
Entre el 70 % y el 85 % de las transacciones de los TC40 se convierten en disputas, y solo los reembolsos completos pueden prevenir las disputas.
Implementa una descripción en el extracto bancario clara
Reduce el número de disputas no reconocidas.

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.

¿A punto para empezar?

Crea una cuenta y empieza a aceptar pagos: no tendrás que firmar ningún contrato ni proporcionar datos bancarios. Si lo prefieres, puedes ponerte en contacto con nosotros y diseñaremos un paquete personalizado para tu empresa.
Radar

Radar

Combate el fraude con la solidez de la red de Stripe.

Documentación de Radar

Utiliza Stripe Radar para proteger tu empresa contra fraude.