Reglas de prevención de fraude
Usa reglas de prevención de fraude para proteger tu empresa.
Las reglas de prevención de fraude te permiten actuar cuando un pago coincide con determinados criterios.
Stripe Radar proporciona reglas integradas para ayudar a detectar el riesgo de fraude y ofrecer protección contra dicho riesgo a todos los usuarios de Stripe.
Los usuarios de Radar para Equipos de Fraude pueden utilizar el Dashboard para crear reglas personalizadas basadas en la lógica empresarial única y específica de tu empresa. Por ejemplo, puedes:
- Solicitar 3D Secure (3DS) para todos los pagos que admitan 3D Secure y sean efectuados por un cliente nuevo
- Autorizar todos los pagos que lleguen de la dirección IP de tu centro de atención telefónica
- Bloquear los pagos efectuados desde el extranjero o con una tarjeta emitida fuera de tu país
- Revisar todos los pagos superiores a USD 1,000 realizados con tarjetas de prepago
Precaución
Los comerciantes de la UE podrían verse afectados por el Reglamento sobre bloqueo geográfico y sus prohibiciones de bloquear pagos de clientes establecidos en estados miembros de la UE.
Reglas integradas
De forma predeterminada, las siguientes reglas están disponibles para todos los usuarios de Radar.
Comprobaciones de riesgo con machine learning
Stripe Radar y Radar para Equipos de Fraude de Stripe proporcionan un conjunto de reglas predeterminadas basadas en las valoraciones de nuestros modelos de machine learning, que son las siguientes:
Block if :risk_level: = 'highest'
La regla bloquea los pagos de muy alto riesgo de fraude y no permite su procesamiento. Esta regla está habilitada de forma predeterminada para los usuarios de Radar y de Radar para Equipos de Fraude.
Review if :risk_level: = 'elevated'
El comportamiento predeterminado de Radar para Equipos de Fraude de Stripe es pasar a revisión los pagos que Stripe presuma que tienen elevado riesgo de fraude.
Comprobaciones tradicionales de tarjetas
Un pago puede realizarse correctamente incluso si falla la comprobación del CVC o del domicilio (AVS). Esto se debe a que los emisores de tarjetas tienen en cuenta muchas señales para decidir si aprueban o rechazan un pago. En algunos casos, el emisor puede aprobar un pago que considera legítimo, aun cuando haya errores en las verificaciones del CVC o del código postal.
Stripe tiene reglas integradas para poder bloquear pagos aun cuando el emisor de la tarjeta los haya aprobado. Puedes activar o desactivar estas reglas en el Dashboard de Stripe.
Estas reglas también se aplican al proceso de validación de tarjetas que ocurre cuando se agrega una tarjeta a un cliente. Cuando la tarjeta y el cliente se crean al mismo tiempo, el error en la validación del CVC o del código postal evita que el registro del cliente se genere correctamente. Es posible que esta regla no esté activada de forma predeterminada para tu cuenta. Puedes activarla o desactivarla en cualquier momento en el Dashboard de Stripe.
Bloquear si falla la verificación del CVC
Si esta regla está habilitada, Radar bloquea los pagos que no pasan la verificación del CVC del emisor de la tarjeta. Si el cliente no brinda el número de CVC, por ejemplo, porque usa una cartera, o el emisor de su tarjeta no admite su verificación, la regla no puede bloquear el pago.
Bloquear si falla la verificación del código postal
Si esta regla se encuentra habilitada, Radar bloquea los pagos cuando no pasan la verificación del código postal del emisor de la tarjeta. Si el cliente no proporciona el código postal, o si el emisor de su tarjeta no admite su verificación, la regla no puede bloquear el pago. Es posible que esta regla no esté habilitada para tu cuenta de forma predeterminada. Puedes habilitarla o deshabilitarla en cualquier momento en el Dashboard.
Reglas integradas para solicitar 3D Secure
Cuando se usa 3DS , se les solicita a los clientes que realicen un paso de autenticación más antes de completar el flujo de compra. Si 3DS autentica un pago, la responsabilidad por cualquier disputa relacionada con el fraude para ese pago suele pasar del vendedor al emisor. Este cambio de responsabilidad significa que, en la mayoría de los casos, el vendedor no es responsable de los costos por fraude en los pagos autenticados con 3DS.
Stripe maneja automáticamente los códigos de rechazo temporal que indican que se necesita una autenticación 3DS. También activamos la autenticación 3DS cuando es necesario, para cumplir con normativas como la autenticación reforzada de clientes (SCA) que integra el marco de la Segunda Directiva de Servicios de Pago (PSD2). La desactivación de Radar no impide que se active 3D Secure en los casos en que sea necesario.
Stripe proporciona tres reglas deshabilitadas predeterminadas que puedes habilitar para solicitar 3DS en forma dinámica al usar Radar con Payment Intents o Setup Intents:
Solicitar 3D Secure si se exige 3D Secure para la tarjeta- Está desactivada de forma predeterminada. Al activar esta regla, el cliente solicita la autenticación mediante 3DS si históricamente la tarjeta exigía 3DS.
- Stripe maneja automáticamente los códigos de pagos rechazados suave que indican que los emisores exigen 3DS. Además, también activamos 3DS cuando es necesario, cumpliendo con normativas como la autenticación reforzada de clientes (SCA) exigida por la segunda Directiva sobre servicios de pago (PSD2).
Solicitar 3D Secure si la tarjeta admite 3D Secure- Viene deshabilitada en forma predeterminada, pero es similar a la regla anterior. Si se habilita esta regla, se le solicita al cliente la autenticación con 3DS siempre que la tarjeta lo admita.
- Utiliza esta regla en lugar de la anterior si quieres maximizar la cantidad de pagos con transferencia de responsabilidad. Ten en cuenta que este requisito adicional puede disminuir las tasas de conversión.
Solicitar 3D Secure si se recomienda 3D Secure para la tarjeta- Viene deshabilitada en forma predeterminada. Si se habilita esta regla, se le solicita al cliente la autenticación con 3DS cuando Stripe considera que se puede hacer la autenticación con un impacto mínimo en las tasas de conversión.
- Activa esta regla si quieres maximizar la cantidad de pagos con transferencia de responsabilidad.
Debido a que 3DS requiere que tu cliente pase por una capa adicional de autenticación, el uso indiscriminado de 3DS podría reducir las tasas de conversión. Stripe recomienda que habilites las reglas predeterminadas de solicitud de 3D Secure solo si necesitas enviar todos los pagos realizados desde las tarjetas que admiten 3DS.
Si solicitas 3DS, no significa necesariamente que el emisor realmente realice la autenticación mediante 3DS. Para obtener más información sobre los posibles resultados, consulta la documentación de 3D Secure.
Reglas personalizadas para solicitar 3D Secure y actuar en función de resultados específicos
Después de intentar la autenticación con 3DS, si tienes Radar para Equipos de Fraude, puedes evaluar el resultado en las reglas de permiso, bloqueo o revisión.
Los atributos más importantes para las reglas personalizadas de Radar son los siguientes:
is_3d_secure, que es verdadero si se admite la tarjeta, el emisor intentó la autenticación con 3DS y el usuario realizó la autenticación correctamente. Por lo general, recomendamos usar este atributo en las reglas de bloqueo.is_3d_secure_authenticated, que es verdadero si el emisor intentó la autenticación con 3DS y el usuario completó correctamente toda la autenticación. El uso de este atributo en una regla de bloqueo excluye las transacciones legítimas que pueden tener una exención de la autenticación reforzada de clientes (SCA) o que no se categorizan como un error claro o una autenticación correcta, como los errores de procesamiento.has_liability_shift, que es verdadero si Stripe espera que el pago se rija por la regla de transferencia de responsabilidad. Es posible que este atributo no siempre coincida con 3DS, por ejemplo, Apple Pay en ciertas regiones.
Para las reglas personalizadas, recomendamos que mantengas alineadas las reglas de Request 3DS y Block según el riesgo que quieras asumir. Sin embargo, no bloqueamos las transacciones en las que no se admita 3DS, como las de algunas billeteras.
Estos son algunos ejemplos que muestran cómo lograrlo para diferentes casos de uso:
Solicita 3D Secure según el nivel de riesgo de Radar
Usa Radar para solicitar 3DS en todos los cargos en función del nivel de riesgo de Radar y cuando se supere un cierto importe.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if :risk_level: != | Esta regla verifica el nivel de riesgo de Radar y luego solicita 3DS en todos los cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. |
En este caso, sin una regla de bloqueo, las tarjetas o billeteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo.
Siempre solicita 3D Secure en función del nivel de riesgo de Radar
Usar Radar para solicitar 3DS en todos los cargos en función del nivel de riesgo de Radar elevado o alto, y cuando se supere un cierto importe. Si las tarjetas no admiten 3DS, no querrás aceptarlas.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if :risk_level: != | Esta regla verifica el nivel de riesgo de Radar y luego solicita 3DS en todos los cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. |
Block if not :is_3d_secure: and :risk_level: != | Esta regla bloquea los pagos sin un flujo de 3DS para cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. Sin embargo, acepta transacciones legítimas que podrían tener una exención de la autenticación reforzada de clientes (SCA) o no tienen un error claro o una autenticación correcta, como attempt_. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y billeteras como Apple Pay o Google Pay, para ejecutarse correctamente. |
Solo acepta transacciones completamente autenticadas con 3D Secure si se admite 3D Secure
Puedes confiar en que Stripe activará 3DS cuando sea necesario en casos como la autenticación reforzada de clientes (SCA), pero no aceptes casos extremos como los errores de procesamiento.
| Regla de Radar | Descripción |
|---|---|
Block if :is_3d_secure: and not :is_3d_secure_authenticated: | Esta regla bloquea los pagos en los que la tarjeta está inscrita en 3DS y se intentó realizar la autenticación con 3DS, pero el usuario no logró una autenticación correcta. Se aceptan tarjetas que no admiten 3DS, exenciones de la autenticación reforzada de clientes (SCA), pagos fuera de la sesión, como cargos de suscripciones recurrentes, y billeteras, como Apple Pay o Google Pay. |
Solicita 3D Secure en función de los metadatos
Usa Radar para solicitar 3DS en todos los cargos con un atributo de metadatos personalizado.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if ::foo:: = | Esta regla comprueba si hay una condición de metadatos y luego solicita 3DS. Para verificar los metadatos del cliente, reemplaza ::foo:: = 'bar' con un valor como ::customer:trusted:: = 'false'. |
En este caso, sin una regla de bloqueo, las tarjetas o billeteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo.
Siempre solicita 3D Secure en función de los metadatos
Usa Radar para solicitar 3DS en todos los cargos con un atributo de metadatos personalizado y bloquear las tarjetas que no admitan esta autenticación.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if ::foo:: = | Esta regla comprueba si hay una condición de metadatos y luego solicita 3DS. Para verificar los metadatos del cliente, reemplaza ::foo:: = 'bar' con un valor como ::customer:trusted:: = 'false'. |
Block if ::foo:: = | Esta regla bloquea los pagos sin un flujo de 3DS para los cargos con un atributo de metadatos personalizado. Sin embargo, acepta transacciones legítimas que podrían tener una exención de la SCA o no tienen un error claro o una autenticación correcta, como attempt_. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y billeteras, como Apple Pay o Google Pay, para ejecutarse correctamente. |
Solicita 3D Secure para todas las tarjetas nuevas y revisa si no se admitió 3D Secure
Usa Radar para solicitar 3DS en todas las tarjetas nuevas y revisar manualmente los cargos de las tarjetas que no admitan 3DS.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Esta regla solicita 3DS en todas las tarjetas que no se hayan utilizado en tu cuenta. Para reducir la fricción para el usuario, puedes agregar una condición adicional para solicitar 3DS solo si :risk_level: != . |
Request 3D Secure if :is_new_card_on_customer: | Como alternativa a la regla anterior, esta regla solicita 3DS en todas las tarjetas que se usan recientemente en un Customer. Para reducir los inconvenientes para el usuario, puedes agregar una condición más para solicitar solo 3DS si :risk_level: != . |
Review if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Esta regla marca los pagos en los que se espera 3DS, pero no es compatible con la revisión manual. Ignora los pagos fuera de sesión, como los cargos de suscripción recurrentes, y las billeteras, como Apple Pay o Google Pay. Los pagos marcados para revisión continúan con la autorización y pueden dar señales adicionales, como comprobaciones de CVC del emisor. |
En este caso, sin una regla de bloqueo, las tarjetas o billeteras que no admitan 3DS no se bloquearán. Los intentos fallidos de autenticación con 3DS no continuarán con la autorización del cargo.
Siempre solicita 3D Secure para ciertos países emisores
Usa Radar para solicitar 3DS en todos los cargos de emisores de tarjetas provenientes de países que se encuentran en una lista personalizada y para bloquear las tarjetas que no admitan esta autenticación.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if :card_country: in @enforce_3ds_list | Esta regla comprueba si hay una condición según los emisores de tarjetas provenientes de ciertos países y los compara con una lista personalizada. Si coinciden, solicita 3DS. |
Block if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Esta regla bloquea los pagos sin un flujo de 3DS para los cargos que se originan en los países de la lista personalizada. Sin embargo, acepta transacciones legítimas que podrían tener una exención de la autenticación reforzada de clientes (SCA) o que tengan un error claro o una autenticación correcta, como attempt_. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y billeteras, como Apple Pay o Google Pay, para ejecutarse correctamente. |
Siempre solicita 3D Secure según el nivel de riesgo de Radar y revisa los casos extremos
Usa Radar para solicitar 3DS en todos los cargos según el nivel de riesgo de Radar y bloquear las tarjetas que no admitan 3DS, pero revisa manualmente los casos extremos.
| Regla de Radar | Descripción |
|---|---|
Request 3D Secure if :risk_level: != | Esta regla verifica el nivel de riesgo de Radar y luego solicita 3DS en todos los cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. |
Block if not :is_3d_secure: and :risk_level: != | Esta regla bloquea los pagos sin un flujo de 3DS para cargos con un nivel de riesgo elevado o alto que estén por encima de un cierto importe. Sin embargo, acepta transacciones legítimas que podrían tener una exención de la SCA. Acepta pagos fuera de la sesión, como cargos de suscripciones recurrentes, y billeteras, como Apple Pay o Google Pay, para ejecutarse correctamente. |
Review if not :is_3d_secure_authenticated: and :risk_level: != | Esta regla marca para la revisión manual los pagos que usaban 3DS, pero no completaron el flujo de autenticación. Como resultado, se revisarían los casos extremos, como attempt_, y también se marcarían los pagos legítimos independientemente de las exenciones de la autenticación reforzada de clientes (SCA). Debido a que las reglas de revisión se evalúan después de las reglas de bloqueo, las tarjetas que no admitan 3DS se bloquearán. |
Cuándo crear reglas
Las reglas predeterminadas de Stripe pueden bloquear una gran cantidad de pagos fraudulentos. Las empresas que necesitan más control sobre qué pagos quieren revisar, permitir o bloquear pueden escribir reglas personalizadas a través de Radar para Equipos de Fraude.
Ten en cuenta las siguientes preguntas al decidir si habilitar reglas personalizadas:
- ¿Consideras que ciertas características o comportamientos de usuario son más riesgosos (por ejemplo, el uso de una dirección de correo electrónico temporal)?
- ¿Quieres implementar reglas según el importe del pago o el nivel de riesgo percibido (por ejemplo, revisar automáticamente si el pago es superior a USD 500 o permitir automáticamente si el pago es inferior a USD 5)?
- ¿Tus actuales pagos disputados y rembolsados comparten algún patrón común (por ejemplo, importes similares o el mismo país o tipo de tarjeta)?
- ¿Tienes reglas que quieres migrar a Stripe? Es posible que muchas de estas reglas ya estén comprendidas en los modelos de machine learning de Stripe y puedes verificar cómo se comporta nuestro sistema en tu empresa antes de personalizarlo.
Cómo crear reglas eficaces
Si bien las reglas pueden ayudarte a automatizar los flujos de trabajo existentes, también pueden perjudicar a tu empresa si no se usan correctamente. Por ejemplo, si una regla no se configura como se debe, puede permitir una gran cantidad de pagos fraudulentos o bloquear una gran cantidad de pagos legítimos automáticamente.
Cuando configures reglas, ten en cuenta lo siguiente:
- Las reglas solo se aplican a pagos futuros y no se aplican a ninguno que ya hayas procesado.
- Las reglas de solicitud de 3DS solo se aplican cuando se usa Stripe Checkout, Payment Intents o Setup Intents y se evalúan antes que las reglas de revisión, bloqueos y permitidos.
- Antes de implementar una regla de bloqueo que vaya a bloquear todos los pagos que se ajusten a sus criterios, piensa si no sería mejor revisar estos pagos primero.
- Implementa reglas de permitidos en la menor medida posible, ya que anulan las reglas predeterminadas de Stripe y cualquier otra regla personalizada que siga los mismos criterios.
- Solo puedes crear en total 200 reglas por cuenta.
Crea reglas
Puedes agregar y administrar reglas desde la pestaña Reglas de la página Radar en el Dashboard.
Para agregar una nueva regla:
- Haz clic en + Agregar regla.
- Elige el tipo de regla del submenú.
- En el editor de reglas, crea una regla usando la sintaxis
{action} if {attribute} {operator} {value}donde:{action}: Cómo responde Radar cuando se cumplen los criterios de la regla. Este valor se completa previamente en función de la selección del tipo de regla que elegiste.`{attribute}: El elemento de la transacción a evaluar, como el importe o el tipo de tarjeta. Empieza a escribir con:para abrir una lista de atributos válidos. También puedes evaluar tus metadatos personalizados encerrándolos en dos puntos, por ejemplo,::product_.sku:: {operator}: Cómo comparar el atributo con el valor, como=,>,!=, etc.{value}: El valor del atributo a evaluar.
- Haz clic en Probar regla.
- Corrige los errores de validación detectados, de ser necesario.
- En la página Revisa la nueva regla, revisa el rendimiento de esta regla en comparación con tus transacciones recientes para confirmar si quieres habilitarla.
- Haz clic en Agregar regla para comenzar a aplicar esta regla a todas las transacciones futuras.
Usar Asistente de Radar
El editor de reglas de Stripe tiene un asistente LLM integrado que crea una regla de Radar a partir de un mensaje de lenguaje natural.
Para usar el Asistente de Radar:
- Desde la pestaña Reglas de la página de Radar en el Dashboard, haz clic en + Agregar regla.
- Elige el tipo de regla del submenú.
- En el editor de reglas, haz clic en Asistente de Radar.
Escritura manual de reglas
Asistente de Radar
- En el campo de mensaje, ingresa tu solicitud de regla. Puedes pedir lo siguiente:
- Revisar los pagos en los que la tarjeta y los países de IP son diferentes.
- Bloquear los pagos con tarjeta Discover de más de $1000.
- Permitir pagos desde direcciones de correo electrónico de stripe.com.
- Cuando el Asistente devuelva su sugerencia, puedes ingresar un comando adicional para realizar ajustes en la regla o puedes hacer clic en Probar regla para ver cómo funciona la regla en tu historial de transacciones recientes.
- Cuando estés satisfecho con la regla, haz clic en Agregar regla para habilitarla para todas las transacciones futuras.
Consentimiento de datos de entrenamiento: Al usar el Asistente de Radar, aceptas que Stripe pueda registrar y usar tus entradas de chat para entrenar y mejorar las capacidades del Asistente de Radar. Si no quieres que tus entradas de chat se usen para este propósito, escribe reglas manualmente.
Más información sobre los servicios de IA de Stripe.
Revisar reglas
Cuando un pago cumple con los criterios de una regla de revisión, Stripe sigue procesando el pago normalmente, pero lo pasa a la cola de revisión para que tu equipo pueda analizarlo con más detenimiento. Si configuras una regla demasiado amplia, puede que muchos pagos pasen a la cola de revisión, con lo que tus clientes sufrirán demoras y tu equipo de revisión se verá sobrecargado.
La interfaz de pruebas de Stripe ejecuta una simulación tomando los cargos de los últimos 6 meses para determinar cuántos pagos legítimos, fraudulentos y bloqueados se hubieran visto afectados por la regla de haberse implementado. Mientras pruebas una regla y examinas los últimos 6 meses, debes asegurarte de lo siguiente:
- El volumen general de pagos es bajo. La revisión de estos pagos no debería sobrecargar a tu equipo.
- Los revisores humanos aportan un valor añadido. Por lo general, un revisor humano puede identificar si un pago es fraudulento con mayor seguridad que el sistema automático.
- La regla se traduce en una mezcla de pagos efectuados con éxito y rembolsados o en disputa. Esto significa que una inspección adicional sobre estos tipos de pagos puede ayudar a separar los pagos legítimos de los fraudulentos.
El siguiente ejemplo muestra cómo mejorar una regla de revisión creada por una empresa que desea revisar tarjetas de crédito de prepago.
| Regla original | Regla mejorada |
|---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
| Demasiado amplia: da lugar a demasiadas revisiones | Más específica: genera menor cantidad de revisiones |
Reglas de bloqueo
Puedes usar reglas de bloqueo para bloquear pagos que consideras que serán fraudulentos o que se basen en restricciones dispuestas por tu empresa (p. ej., bloquear pagos efectuados con tarjetas de prepago). Si tienes dudas respecto de cómo aplicar reglas de bloqueo, te recomendamos enviar los pagos a revisión mediante una regla de revisión. Después de dedicar algún tiempo a revisar estos pagos en busca de posibles falsos positivos, puedes confirmar si prefieres crear una regla de bloqueo.
Las reglas de bloqueo solo actúan sobre pagos fraudulentos y pagos efectuados con éxito, ya que los pagos ya bloqueados no se verán afectados. Mientras pruebas una regla, asegúrate de lo siguiente:
- Mantén el número de falsos positivos lo más bajo posible. Durante la prueba, Stripe identifica la cantidad de pagos correctos y en disputa que hubieran coincidido con la regla. Una buena regla bloquea muchos más pagos fraudulentos que pagos legítimos.
- Minimiza las reglas innecesarias. Si tu regla parece funcionar muy bien, pero está comprendida en una regla que ya existe, es posible que la regla nueva no sea necesaria. Asimismo, si los resultados durante la prueba parecen contradictorios, piensa en configurar una regla de revisión para poder reunir más información acerca de esos tipos de pagos.
El siguiente ejemplo muestra cómo mejorar una regla de bloqueo creada por una empresa con un alto nivel de fraude por pagos fuera de los Estados Unidos:
| Regla original | Regla mejorada |
|---|---|
Block if :card_country: != | Block if :card_country: != |
| Demasiado amplia: gran número de pagos legítimos bloqueados | Más específica: genera menor cantidad de revisiones |
Reglas de permitidos
Permite que las reglas anulen todas tus otras reglas, así que úsalas con precaución. Es posible que muchas empresas no necesiten implementar reglas de permisos. Si te preocupa que una regla de permiso pueda permitir incluso una pequeña cantidad de pagos fraudulentos, considera hacer ajustes para restringir aún más estas reglas antes de implementarlas.
Las reglas de permitidos se aplican a todos los pagos nuevos en cuanto creas la regla. Esto incluye cualquier pago que sea similar a pagos bloqueados anteriormente. Mientras pruebas una regla, asegúrate de lo siguiente:
- Examina la cantidad de pagos anteriormente bloqueados que ahora hubieran sido permitidos. Las reglas de permitidos anulan a todas las demás reglas y la evaluación de riesgos de Stripe. Cuando pruebes una nueva regla de permitidos, todos los pagos que aparezcan serán pagos que habrían sido permitidos si la regla hubiera estado activa. Puede incluir pagos bloqueados o puestos en disputa, lo que afectará tus tasas de disputas futuras.
- Sigue bloqueando los pagos de alto riesgo. Puedes hacerlo agregando este código a cualquier regla de permitidos:
and :risk_level: !='highest' - Evalúa un historial de transacciones legítimas en tu empresa. Puedes analizar las conexiones entre tus clientes para permitir un mayor volumen de transacciones conforme a un historial de compras legítimas. Así, podrás bloquear menos pagos de clientes con historial comprobado en tu empresa. Para ello, revisa la lista de atributos y busca los atributos que incluyan la palabra «cliente».
El siguiente ejemplo muestra cómo mejorar una regla de permitidos para una empresa que generalmente (aunque no siempre) recibe pagos legítimos de clientes en el Reino Unido:
| Regla original | Regla mejorada |
|---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
| Too broad—some fraudulent payments are allowed | Más específica: permite una menor cantidad de pagos fraudulentos |
Cómo mantener tus reglas
A medida que tu empresa crece, quieres asegurarte de que tus reglas sigan reflejando los tipos de clientes con los que quieres operar. A continuación te ofrecemos algunas de las mejores prácticas para mantener actualizadas las reglas conforme a la situación de tu negocio.
Controla las reglas periódicamente para asegurarte de que sigan siendo eficaces
Rule metrics
Los patrones de fraude cambian de manera constante, así que te facilitamos métricas para que puedas ver el desempeño de cada regla. Las métricas varían según el tipo de regla, ya que cada uno ejecuta una acción distinta.
Utiliza el gráfico de funcionamiento de las reglas para entender el comportamiento de tus reglas de Radar. Busca picos o descensos inesperados en la cantidad de pagos que coincidan con tus reglas, como reglas que aprueban o que bloquean demasiados pagos. Estos picos podrían indicar un cambio en los tipos de pagos que está recibiendo tu empresa o señalar que es necesario actualizar las reglas. En el gráfico, las actualizaciones de las reglas se marcan con triángulos y pueden ayudarte a comparar el efecto del cambio antes y después de realizarlo.
Las líneas por colores muestran la cantidad de pagos que coinciden con las reglas de 3DS, las reglas de permitidos, las reglas de bloqueo y las reglas de revisión. Los triángulos en las líneas de este gráfico representan las actualizaciones de las reglas del tipo correspondiente.
You can find information about the effectiveness of your rules and see how many payments each one has taken action against. You can also view and download a filtered list of every payment that a rule has been applied to. Evaluate this information to help you decide if you need to make changes to any rules or remove them entirely.
Para ver comandos adicionales, haz clic en el menú de contenido adicional (). Los comandos adicionales incluyen: Desactivar, Activar, Editar o Eliminar para cualquier regla.
También puedes utilizar nuestros productos de elaboración de informes, Sigma y Data Pipelines, para consultar disputas y datos de fraude, incluidas las decisiones y los atributos de las reglas para cada pago individual.
Evalúa la eficacia de las reglas
Puedes buscar información acerca de la eficacia de tus reglas y ver a cuántos pagos afectaron cada una de ellas. También puedes ver y descargar una lista filtrada de todos los pagos sobre los que se aplicó una regla. Revisa las preguntas de ejemplo de la siguiente tabla para decidir si tienes que modificar o eliminar alguna regla.
| Tipo de regla | Evaluar | Acciones para tener en cuenta |
|---|---|---|
| General | Si esta regla ya no coincide con ningún pago | Eliminar la regla. |
| Si esta regla tiene un comportamiento anómalo, como permitir más pagos que en períodos de tiempo anteriores. | Revisa manualmente los pagos que se correspondan con esta regla para determinar si este es el comportamiento que deseas. | |
| 3D Secure | Si la tasa de finalización de 3DS es alta, pero la cantidad de disputas o alertas preventivas de fraude es baja. | Elimina la regla, ya que puedes estar generando fricción para los buenos usuarios. |
| Si el fraude es alto para las transacciones que pasan 3DS. | Considera cambiar tu regla de 3D Secure a una regla de bloqueo para evitar que estos usuarios pasen el flujo sin fricción (controlado por los emisores) o cometan un fraude propio. | |
| Si la tasa de conversión de 3DS es baja. | Es posible que esta sea una buena regla, ya que podría estar bloqueando principalmente a los estafadores, pero considera investigar de forma manual los pagos correspondientes para asegurarte de que tus buenos usuarios no dejen de usar el servicio debido a una fricción adicional. | |
| De permiso | Si el número de disputas, alertas preventivas de fraude, reembolsos o pagos fallidos es alto. | Elimina la regla que permite que se autoricen los pagos incorrectos. |
| De bloqueo | ¿Está disminuyendo la cantidad de bloqueos, pero el nivel de fraude que experimentas sigue siendo constante o está aumentando? | Modifica tu regla, ya que es posible que ya no sea eficaz. |
| Si la cantidad de bloqueos aumenta, pero tu fraude sigue siendo constante o está aumentando. | Modifica tu regla, ya que podría estar bloqueando a los buenos usuarios. | |
| Si la cantidad de bloqueos aumenta y tu fraude disminuye. | Esto sugiere que tu regla es eficaz, pero considera revisar de forma manual algunas transacciones para asegurarte de que no estés bloqueando demasiados usuarios buenos. | |
| De revisión manual | Si el porcentaje de pagos que se revisan es bajo. | Modifica tu regla para que sea más restrictiva, ya que podría ser demasiado general. |
| Si el número de pagos exitosos o aprobados es alto. | Elimina por completo la regla de revisión manual o escribe una regla de permiso que apunte a esos pagos. | |
| Si el número de rembolsos o disputas y las Alertas Tempranas de Fraude son altas. | Convertir a una regla de bloqueo. |
Request 3DS rules
En el caso de las reglas para solicitar 3D Secure, se muestra lo siguiente:
- 3DS solicitado: la cantidad de veces que una regla activó una solicitud de 3DS.
Haz clic en una regla de 3D Secure para ver las siguientes métricas:
Reglas de permitidos
En el caso de las reglas de permitidos, los usuarios de Radar para Equipos de Fraude pueden ver lo siguiente:
- Pagos permitidos: la cantidad total de pagos permitidos por tus reglas.
- Volumen de pagos permitidos: el importe total, en tu moneda local, relacionado con los pagos permitidos por tus reglas.
- Puntuación de riesgo: los resultados de la evaluación de riesgos correspondientes, que los modelos de machine learning de Stripe asignan al conjunto de pagos permitidos por tus reglas.
- Disputas derivadas de anulaciones: la cantidad total de pagos permitidos que se disputaron.
- Volumen de disputas derivadas de anulaciones: el importe total, en tu moneda local, relacionado con las disputas de pagos permitidos.
Haz clic en una regla de permiso para ver las siguientes métricas:
Reglas de bloqueo
For block rules, we display:
- Pagos bloqueados: la cantidad total de pagos bloqueados por tus reglas.
- Volumen de pagos bloqueados: el importe total, en tu moneda local, relacionado con los pagos bloqueados por tus reglas.
Radar for Fraud Teams users can also view:
- Puntuación de riesgo: los resultados de la evaluación de riesgos correspondientes, que los modelos de machine learning de Stripe asignan al conjunto de pagos permitidos por tus reglas.
- Tasa estimada de falsos positivos: el porcentaje estimado de pagos no fraudulentos que se bloquearon debido a tus reglas de bloqueo en conjunto y a reglas individuales. (Para hacer el cálculo, Stripe utiliza las tasas estimadas de falsos positivos obtenidas gracias a la puntuación de riesgo del machine learning, que se estima a partir de experimentos llevados a cabo en toda la red de Stripe).
- Se evitaron los pagos fraudulentos estimados: la cantidad estimada de pagos fraudulentos que evitaron las reglas de bloqueo. Stripe utiliza puntuación de riesgo de machine learning, calculada mediante el análisis de millones de transacciones en toda la red de Stripe, para predecir pagos con una alta probabilidad de disputarse o rechazarse debido a fraude y estimar cuáles de esos pagos fueron bloqueados con éxito por tus reglas.
Haz clic en una regla de bloqueo para ver las siguientes métricas:
Review rules
En el caso de las reglas de revisión, los usuarios de Radar para Equipos de Fraude pueden ver lo siguiente:
- Pagos enviados a revisión: la cantidad total de pagos que se enviaron a revisión manual debido a tus reglas.
- Volumen de revisiones de pagos aprobados: el importe total, en tu moneda local, relacionado con las revisiones de pagos aprobados.
- Tasa de rembolso: el porcentaje de las revisiones rembolsadas.
- Disputas derivadas de revisiones de pagos aprobados: la cantidad total de pagos que se aprobaron en la revisión, pero que terminaron siendo disputados.
- Volumen de disputas derivadas de revisiones de pagos aprobados: el importe total, en tu moneda local, relacionado con las disputas de revisiones de pagos aprobados.
Haz clic en una regla de revisión para ver las siguientes métricas:
Controla periódicamente tu cola de revisión manual
Si tu cola de revisión es difícil de administrar porque es demasiado larga, revisa si tienes implementadas las reglas correctas. Si la mayor parte de las revisiones terminan con un rembolso por fraude, considera la posibilidad de agregar más reglas para bloquear pagos. Del mismo modo, si la mayoría de los pagos son aprobados, piensa en definir reglas de revisión más específicas.
Analiza tus pagos disputados y rembolsados
Las disputas están íntimamente ligadas al fraude, de manera que cuanto más medidas tomes para reducir el fraude, menor será tu tasa de disputas. Revisa si los pagos en disputa comparten alguna característica (por ejemplo, provienen del mismo lugar o tienen importes similares). También puedes hacer este tipo de investigaciones durante una revisión analizando los pagos que se reembolsaron. Si observas tendencias, podrás probar y crear las reglas apropiadas. Si algún pago parece fraudulento, te conviene reembolsarlo y denunciarlo como fraude para evitar posibles disputas.
También puedes usar nuestros productos de elaboración de informes, Sigma y Data Pipeline, para consultar disputas y datos sobre fraudes.
Puedes responder las disputas que lleguen usando el Dashboard o a través de la API. Además, nuestra documentación sobre disputas incluye algunas sugerencias sobre cómo presentar casos bien documentados.
Anticipa los grandes cambios en tu empresa que podrían influir en tu tasa de fraude
Si tienes pensado hacer lanzamientos importantes o cambios en tu servicio (por ejemplo, lanzar un nuevo producto de alto valor o expandir tu servicio a nuevos países), es posible que al principio quieras controlar los pagos. En el caso de este tipo de cambios, es aconsejable configurar algunas reglas de revisión para poder examinar los pagos nuevos. Revisar estos pagos e identificar patrones puede ayudarte a configurar nuevas reglas que protejan a tu empresa del fraude.