Referencia sobre reglas

Antes de crear una regla, tienes que entender cómo se procesan y qué atributos de pago puedes usar para definir los criterios de evaluación. Los sistema de fraude de machine learning de Stripe pueden bloquear muchos pagos fraudulentos por ti, pero también puedes configurar reglas específicas para tu empresa usando los atributos admitidos.

Procesamiento y ordenamiento de reglas

Radar evalúa cada pago según las reglas que creaste en función de su tipo de acción, utilizando la siguiente priorización:

1. Request 3DS: reglas que cuando se usan con la API Payment Intents o Checkout, solicitan al emisor que realice la autenticación mediante 3D Secure , en caso de que esta se admita. Radar evalúa estas reglas antes de proceder con las reglas de permitidos, bloqueos y revisión.
2. Permitir: reglas que permiten el procesamiento de un pago. Los pagos aprobados por reglas de permitidos no son evaluados con reglas de bloqueo o revisión.
3. Bloquear: reglas que bloquean un pago y lo rechazan. Los pagos bloqueados no son evaluados con reglas de revisión.
4. Revisar: reglas que permiten que los pagos sean procesados, pero luego son colocados en revisión.

Las reglas del mismo tipo de acción no están ordenadas.

Si un pago coincide con el criterio de una regla, Radar toma la medida correspondiente e interrumpe la evaluación. Por ejemplo, si un pago coincide con una regla de permitidos, se procesa normalmente, sin evaluar ninguna regla de bloqueo o revisión posterior, incluso si el pago también cumpliera con sus criterios. Un conjunto de reglas de ejemplo podría ser el siguiente:

• Permitir pagos inferiores a $10
• Permitir pagos realizados dentro de Estados Unidos y con un nivel de riesgo normal
• Bloquear pagos con un nivel de riesgo high
• Block pagos greater than $1,000
• Revisar pagos realizados con una tarjeta emitida outside the US

Cómo usar las reglas anteriores:

• Se procesan todos los pagos inferiores a USD 10, independientemente de su nivel de riesgo o lugar de emisión. Dado que la primera regla permite el pago, no se evaluarán más reglas.
• Un pago de USD 1500 realizado dentro de EE. UU. con un nivel de riesgo normal se procesa normalmente porque cumple con los criterios de la segunda regla, por lo que no se evalúa según la regla para bloquear pagos superiores a USD 1000.
• Un pago de alto riesgo de más de USD 1000 se bloquea porque no cumple con los criterios de ninguna de las dos reglas de permitidos y, luego, activa ambas reglas de bloqueo, independientemente del orden de evaluación.

Estructura de la regla

La estructura de la regla tiene dos componentes: la acción que se llevará a cabo y la condición para hacer la evaluación:

{action} if {condition}

Juntos representan el predicado. En la práctica, una regla para bloquear todos los pagos superiores a USD 1000 se presenta así:

Block if :amount_in_usd: > 1000.00

• La acción es Block
• La condición es :amount_in_usd: > 1000.00

Acciones

Una regla realiza una de las cuatro acciones descritas en esta sección cuando un pago cumple con sus criterios. El orden de los siguientes tipos de acción representa la prioridad que Radar sigue al evaluar cada regla.

Solicitud de 3D Secure

Cuando se utiliza con la API Payment Intents, esta regla determina si Stripe solicita al emisor que intente la autenticación mediante 3D Secure. Solicitar 3DS por sí solo no bloquea todos los resultados de 3D Secure. Independientemente de si hay coincidencias en esta regla, evaluamos las reglas para permitir, bloquear y revisar después.

Permitir

Esta regla determina cuándo permitir un pago que cumpla con determinados criterios, independientemente de cualquier otra regla coincidente. Cuando un pago concuerda con los criterios de una regla de permitidos, no queda sujeto a otras reglas de verificación. A pesar de que Stripe procese el pago, el emisor de la tarjeta puede rechazarlo.

Block

Las reglas de bloqueo especifican que Stripe debe siempre bloquear un pago. Si un pago coincide con el criterio de la regla de bloqueo, Stripe lo rechazará y no estará sujeto a otras reglas de evaluación.

Revisar

Quizás quieras autorizar determinados tipos de pago y a la vez tener la opción de examinarlos con más detenimiento. Puedes poner un pago en revisión usando reglas de revisión. Esta acción es muy útil para los pagos que no entran dentro de los patrones comunes, como los pagos más grandes o los pagos de países a los que no sueles hacer envíos. Stripe procesará estos pagos de todos modos y le cobrará al cliente, pero tendrás la oportunidad de revisar el pedido y verificar si hay señales de fraude.

Cuando se activa una regla en particular, Radar acciona según la orden correspondiente e interrumpe todas las evaluaciones adicionales de la regla.

Condiciones

Si un pago coincide con la condición de una regla, se toma la medida correspondiente. Una condición básica se compone de tres partes:

[attribute] [operator] [value]

• Attribute: el atributo de un pago (por ejemplo, el importe o tipo de tarjeta)
• Operator: la aritmética que compara el atributo con el valor (por ejemplo, superior a o no igual a)
• Value: The criteria you want to use (for example, 100.00 or debit)

Si se combina la acción y la condición, esta es la estructura de la regla:

{action} if {[attribute] [operator] [value]}

Hay cuatro tipos de condiciones según el tipo de atributo:

• [string_attribute] [operator] [string_value]
• [country_attribute] [operator] [country_value]
• [numeric_attribute] [operator] [numeric_value]
• [boolean_attribute]

También puedes utilizar atributos como valor correspondiente dentro de una condición. Por ejemplo, puedes crear una regla para bloquear pagos cuando el país emisor de la tarjeta no coincida con el país en el que se efectuó el pago:

Block if :card_country: != :ip_country:

Para acceder a una lista de todas las condiciones posibles, consulta los atributos admitidos.

Atributos de cadena

Estos contienen cualquier combinación de caracteres. Los valores y atributos de cadena generalmente representan un texto, como la marca de la tarjeta (por ejemplo, visa, amex), o el nivel de riesgo (por ejemplo, elevated). Puedes usarlos en las reglas para permitir pagos solo desde un determinado país o para bloquear pagos efectuados con tarjetas de prepago.

Atributos de metadatos

Estos atributos derivan de los metadatos que adjuntaste a tus pagos. Los atributos de metadatos pueden operar como cadenas o como números. Cuando se usan como cadenas, los atributos de metadatos distinguen entre mayúsculas y minúsculas.

Puedes usar estos atributos cuando creas reglas de Stripe Radar, lo que te permitirá escribir reglas tomando en cuenta todos los atributos de empresa personalizados que le hayas pasado a Stripe en el campo de metadatos asociado con los pagos.

Los atributos de metadatos se escriben según la siguiente estructura:

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

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

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

Revisar if ::Customer Age:: < 30

También puedes escribir reglas con atributos de metadatos y otros atributos admitidos mencionados en este documento. Por ejemplo, puedes escribir una regla que coloque un pago en revisión solo si el Item ID coincide con 5A381D y el importe de pago excede los USD 1000.

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

Los atributos de metadatos también admiten el operador IN para encontrar equivalencias con varios valores. Por ejemplo, puedes escribir una regla que coloque el pago en revisión si la Category ID es comestibles, electrónica o indumentaria.

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

Puedes usar el operador INCLUDES con reglas para atributos de metadatos y otros atributos de cadena para que coincidan con las subcadenas. Por ejemplo, puedes escribir una regla que ponga un pago en revisión si el Item ID incluye la cadena A381. Esto coincide con A381, 5A381D, A381D, 5A381, etc.

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

Metadatos en objetos Customer y Destination

También puedes acceder a los metadatos en los objetos Customer y Destination (si se han utilizado para un pago determinado). Estos atributos usan la siguiente estructura:

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

Por ejemplo, supongamos que tienes un cliente con los siguientes metadatos:

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

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

O si tienes un destino con los siguientes metadatos:

Puedes escribir una regla que coloque el pago en revisión si el campo de metadatos Category del destino es new.

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

Atributos de país

Se usan los códigos de país de dos letras para representar el país, por ejemplo, US para Estados Unidos, GB para Gran Bretaña o AR para Argentina. Los atributos de país funcionan de la misma manera que los atributos de cadena, la única diferencia es que el valor debe ser el código de país.

Atributos de estado

Estos atributos utilizan los códigos ISO para representar el estado o la subdivisión principal de un país, como CA para representar a California de los Estados Unidos, ENG para representar a Inglaterra, que es parte de Gran Bretaña, o L para representar a La Pampa, que es parte de Argentina. Omitimos el código de país de dos letras del código ISO del estado, por lo que si deseas bloquear las transacciones de California, compara el atributo de estado con CA.

Bloquear si :ip_state: = 'CA'

Los atributos de estado funcionan de la misma manera que los atributos de cadena, la única diferencia es que el valor debe ser un código ISO.

Atributos numéricos

Como estos solo contienen números, admiten más operadores que los valores y atributos de cadena. Un ejemplo de un atributo numérico es el importe de un pago. Puedes creas una regla para lleve a cabo una acción si el importe es superior, inferior, igual o no igual al importe especificado.

For numeric attributes that are counts over time windows, the count excludes the payment that you’re currently processing. For example, total_charges_per_customer_hourly represents the number of previous charge attempts from a given customer in the preceding hour. So, for the first charge attempt in a given hour for a customer, total_charges_per_customer_hourly has a value of 0. For a second charge attempt within the same hour, it has a value of 1, and so on.

Los atributos time-since-first-seen (tiempo transcurrido desde que se vio por primera vez) tampoco tienen en cuenta el pago que está en proceso. Por ejemplo, a un pago sin un correo electrónico asociado le falta el valor de seconds_since_email_first_seen. Lo mismo ocurre con los pagos con correos electrónicos que nunca antes aparecieron en tu cuenta (debido a que no incluimos el pago que se encuentra en proceso, este comportamiento es el mismo que el del primer ejemplo). Para obtener más detalles sobre los valores faltantes, sigue leyendo. El campo seconds_since_email_first_seen será distinto de cero solamente después de procesar un pago nuevo con un correo electrónico asociado.

Bounded numeric attributes

Los atributos numéricos limitados son similares a los atributos numéricos descritos anteriormente. Por ejemplo, no incluyen el pago que se está procesando en el momento. La diferencia es que los valores disponibles para los atributos numéricos limitados tienen un tope (o un límite), que es un valor específico.

Por ejemplo, authorized_charges_per_email_hourly representa la cantidad de cargos previos que se autorizaron para un correo electrónico durante la última hora en tu cuenta. Supongamos que su límite es 5. Para el primer intento de pago en la última hora de parte del correo elena.garcia@ejemplo.com, el contador tiene un valor de 0. Los intentos de pago siguientes que se realicen en la misma hora tendrán valores mayores en el contador. Después de autorizar el sexto cargo dentro de la misma hora para elena.garcia@ejemplo.com, el contador dejará de aumentar y se quedará en 5, a pesar de haberse hecho 6 intentos de pago en la última hora.

Si se intenta aumentar el contador por encima del límite, se dejan de tener en cuenta los valores anteriores, que se reemplazan por valores más nuevos. Por ejemplo, considera un contador con un límite de 3 que se ha completado con 3 cargos. Una forma de visualizar el contador es llevando una lista de marcas temporales que representen la hora en la que llegan los cargos, como [10, 20, 30]. Si un cargo llega en la hora 50, el contador mostrará [20, 30, 50].

Atributos booleanos

A Boolean attribute represents whether a particular attribute is true. Unlike string and numeric attributes, Boolean attributes have no operators or values. You can use a Boolean attribute to block payments that have been made with a disposable email address, or place payments in review that were made with an anonymous IP address.

Atributos de posautorización

Un atributo de posautorización (por ejemplo, :cvc_check:, :address_zip_check:, o :address_line1_check:) exige que Stripe intercambie datos con los emisores de las tarjetas como parte del proceso de autorización. El emisor de la tarjeta verifica si los datos corresponden a la información que tiene en sus registros sobre el titular de la tarjeta. Las reglas que usan atributos de posautorización son ejecutadas después de las reglas que no usan estos atributos. (Esto no afectará la decisión de bloquear el cargo o no, pero puede influir en qué regla se aplica para bloquear el cargo).

Si usas un atributo de posautorización en una regla, es posible que se vea temporalmente una autorización en el extracto del cliente aunque el cargo esté bloqueado. Por lo general, la autorización desaparece después de unos días.

Los atributos de domicilio (AVS) y CVC tienen cinco valores posibles:

Algunas reglas de ejemplo:

• Block if :address_line1_check: = 'fail'
• Block if :cvc_check: = 'fail'
• Block if :address_zip_check: in ('fail', 'not_provided')

Exigir un pass estricto en las reglas puede ser demasiado restrictivo. Por ejemplo, las carteras no suelen proporcionar un CVC porque almacenan los datos tokenizados de la tarjeta. Por lo tanto, los cheques con CVC, por ejemplo, los cheques con 3D-Secure, no están disponibles para los métodos de pago como Apple Pay. Stripe recomienda usar las reglas integradas, de Radar, que tienen en cuenta estos casos extremos.

Atributos admitidos

Consulta la lista de todos los atributos admitidos para acceder a una lista completa de atributos que puedes aplicar a tus definiciones de reglas.

Importes convertidos

Al usar amount_in_xyz, Stripe determina automáticamente el importe convertido de un pago cuando verifica si el importe coincide con el criterio seleccionado. Por ejemplo, si creas una regla con amount_in_usd para bloquear todos los pagos superiores a USD 1000, Stripe bloqueará un pago de un importe nominal inferior en otra moneda (por ejemplo, GBP 900) si el valor convertido equivalente excede los USD 1000.

“Takes into account payments from 2020 onwards” in practice

En la descripción de los atributos de algunas reglas se incluye la frase «Se toman en cuenta los pagos a partir de 2020». Esto significa que la regla considera a una tarjeta cuya última transacción con tu empresa fue en 2019 de igual forma que a una tarjeta que es nueva para tu empresa. Piensa sobre cómo se traduce esto en el contexto de tu empresa y tus reglas, ya que podría traer aparejado un comportamiento contradictorio. Por ejemplo, si creas una regla para bloquear pagos de alto valor provenientes de tarjetas nuevas, podrías terminar bloqueando a un buen cliente que no ha realizado una compra desde 2019.

«Este atributo solo incluye los objetos Customer en modo activo que interactuaron con tu cuenta en el último/la última <week, year>. Estos datos se actualizan como máximo cada 72 horas». en la práctica

Las descripciones de algunos atributos de reglas incluyen el siguiente texto: «Este atributo solo incluye los objetos Customer en modo activo que interactuaron con tu cuenta en el último/la última <week, year>. Estos datos se actualizan como máximo cada 72 horas». Esto significa que los objetos Customer en modo activo que se crearon, cargaron o actualizaron en tu cuenta en la última semana o el último año se incluyen en estos recuentos. No obstante, el recuento no se actualiza de inmediato y podría demorar hasta 72 horas en propagarse a través del sistema, aunque a menudo estos recuentos se actualizan antes de las 72 horas.

Operadores

El operador de una condición denota la comparación entre el atributo de pago y el valor que especificaste. Hay diferentes operadores disponibles según el tipo de atributo que se use.

Listas

Puedes hacer referencia a un conjunto de valores en tus reglas por medio de listas. Todos los alias de las listas a las que hagas referencia en las reglas deben comenzar con @. Para construir una regla que haga referencia a una lista, sigue esta estructura:

{action} [attribute] in [list]

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

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

También puedes escribir una regla usando una lista insertada:

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

También puedes crear una lista de países de tarjetas que quieres bloquear, denominada card_countries_to_block. Luego, puedes agregar a la lista los países que quieras y hacer referencia a esa lista en una regla:

Block if :card_country: in @card_countries_to_block

Si haces referencia a una lista en una regla, podrás editar una gran cantidad de elementos en un solo lugar en lugar de tener varias reglas separadas.

Atributos faltantes

Las condiciones típicas de una regla hacen referencia a los atributos definidos en todos los pagos, como :card_country: (que se define para todos los cargos con tarjeta), o a un atributo de metadatos que siempre envías con tus solicitudes de pago. En algunos casos, puede faltar un atributo, por ejemplo:

• Tienes diferentes flujos para finalizar la compra en tu sitio, y algunos de ellos no recopilan las direcciones de correo electrónico de los clientes

• Has empezado a usar Stripe.js y por eso, :ip_country: está disponible para los pagos nuevos, pero no para los pagos anteriores (que buscamos cuando previsualizamos reglas)

• Para algunos de los pagos, no se puede definir la clave de metadatos esperada por un error en la integración

De qué manera las condiciones de las reglas evalúan los atributos faltantes

Considera la regla Block if :email_domain: = 'definitelyfraud.com'. Si no recopilaste la dirección de correo electrónico del cliente, el atributo :email_domain: no existe, entonces la condición de la regla no coincidirá con el pago.

Ahora considera la regla Review if :email_domain: != 'definitelysafe.com'. Si falta el atributo :email_domain:, esta regla tampoco coincide con el pago. Podría parecer una coincidencia porque ningún valor es 'definitelysafe.com'. Sin embargo, interpretamos que != 'definitelysafe.com' significa «el atributo tiene algún valor distinto de 'definitelysafe.com'», que un atributo que falta no satisface. La información del atributo que falta también se transfiere cuando se utiliza el operador NOT, por lo que la regla Review if NOT (:email_domain: = 'definitelysafe.com') tampoco coincide con el pago si falta el atributo :email_domain:.

En términos más generales, cualquier comparación (por ejemplo, =, !=, >, <) entre una característica no encontrada con otra característica o valor estático (presente o no) siempre resulta falso. El uso del operador NOT con cualquier comparación que contenga una función faltante siempre resulta falso.

Gestión explícita con la función is_missing

Si quieres verificar expresamente la existencia de un atributo o un atributo de metadatos, utiliza la función is_missing. Ingresa esta función con el atributo o la clave de metadatos que falte.

Por ejemplo, si no tienes acceso a la dirección de correo electrónico del cliente, puedes escribir una regla que coincida con todos los pagos:

• Review if is_missing(:email_domain:)

O también puedes escribir una regla que coincida con todos los pagos que tengan un determinado atributo de metadatos configurado:

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

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

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

Condiciones complejas

Puedes diseñar condiciones complejas uniendo condiciones básicas con operadores AND, OR y NOT. También puedes usar los símbolos equivalentes: &&, || y !, respectivamente.

Al igual que los lenguajes de programación, como C, Python y SQL, Stripe admite la prioridad de operador estándar (orden de las operaciones). Por ejemplo, la condición compleja:

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

se interpreta como:

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

También se admite el agrupamiento subcondicional dentro de condiciones complejas mediante el uso de paréntesis. Por ejemplo, puede corregir el ejemplo anterior para cambiar de manera explícita el orden de evaluación de los subpredicados:

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

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

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

Condiciones válidas

Las siguientes condiciones son ejemplos de usos correctos de atributos y un operador admitido:

• :card_brand: = 'amex'
• :card_country: != 'US'
• :amount_in_usd: >= 1000.00
• :is_anonymous_ip:

Condiciones no válidas

Cuando se crea una regla, Radar proporciona comentarios si intentas usar una condición no válida. A modo de referencia, los siguientes ejemplos son condiciones no válidas, en las que no se admite el valor de un atributo o el operador utilizado:

• :risk_level: < 'highest' (string values can only make use of = or != operators)
• :ip_country: = 'Canada' (los valores de país deben expresarse con el código corto de dos letras)
• :amount_in_usd: >= 'one thousand dollars' (los valores numéricos deben expresarse en números)
• :is_anonymous_ip: = 'true' (Boolean attributes are not used with operators or values)

Reglas de velocidad

Muchos atributos admitidos incluyen invariantes para diferentes escalas de tiempo (por ejemplo, el daily en total_charges_per_email_daily). Estas se llaman reglas de velocidad.

Stripe calcula los atributos utilizando incrementos de bucket. La longitud del incremento varía según el intervalo de atributo. Esto significa que la velocidad de un atributo puede incluir datos que ocurrieron dentro del intervalo más un bucket. Por ejemplo, un intervalo de atributo por hora puede ser de 3900 segundos (una hora y cinco minutos) de la transacción actual porque el intervalo utiliza buckets de cinco minutos.

Los atributos se definen como:

• hourly dura hasta 3900 segundos (buckets de 5 minutos).
• daily dura hasta 90000 segundos (buckets de 1 hora).
• weekly dura hasta 608400 segundos (buckets de 1 hora).
• yearly es de hasta 31622400 segundos (buckets de 1 día).
• all_time incluye 5 años de datos con una velocidad de hasta 31622400 segundos (buckets de 1 día).

Un caso de uso común para estos atributos es reducir la prueba de tarjetas o los casos de ataque de enumeración, como se explica en la guía de los aspectos básicos de Radar.