As regras padrão da Stripe usam machine learning para prever e bloquear uma ampla gama de pagamentos fraudulentos. Para empresas que precisam de mais controle sobre quais pagamentos devem ser revisados, permitidos ou bloqueados, as regras são uma ferramenta poderosa para personalizar a proteção contra fraudes.

Este guia abrange vários assuntos relacionados a regras do Radar, inclusive 100 regras do Radar que você pode usar e práticas recomendadas sobre backtesting, criação de regras e muito mais.

Vamos começar.

A importância da ordem e da hierarquia das regras

A ordem em que as regras aparecem na sua página do Radar é importante. Cada pagamento é avaliado em relação às regras que você criou e executou nesta ordem:

1. Request 3DS: Regras que solicitam a autenticação do 3D Secure quando usadas com a API Payment Intents ou Checkout. Independentemente das correspondências nessa regra, as regras de permissão, bloqueio e análise são avaliadas depois.
   
2. Allow: Regras que permitem que o pagamento seja processado. Regras de permissão devem ser implementadas com cuidado, pois elas sobrepõem todas as outras regras, exceto as 3DS e devem ser usadas com muita cautela. Apenas comerciantes que processaram mais de US$ 100 mil podem criar regras de permissão.
   
3. Block: Regras que bloqueiam e rejeitam o pagamento. Se o pagamento for rejeitado, ele não será avaliado em relação às regras de análise.
   
4. Review: Os pagamentos ainda serão processados e o cliente será cobrado, mas esses pagamentos serão sinalizados para que você dê uma olhada neles de novo se quiser.
   

Para colocar isso em prática, vamos usar as regras a seguir como exemplo. Todos os pagamentos abaixo de US$ 10 seriam processados. Isso porque a primeira regra permite o pagamento, então nenhuma regra posterior é avaliada. Da mesma forma, seguindo essas regras, um pagamento de US$ 1.500 feito dentro dos EUA com um nível de risco normal também seria permitido, apesar da regra de bloqueio de pagamentos acima de US$ 1.000. Isso por causa da segunda regra da lista, que permite pagamentos feitos dentro dos EUA com nível de risco normal. Assim que uma regra específica é acionada, nenhuma outra regra posterior é avaliada.

• 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

Tabela de resumo da linguagem de regras

As regras são similares ao SQL e há diferentes operadores que você pode usar com base no tipo de dados que você usa para criar a regra. Confira uma tabela de resumo.

Se você quiser conferir explicitamente se um atributo ou atributo de metadados existe, não use o operador !=, mas sim a função is_missing. Insira nessa função o atributo ou a chave de metadados que pode estar ausente. Por exemplo, você pode criar uma regra para corresponder todos os pagamentos em que você não tem acesso ao e-mail do cliente:

• Review if is_missing(:email_domain:)
  

Ou criar uma regra para corresponder todos os pagamentos em que o e-mail do cliente NÃO está ausente:

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

Criação de regras usando linguagem natural

Você quer criar regras de um jeito mais fácil, ou não sabe bem quais atributos usar em um cenário de fraude específico? O Radar Assistant usa IA para transformar o que você escreve em regras aplicando a sintaxe do Radar. Também é possível fazer backtesting das regras direto no Radar Assistant. Assim você consegue ver como teria sido o desempenho delas nos dados históricos antes de implementá-las.

Regras do Radar usadas com frequência

Esta lista contém algumas das regras mais usadas do Radar com base em diferentes objetivos.

Regras que ajudam a evitar teste de cartões e saques com cartão

Regras que ajudam a evitar fraudes com SKUs de alto risco

Essa regra precisa de metadados ou transmissão de informações da SKU como a descrição da cobrança. Os pagamentos ainda serão processados e o cliente será cobrado, mas esses pagamentos serão sinalizados para que você dê uma olhada neles de novo.

Regras que ajudam a evitar abuso de avaliação gratuita de cartões pré-pagos

Análise de fraude para orientar a criação de regras

Análises de fraudes

Para produzir as regras mais eficientes possíveis, é preciso entender profundamente a atividade fraudulenta da conta. É importante caracterizar os diferentes tipos de vetores de fraude presentes. Algumas perguntas a se fazer:

• As contas estão fazendo compras fraudulentas imediatamente após serem criadas usando novos e-mails e nomes de titulares de cartão?

• Os agentes fraudulentos estão acessando contas antigas e fazendo compras de valores anormalmente altos?

• A fraude é direcionada a bandeiras de cartão ou países específicos?

• Está ocorrendo fraude em alta velocidade, ou seja, várias tentativas do mesmo cartão, e-mail ou endereço IP em um curto período?

Analisando a fraude de alta velocidade que ocorre na captura de tela acima, as regras que utilizam authorized_charges_per_card_number_hourly ou authorized_charges_per_ip_address_hourly talvez pudessem resolver esse vetor de fraude.

Tenha acesso a mais insights de fraudes

Os insights de fraudes podem ajudar a identificar e corrigir as causas das fraudes com mais rapidez sem precisar analisar manualmente os dados de transações. A guia Insights no Dashboard mostra os principais atributos associados a transações fraudulentas. Você pode adicionar uma regra para corrigir o atributo direto na guia Insights.

Três tipos de atributos para criar regras

Tipo 1

atributos de pós-autorização: disponíveis para uso geral. É preciso colocar dois-pontos antes e depois dos atributos de pós-autorização, como em :cvc_check:.

Veja um exemplo de como usar atributos de pós-autorização:

• Block if :address_line1_check: != 'pass' Com essa regra em vigor, todas as cobranças serão bloqueadas se não passarem especificamente na verificação do emissor do cartão, que confere se a primeira linha do endereço de faturamento fornecido corresponde às informações registradas sobre o titular do cartão. Isso significa que, se a verificação não estiver disponível (unavailable), se os dados não tiverem sido verificados (unchecked) pelo emissor ou se os dados não tiverem sido fornecidos pelo emissor (not_provided), o pagamento será bloqueado.
  

Tipo 2

atributos padrão: disponíveis para uso geral. É preciso colocar dois-pontos antes e depois dos atributos padrão, como em :card_bin:. Dividimos nossos atributos padrão em quatro categorias:

• Atributos baseados em frequência; útil para evitar teste de cartões e saques com cartão
  
• Atributos baseados em dados do cartão
  
• Atributos baseados em informações de pagamento
  
• Atributos baseados em informações do cliente
  

Alguns atributos exigem valores como strings, enquanto outros exigem valores como números. Fornecemos um exemplo de cada atributo para deixar isso claro. Se o atributo exigir uma string, como é o caso de :card_bin:, você verá no exemplo que o número está entre ' '. Por exemplo, :card_bin: = '424242', embora exija um número, não terá ' ', como:amount_in_usd: > 250.

Atributos baseados em frequência

Há quatro tipos de atributos baseados em frequência que são especialmente úteis para evitar fraudes de cartão roubado, teste de cartões e saques com cartão.

1. Autorização: com base em autorizações do emissor
   
2. Cobrança: com base em cobranças
   
3. Pagamento recusado: com base em pagamentos recusados pelo emissor
   
4. Bloqueio: com base em bloqueios feitos pelo machine learning do Radar
   

Há também atributos baseados em resultados de cobrança, como autorizações (com base em autorizações bem-sucedidas do emissor), cobranças (com base em tentativas de cobrança), pagamento recusado (com base em pagamento recusado pelo emissor), contestações (transações anteriores contestadas como fraudulentas) e bloqueios (com base em bloqueios feitos pelo machine learning do Radar). Os resultados são combinados com as informações do cliente (e-mail, endereço IP, nome ou ID do cliente) para formar um atributo.

Além disso, você pode combinar a frequência da informação do cliente (e-mail, nome) com o cartão ou endereço IP usado em uma transação. Ou seja, há dois tipos de regra de frequência disponíveis:

1. Com base no resultado da cobrança (por exemplo, authorized_charges_per_email_hourly, blocked_charges_per_email_hourly), que pode ser autorização bem-sucedida, tentativa de cobrança, pagamento recusado, contestação ou bloqueio
   
2. Com base na associação entre as informações do cliente e as do cartão ou IP (por exemplo, name_count_for_card_weekly, email_count_for_ip_hourly)
   

As regras de frequência excluem o pagamento que você está processando no momento. Por exemplo, authorized_charges_per_email_hourly representa o número de tentativas bem-sucedidas de cobrança de um e-mail na última hora. Para a primeira tentativa de cobrança em determinada hora para um e-mail, authorized_charges_per_email_hourly tem o valor de 0. Se a primeira tentativa for bem-sucedida, a segunda tentativa que ocorrer nessa mesma hora para esse e-mail terá o valor de 1, e assim por diante.

Atributos baseados em dados do cartão

Atributos baseados em informações de pagamento

Atributos baseados em informações do cliente

Veja um exemplo de como usar atributos padrão:

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

Com essa regra em vigor, qualquer cobrança de um cartão emitido no Canadá, na Alemanha ou nos Emirados Árabes Unidos será bloqueada.

Tipo 3

Atributos de metadados: esses atributos dependem de quais metadados você envia à Stripe. É preciso colocar dois-pontos antes e depois dos atributos padrão, como em ::Customer Age::. Os atributos de metadados podem funcionar como strings ou números. Quando usados como strings, os atributos de metadados diferenciam maiúsculas de minúsculas.

Os metadados podem ser usados para criar regras muito eficientes, como colocar cobranças em análise manual com base na SKU adquirida ou reduzir o atrito para clientes recorrentes. Para saber como passar mais metadados, leia este guia.

Os atributos de metadados são criados com a seguinte estrutura:

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

Vamos supor que temos pagamentos com os seguintes dados chave-valor armazenados no campo de metadados:

É possível criar uma regra que envia para análise os pagamentos que cumprem os critérios especificados.

• Review if ::Customer Age:: < 30
  

Você também pode criar regras usando atributos de metadados e outros atributos compatíveis mencionados neste documento. Por exemplo, você pode criar uma regra que só envia o pagamento para análise se o ID do item corresponder a 5A381D e se o valor para pagamento for superior a US$ 1.000.

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

Os atributos de metadados também oferecem suporte ao operador IN para fazer correspondência a vários valores. Por exemplo, você pode criar uma regra que envia o pagamento para análise se o ID da categoria for "groceries", "electronics" ou "clothing".

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

O operador INCLUDES pode ser usado com regras para atributos de metadados e outros atributos de string para fazer correspondência com substrings. Por exemplo, você pode criar uma regra que envia o pagamento para análise se o ID do item inclui a string A381. Essa regra faria a correspondência com "A381", "5A381D", "A381D", "5A381" e outros.

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

Também é possível acessar metadados nos objetos Customer e Destination (se usados em um determinado pagamento). Esses atributos são criados com a seguinte estrutura:

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

Suponha que você tem um cliente com estes metadados:

É possível criar uma regra que permite pagamentos se o campo Trusted dos metadados do cliente é true.

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

No caso de um destino com os seguintes metadados:

É possível criar uma regra que envia para análise os pagamentos se o campo Category dos metadados é new.

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

Uso de listas salvas nas suas regras (como lista de permissões, lista de bloqueio)

Você pode fazer referência a um grupo de valores das suas regras por meio de listas criadas previamente (como lista de permissões ou lista de bloqueio). Se você estiver tentando bloquear uma lista de e-mails, crie uma lista de bloqueio em vez de criar várias regras para cada e-mail que você deseja bloquear.

Todos os alias da lista mencionados nas regras devem começar com @. Para criar uma regra que faça referência a uma lista, é preciso usar a seguinte estrutura:

• {action} [attribute] in [list]
  

Por exemplo, digamos que você tenha uma lista de países do cartão que deseja bloquear. É possível criar uma regra usando várias cláusulas OR:

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

Também é possível criar uma regra usando uma lista em linha:

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

Você também pode criar uma lista de países do cartão que deseja bloquear chamada card_countries_to_block. Depois você pode adicionar os países que quiser à lista e fazer referência a essa lista na regra:

• Block if :card_country: in @card_countries_to_block
  

Além de mais simples, as regras que usam listas são mais fáceis de editar e permitem adicionar facilmente um grande número de itens.

Criação de regras complexas com várias condições

Você pode criar condições complexas associando condições básicas com os operadores AND, OR e NOT. Também é possível usar os símbolos equivalentes a esses operadores: &&, || e !, respectivamente. Assim como nas linguagens de programação como C, Python e SQL, a Stripe usa a precedência padrão de operadores (ordem de operações). Por exemplo, a condição complexa:

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

é interpretada como:

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

Também há suporte ao agrupamento subcondicional dentro de condições complexas com o uso de parênteses. O exemplo anterior poderia ser corrigido para alterar explicitamente a ordem de avaliação de subpredicados:

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

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

Com o uso de parênteses em locais distintos, cada uma dessas condições complexas gera resultados diferentes.

Também é possível usar a função is_missing com as conjunções OR ou AND:

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

Ou você pode usar a função is_missing quando algo não estiver ausente, neste caso, para bloquear pagamentos se :ip_country: NÃO estiver ausente e se o IP for de EUA ou PR.

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

Regras de backtesting

Como filosofia geral da análise de regras, há um meio-termo entre evitar fraudes e bloquear transações legítimas ou falsos positivos. O backtesting ajuda a identificar regras que se enquadram na sua predisposição a assumir riscos ou atingir o equilíbrio desejado entre contestações evitadas e aumento de falsos positivos. Para estimar o impacto de uma regra, você pode fazer backtesting de combinações usando dados de transações dos últimos seis meses por meio do Radar Dashboard e realizar análises mais direcionadas para entender qual teria sido o desempenho da regra se ela estivesse em vigor.

Backtesting no Dashboard

As definições do que constitui pagamentos fraudulentos e bem-sucedidos variam de acordo com o tipo de regra que você está testando:

Regra de bloqueio

• Houve contestação, recebimento de alerta antecipado de fraude ou reembolso por fraude: cobranças bem-sucedidas que foram contestadas ou reembolsadas por fraude ou cobranças bem-sucedidas enviadas para análise que foram contestadas ou reembolsadas por fraude

• Outros pagamentos bem-sucedidos: cobranças bem-sucedidas que não foram contestadas nem reembolsadas por fraude ou cobranças bem-sucedidas enviadas para análise e que não foram contestadas nem reembolsadas por fraude

• Tentativas de pagamento com falha: pagamento recusado pelo emissor ou bloqueado pelo Radar

Regra de análise

• Houve contestação, recebimento de alerta antecipado de fraude ou reembolso por fraude: cobranças bem-sucedidas que foram contestadas ou reembolsadas por fraude

• Outros pagamentos bem-sucedidos: cobranças bem-sucedidas que não foram contestadas nem reembolsadas por fraude

• Houve falha ou envio para análise: pagamento recusado pelo emissor, bloqueado pelo Radar ou cobranças bem-sucedidas enviadas para análise (independentemente do status de contestação ou reembolso)

Regra de permissão

• Bloqueado pela Stripe ou por suas regras personalizadas: cobranças bloqueadas pelo Radar

• Houve contestação, recebimento de alerta antecipado de fraude ou reembolso por fraude: cobranças bem-sucedidas que foram contestadas ou reembolsadas por fraude ou cobranças bem-sucedidas enviadas para análise que foram contestadas ou reembolsadas por fraude

• Outros pagamentos bem-sucedidos ou recusados pelo banco: pagamento recusado pelo emissor, cobranças que não foram contestadas nem reembolsadas por fraude, ou cobranças bem-sucedidas enviadas para análise e que não foram contestadas nem reembolsadas por fraude

Análises personalizadas de backtesting

O recurso de backtesting do Radar Dashboard foca os últimos seis meses de transações e inclui contestações, alertas antecipados de fraude e cobranças reembolsadas como fraudulentas.

Faça uma análise mais direcionada se, por exemplo, você estiver em risco de identificação em um Programa de monitoramento de fraudes da Visa (com foco exclusivo em alertas antecipados de fraude) ou se notar um pico de fraudes recente vindo de um tipo de carteira ou de um país de IP específico. Para isso, você pode criar uma consulta SQL no Sigma ou exportar e analisar relatórios de dados de pagamento no Dashboard. O backtesting personalizado proporciona flexibilidade em prazos (além de seis meses) e análises mais direcionadas (por exemplo, você pode se concentrar apenas em contestações ou EFWs). O exemplo de consulta abaixo faz o backtesting de alertas antecipados de fraude (EFWs) da Visa sobre transações de até US$ 100 se, hipoteticamente, você descobriu que o volume de fraude aumentou nos últimos tempos em valores mais altos e que as transações com pontuação de risco elevada criaram riscos no programa de monitoramento:

Uso de campos e tabelas disponíveis no 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

O backtesting dos últimos 60 dias por data de criação do EFW se concentra nas fraudes mais recentes, ao passo que o backtesting dos últimos 60 a 120 dias de vendas não fraudulentas permite analisar fraudes em estágios mais avançados.

Vetores de fraude comuns

A maioria dos agentes fraudulentos segue o mesmo padrão ao cometer a fraude. Primeiro eles validam as informações de pagamento roubadas (por exemplo, cartões). Depois de validar, eles usam essas credenciais para extrair valor na forma de bens físicos para uso pessoal ou revenda (mercadorias de luxo ou eletrônicos), serviços para uso pessoal ou revenda (serviço de entrega de alimentos) ou serviços e produtos que ajudam a cometer outras fraudes (serviços de hospedagem na Web, serviços de spam etc.).

Continue lendo para saber mais detalhes sobre os vetores de fraude mais comuns e ver nossas sugestões de uso do Radar para mitigá-los.

Testes

O teste de cartões ocorre quando agentes fraudulentos usam scripts ou processos manuais para testar se os números brutos do cartão roubado ainda estão ativos. Essa fase da fraude não envolve a obtenção de um serviço ou produto físico, trata-se apenas de verificar se o cartão está ativo. Essas cobranças normalmente são de autorizações ou transações de valores baixos. O teste ocorre normalmente em sucessão muito rápida. Os atributos que podem ser úteis são os recursos de agrupamento e velocidade, como:

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

Agentes fraudulentos costumam contornar isso criando e-mails falsos e usando endereços de e-mail diferentes. Os golpistas mais avançados mascaram o endereço IP ou até mesmo usam vários dispositivos para fornecer dados de dispositivo exclusivo. Nesse ponto, é importante conhecer o comportamento do cliente típico e legítimo. Recursos como domínio de e-mail e país do IP, entre outras categorias mais amplas, podem ajudar a identificar transações de alto risco. Muitos clientes fraudulentos usam domínios de e-mail populares de provedores de e-mails consagrados, como gmail.com. É comum ver domínios como gmail.comms ou gomail.co, que tentam mascarar a identidade de agentes fraudulentos. O país do cartão e do IP também pode ser usado para ajudar a segmentar clientes e garantir que as transações venham de áreas típicas da sua base de usuários. Se as transações não forem desses locais, pode ser interessante analisá-las ou bloqueá-las.

Uma última funcionalidade para contornar esse comportamento de teste é a implementação de CAPTCHA.

No Stripe Checkout, os desafios de CAPTCHA são apresentados automaticamente quando o machine learning detecta um ataque de teste de cartão. Para conter os testes de cartões, a Stripe usa uma série de controles automatizados e manuais, como limitadores de fluxo, alertas, análises contínuas e treinamento de modelos de teste de cartões para detectar ataques automaticamente. Esses modelos só apresentam desafios quando há um ataque de teste de cartão em andamento. O CAPTCHA quase nunca aparece para usuários legítimos, somente para bots. Isso reduziu em 80% os testes de cartões para empresas que usam o Stripe Checkout, com impacto quase nulo na conversão.

Você também pode criar regras personalizadas como "Bloqueie se recusado mais de três vezes em um determinado endereço IP" para reduzir os ataques de teste de cartões.

Extração de valor

Cartões de crédito roubados (novo comportamento)

Nesse vetor de fraude, o agente fraudulento usa o cartão roubado e validado em seu dispositivo pessoal ou no dispositivo que é usado para cometer fraudes.

Em geral, esse vetor é explorado de maneira abusiva por meio de ataques em massa programados ou em menor escala, com quadrilhas mais direcionadas. Independentemente disso, o uso de atributos de regras que verificam quão recente é uma conta na Stripe, como hours_since_email_first_seen_on_stripe, junto com risk_score e outros recursos, mantém esses novos titulares de cartão à distância. Além disso, restrições de velocidade em IP, e-mails e cartões podem proteger ainda mais os comerciantes contra ataques volumosos em que os agentes fraudulentos tentam monetizar credenciais roubadas o mais rápido possível.

Cartões de crédito roubados (mascaramento)

Nesse vetor de fraude, o agente fraudulento usa o cartão roubado e validado em seu dispositivo pessoal ou no dispositivo usado para cometer fraudes ou o agente fraudulento comprometeu uma conta de assinatura e obteve acesso aos dados do cartão de crédito armazenados na conta.

O agente fraudulento tentará ao máximo mascarar sua presença:

• Usando o mesmo nome de transações já concluídas

• Usando o mesmo endereço de faturamento de transações já concluídas

• Usando VPN para fazer parecer que se trata do titular do cartão. O agente pode configurar a VPN para a mesma cidade, às vezes até para o mesmo quarteirão

• Alterando uma informação secundária, como endereço de e-mail ou telefone

• Alterando o endereço de entrega usado em transações passadas, para um produto físico, resultando, possivelmente, em uma distância grande entre o endereço de faturamento e o endereço de entrega. Esse é um sinal fraco

O mascaramento descrito acima dificulta a identificação de quem de fato está realizando a transação, se é mesmo o titular do cartão ou se é um agente fraudulento que comprometeu a conta. Com frequência, isso tudo faz com que esse tipo de fraude demore mais para ser detectado, tanto pelo comerciante quanto pelo titular do cartão.

A estratégia aqui é a mesma: o agente fraudulento tenta extrair o máximo de valor possível das credenciais roubadas. As regras que usam recursos limitadores de velocidade, junto com riskscore, falhas em cvccheck ou falhas na verificação do código postal, podem ajudar na proteção contra esse comportamento.

Outras práticas recomendadas

Veja mais algumas práticas recomendadas para otimizar a criação de regras no Radar.

Importância de usar o Stripe.js

• Inclua stripe.js no caminho completo do pagamento para obter o máximo de sinalização de fraudes
  
• Para aproveitar o Radar ao máximo sem impactar o tempo de carregamento da página, carregue o stripe.js de modo assíncrono em páginas que não são de pagamento
  
• Mais simples de colocar ao lado das tags de script do Google Analytics
  
• O tamanho do pacote completo do stripe.js compactado é de 29,6 kb
  
  • Estado futuro: radar.js poderá ser incluído separadamente do stripe.js
    

Conclusão

As regras podem ser uma ferramenta extraordinariamente poderosa para personalizar a proteção contra fraudes. Ao implementar uma lógica exclusiva, fundamentada em algumas das práticas recomendadas descritas neste guia, é possível criar uma configuração de prevenção a fraudes no Radar específica para as necessidades da sua empresa.

Para saber mais sobre o Radar for Fraud Teams, clique aqui.

Se você já usa o Radar for Fraud Teams, confira a página de regras em seu Dashboard para começar a escrever regras.

Outras observações

Radar para plataformas

Sua plataforma usa Stripe Connect? Nesse caso, todas as regras que você criar se aplicam apenas a pagamentos criados na conta da plataforma (nos termos do Connect, cobranças de destino ou em nome
de). Os pagamentos criados diretamente na conta conectada estão sujeitos às regras dessa conta.

Radar para Terminal

As cobranças do Terminal não são avaliadas pelo Radar. Isso significa que, se você usar o Terminal, poderá criar regras com base na frequência do IP sem se preocupar em bloquear pagamentos presenciais.