# Regras de prevenção de fraudes Use regras de prevenção a fraudes para ajudar a proteger sua empresa O Stripe Radar oferece regras integradas para ajudar a detectar e proteger contra risco de fraude em todas as [formas de pagamento compatíveis](https://docs.stripe.com/radar/supported-payment-methods.md). Todas as transações são avaliadas usando as regras padrão do Radar. O Radar for Fraud Teams e o [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) permitem usar o [Dashboard](https://dashboard.stripe.com/test/radar/rules) para criar [regras personalizadas](https://docs.stripe.com/radar/supported-payment-methods.md#custom-risk-settings) com base na lógica da sua empresa. Por exemplo, é possível: - **Solicitar 3D Secure** (3DS) para todos os pagamentos em que ele é aceito e que forem feitos por um novo cliente - **Permitir** todos os pagamentos do endereço IP da sua central de atendimento - **Bloquear** pagamentos feitos de um local ou cartão emitido fora do seu país - **Revisar** todos os pagamentos superiores a US$ 1.000 que foram feitos com um cartão pré-pago - **Revisar e pausar automaticamente repasses** em contas com alta taxa de contestação (com o Radar for Platforms) > Empresas da UE podem ser afetadas pela [Regulamentação de geobloqueio](https://support.stripe.com/questions/eu-geo-blocking-regulation-changes) e suas proibições de bloqueio de pagamentos de clientes estabelecidos em estados membros da UE. ## Regras integradas As seguintes regras estão disponíveis por padrão, a menos que sejam marcadas como regras personalizadas, que estão disponíveis apenas se você usar o Radar for Fraud Teams ou o Radar for Platforms. > #### Bloqueie fraudes automaticamente > > Ou, você pode usar os [controles de risco](https://docs.stripe.com/radar/risk-settings.md) do Radar para bloquear fraudes automaticamente. Os controles de risco usam [alertas antecipados de fraude](https://docs.stripe.com/radar/risk-settings.md#early-fraud-warning) para avaliar e bloquear os pagamentos de maior risco. ### Verificações de risco baseadas em IA Todas as ofertas do Radar fornecem um conjunto de regras padrão baseadas nas avaliações dos nossos modelos de IA. | Regra do Radar | Descrição | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if :risk_level: = 'highest'` (Deprecated) | A regra bloqueia e não processa pagamentos com um alto risco de fraude. Essa regra é habilitada por padrão para todos os usuários do Radar. | | `if :risk_level: = 'elevated'` | O comportamento padrão do Radar for Fraud Teams e do Radar for Platforms é colocar em revisão os pagamentos que suspeitamos ter risco elevado de fraude. | O Radar for Platforms possui outros modelos de IA no nível da conta integrados por meio de duas regras padrão: `if :account_risk_level: = 'highest'` `if :account_risk_level: = 'elevated'` Calculamos o risco no nível da conta usando informações de KYC, transações, fatores de risco geográficos e padrões de comportamento. ### Verificações de cartão tradicionais Um pagamento ainda pode ser aprovado mesmo quando a verificação de *CVC* (The card verification code (CVC) or card verification value (CVV) is a three- or four-digit number printed directly on a card used to verify the entered card number) ou de endereço (*AVS* (The address verification system (AVS) is used to pass billing address information to issuers to verify the data if available)) falha, pois emissores avaliam diversos fatores de risco ao decidir autorizar um pagamento. Um emissor de cartão ainda pode considerar legítimo um pagamento que falha na verificação de CVC ou do código postal e, portanto, aprová-lo. Você pode habilitar as regras nativas do Radar para bloquear determinados pagamentos aprovados pelo emissor do cartão. Quando ativadas, essas regras também afetam a vinculação de um cartão a um cliente e a criação de um cliente, se você criar o cartão e o cliente juntos. #### Regras de CVC e AVS A partir de 17 de dezembro de 2024, a Dashboard mostra essas regras a novos clientes e clientes existentes que não usaram as regras antigas de CVC ou AVS. | Regra do Radar | Descrição | | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `se a verificação de CVC falhar com base na pontuação de risco` | Habilite essa regra para bloquear pagamentos que falham na verificação de CVC do emissor do cartão, a menos que a Stripe os avaliem como de baixo risco. Esta regra não bloqueia pagamentos em que o cliente não informa o número da CVC porque usa uma *carteira* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) ou porque o emissor do cartão não aceita a verificação, por exemplo. | | `se a verificação de código postal falhar com base na pontuação de risco` | Habilite essa regra para bloquear pagamentos reprovados na verificação de código postal do emissor do cartão, a menos que a Stripe os avaliem como de baixo risco. Essa regra não bloqueia pagamentos em que o cliente não informa o código postal ou o emissor do cartão não aceita a verificação. | #### Regras de CVC e AVS antigas Em vigor a partir de 17 de dezembro de 2024, o Dashboard mostra essas regras a clientes existentes que ativaram pelo menos uma das regras. | Regra do Radar | Descrição | | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `if CVC verification fails` | Habilite essa regra para bloquear pagamentos reprovados na verificação de CVC do emissor do cartão. Esta regra não bloqueia pagamentos em que o cliente não informa o número da CVC porque usa uma *carteira* (A digital wallet is a contactless payment method that stores payment options, such as credit and debit cards, allowing customers to use a smart device to make a purchase) ou porque o emissor do cartão não aceita a verificação, por exemplo. | | `if postal code verification fails` | Habilite essa regra para bloquear pagamentos quando houver falha na verificação de código postal do emissor do cartão. Essa regra não bloqueia pagamentos em que o cliente não informa o código postal ou o emissor do cartão não aceita a verificação. | ### Regras integradas para solicitar 3D Secure O *3D Secure (3DS)* (3D Secure (3DS) provides an additional layer of authentication for credit card transactions that protects businesses from liability for fraudulent card payments) exige que os clientes concluam uma etapa de autenticação adicional antes de concluírem o fluxo de compra. Se o 3DS autenticar um pagamento, a [responsabilidade](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments) por quaisquer contestações de fraude relacionadas a esse pagamento normalmente passa do vendedor para o emissor. Isso significa que, na maioria dos casos, o vendedor não é responsável pelos custos de fraude em pagamentos autenticados com 3DS. A Stripe gerencia automaticamente códigos de recusa simples que indicam a exigência do 3DS pelos emissores. Também acionamos o 3DS quando necessário, cumprindo regulamentações como a [Autenticação Forte de Cliente](https://stripe.com/guides/strong-customer-authentication) (SCA) instruída pelo PSD2. A desativação do Radar não impede que o 3D Secure seja acionado nos casos em que é necessário. A Stripe oferece três regras integradas legadas para solicitar o 3DS ao usar o Radar com [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) ou [SetupIntents](https://docs.stripe.com/payments/save-and-reuse.md): | Regra do Radar | Descrição | | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `if 3D Secure is recommended for card` (Descontinuado) | Ative esta regra para solicitar a autenticação 3DS ao cliente com base no risco. | | `if 3D Secure is supported for card` (Descontinuado) | Ative esta regra para solicitar a autenticação 3DS ao cliente, desde que o cartão ofereça suporte. | | `se 3D Secure for necessário para o cartão` (Deprecated) | Ative esta regra para solicitar autenticação 3DS ao cliente se o cartão historicamente [exigiu 3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#three-ds-cards). Independentemente dessas regras, o Stripe aciona automaticamente o 3DS: - Se um código de recusa simples indicar, o emissor exige 3DS. - Em conformidade com regulamentações, como a exigência da instrução de [autenticação forte de cliente](https://stripe.com/guides/strong-customer-authentication) da PSD2. | Como o 3DS exige que seu cliente passe por uma camada adicional de autenticação, o uso indiscriminado do 3DS pode reduzir as taxas de conversão. Solicitar o 3DS não significa necessariamente que o emissor realmente executa o 3DS. Saiba mais sobre [possíveis resultados](https://docs.stripe.com/payments/3d-secure.md). ### Regras personalizadas para solicitar o 3D Secure e realizar ações com base em resultados específicos Se você tiver o [Radar for Fraud Teams](https://stripe.com/radar/fraud-teams) ou o [Radar for Platforms](https://docs.stripe.com/radar/radar-for-platforms.md) e tentar a autenticação do 3DS, poderá avaliar o resultado com regras de permissão, bloqueio ou revisão. Veja abaixo os atributos mais importantes para regras personalizadas do Radar. | Atributo | Descrição | | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `is_3d_secure` | Este atributo é verdadeiro se o cartão for compatível, o 3DS tiver sido tentado pelo emissor e o cliente não tiver falhado na autenticação. Geralmente recomendamos usá-lo em regras de bloqueio. | | `is_3d_secure_authenticated` | Este atributo é verdadeiro se o 3DS tiver sido tentado pelo emissor e o cliente tiver concluído com sucesso a autenticação completa. Usar este atributo em uma regra de bloqueio exclui transações legítimas que podem ter uma isenção de SCA ou não se enquadram claramente em falha ou sucesso de autenticação, como erros de processamento. | | `has_liability_shift` | Este atributo é verdadeiro se a Stripe esperar que a *transferência de responsabilidade* (With some 3D Secure transactions, the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer) cubra o pagamento. Isso nem sempre é a mesma coisa que o [3DS](https://docs.stripe.com/payments/3d-secure/authentication-flow.md#disputed-payments), como no caso do Apple Pay em certas regiões. | Para regras personalizadas, recomendamos manter alinhadas as regras `Solicitar 3DS` e `Block` de acordo com seu [apetite de risco](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data). No entanto, não bloqueie pagamentos em que o 3DS não é compatível, como em algumas carteiras digitais. Veja abaixo alguns exemplos que mostram como alcançar isso em diferentes casos de uso. #### Solicitar o 3D Secure com base no nível de risco do Radar Você quer usar o Radar para solicitar 3DS em todos os pagamentos, com base no nível de risco e acima de um determinado valor. | Regra do Radar | Descrição | | -------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | `Solicitar 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Esta regra verifica o nível de risco do Radar antes de solicitar 3DS em todos os pagamentos com risco elevado ou alto acima de um determinado valor. | Nesse caso, sem uma regra de bloqueio, cartões ou carteiras digitais que não oferecem suporte ao 3DS não são bloqueados. Tentativas de 3DS que falharem na autenticação não continuam para a autorização da cobrança. #### Sempre exija o 3D Secure com base no nível de risco do Radar Você quer usar o Radar para solicitar 3DS em todos os pagamentos com nível de risco elevado ou alto e acima de um determinado valor. Você não quer aceitar cartões que não oferecem suporte ao 3DS. | Regra do Radar | Descrição | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Solicitar 3D Secure if :risk_level: != 'normal' and :amount_in_usd: > 25` | Esta regra verifica o nível de risco do Radar antes de solicitar 3DS em todas as cobranças com risco elevado ou alto acima de um determinado valor. | | `Bloquear if not :is_3d_secure: and :risk_level: != 'normal' and :amount_in_usd: > 25 and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra bloqueia pagamentos de risco elevado ou alto acima de um determinado valor que não tenham fluxo 3DS. Ela aceita pagamentos legítimos que podem ter uma isenção de SCA ou não apresentem falha ou sucesso claro de autenticação, como `attempt_acknowledged`. Aceita pagamentos fora da sessão, como cobranças recorrentes de assinatura, e carteiras digitais, como Apple Pay ou Google Pay. | #### Aceitar apenas pagamentos totalmente autenticados com 3D Secure se o 3D Secure for compatível Você depende do Stripe para ativar o 3DS quando necessário em casos como [Autenticação forte de cliente](https://stripe.com/guides/strong-customer-authentication) (SCA), mas não quer aceitar [casos extremos](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), como erros de processamento. | Regra do Radar | Descrição | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Block if :is_3d_secure: and not :is_3d_secure_authenticated:` | Esta regra bloqueia pagamentos em que o cartão está inscrito no 3DS e o 3DS foi tentado, mas a autenticação do usuário não foi bem-sucedida. Cartões incompatíveis com 3DS, isenções da SCA, pagamentos fora da sessão (como cobranças de assinatura recorrentes) e carteiras (como Apple Pay ou Google Pay) são aceitos. | #### Solicitar o 3D Secure com base em metadados Recomendamos usar o Radar para solicitar o 3DS em todos os pagamentos com um atributo de metadados personalizado. | Regra do Radar | Descrição | | ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Solicitar 3D Secure if ::foo:: = 'bar'` | Esta regra verifica uma condição de metadados e solicita o 3DS. Para verificar metadados do Cliente, substitua `::foo:: = 'bar'` por um valor como `::customer:trusted:: = 'false'`. | Nesse caso, sem uma regra de bloqueio, nós não bloqueamos cartões ou carteiras digitais que não oferecem suporte ao 3DS. Tentativas de 3DS que falharem na autenticação não continuam para a autorização da cobrança. #### Sempre exija o 3D Secure com base em metadados Recomendamos usar o Radar para solicitar o 3DS em todos os pagamentos com um atributo de metadados personalizado e bloquear cartões que não o aceitem. | Regra do Radar | Descrição | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Solicitar 3D Secure if ::foo:: = 'bar'` | Esta regra verifica uma condição de metadados e solicita o 3DS. Para verificar metadados do Cliente, substitua `::foo:: = 'bar'` por um valor como `::customer:trusted:: = 'false'`. | | `Bloquear if ::foo:: = 'bar' and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra bloqueia pagamentos que não têm um fluxo de 3DS para cobranças com um atributo de metadados personalizado. Esta regra aceita transações legítimas que possam ter uma isenção de SCA ou não se enquadrem em uma autorização com falha ou êxito, como `attempt_acknowledged`. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. | #### Solicite o 3D Secure para todos os novos cartões e faça uma análise se o 3D Secure não era aceito Recomendamos usar o Radar para solicitar o 3DS em todos os cartões novos e analisar manualmente os pagamentos de cartões que não aceitam o 3DS. | Regra do Radar | Descrição | | --------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if is_missing(:seconds_since_card_first_seen:)` | Esta regra solicita o 3DS em todos os cartões que não foram usados em sua conta. Para reduzir o atrito dos usuários, você pode adicionar uma condição para solicitar o 3DS somente se `:risk_level: != ``normal’``. | | `Request 3D Secure if :is_new_card_on_customer:` | Como alternativa à regra acima, essa regra solicita 3DS em todos os cartões usados pela primeira vez em uma [conta](https://docs.stripe.com/api/v2/core/accounts/object.md#v2_account_object-configuration-customer) ou [cliente](https://docs.stripe.com/api/customers.md) configurado pelo cliente. Para reduzir o atrito para o usuário, você pode adicionar uma condição para solicitar 3DS apenas se :risk_level: != `'normal'```. | | `Revisar if not :is_3d_secure and not:is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra marca pagamentos em que o 3DS é esperado, mas não é compatível, para análise manual. Ela ignora pagamentos off-session, como cobranças recorrentes de assinaturas, e carteiras digitais, como Apple Pay ou Google Pay. Pagamentos marcados para análise continuam para autorização e podem fornecer fatores de risco adicionais, como verificações de CVC pelo emissor. | Nesse caso, sem uma regra de bloqueio, nós não bloqueamos cartões ou carteiras digitais que não oferecem suporte ao 3DS. Tentativas de 3DS que falharem na autenticação não continuam para a autorização da cobrança. #### Sempre exija o 3D Secure para determinados países de emissores Recomendamos usar o Radar para solicitar o 3DS em todos os pagamentos de emissores de cartão originários de países em uma [lista personalizada](https://docs.stripe.com/radar/lists.md) e bloquear cartões que não o aceitem. | Regra do Radar | Descrição | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Request 3D Secure if :card_country: in @enforce_3ds_list` | Esta regra verifica uma condição baseada no país de origem do emissor do cartão e compara com uma [lista personalizada](https://docs.stripe.com/radar/lists.md). Se houver correspondência, solicitamos o 3DS. | | `Bloquear if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != 'apple_pay' and not(:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra bloqueia pagamentos que não têm fluxo 3DS e que se originam de países na lista personalizada. Ela aceita pagamentos legítimos que podem ter uma isenção de autenticação forte de cliente (SCA) ou não apresentem falha clara ou autenticação bem-sucedida, como `attempt_acknowledged`. Ela aceita pagamentos fora da sessão, como cobranças recorrentes de assinatura, e carteiras digitais, como Apple Pay ou Google Pay. | #### Sempre exija o 3D Secure com base no nível de risco do Radar e analise os casos extremos Você quer usar o Radar para solicitar 3DS em todos os pagamentos com base no nível de risco e bloquear cartões que não oferecem suporte ao 3DS, mas revisar manualmente casos extremos. | Regra do Radar | Descrição | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Solicitar 3D Secure if :risk_level: != 'normal'` | Esta regra verifica o nível de risco do Radar antes de solicitar 3DS em todos os pagamentos de risco elevado ou alto acima de um determinado valor. | | `Bloquear if not :is_3d_secure: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra bloqueia pagamentos de risco elevado ou alto acima de um determinado valor que não tenham fluxo 3DS. Ela aceita pagamentos legítimos que podem ter uma isenção de autenticação forte de cliente (SCA). Ela aceita pagamentos fora da sessão, como cobranças recorrentes de assinatura, e carteiras digitais, como Apple Pay ou Google Pay. | | `Revisar if not :is_3d_secure_authenticated: and :risk_level: != 'normal' and not :is_off_session: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)` | Esta regra marca para revisão manual pagamentos que usaram 3DS, mas não resultaram em autenticação completa. Ela revisa [casos extremos](https://docs.stripe.com/api/charges/object.md#charge_object-payment_method_details-card-three_d_secure-result), como `attempt_acknowledged`, e também marca pagamentos legítimos apesar de isenções de autenticação forte de cliente (SCA). Como regras de revisão são avaliadas após regras de bloqueio, bloqueamos cartões que não oferecem suporte ao 3DS. | ## Criar regras Somente o titular da conta, os administradores e os desenvolvedores podem criar regras. Se você precisar que [membros da equipe](https://support.stripe.com/questions/can-i-invite-other-team-members-or-my-developer-to-use-my-stripe-account) criem regras, consulte as [configurações de equipe](https://dashboard.stripe.com/settings/team) para ver se eles têm acesso administrativo. As regras padrão da Stripe podem bloquear um número significativo de pagamentos fraudulentos. Empresas que precisam de mais controle sobre quais pagamentos desejam revisar, permitir ou bloquear podem criar regras personalizadas com o Radar for Fraud Teams. Plataformas podem criar regras personalizadas com o Radar for Platforms para calibrar o risco de pagamentos para sua plataforma e contas conectadas e aplicar regras específicas por conta. Considere o seguinte ao decidir se deseja habilitar regras personalizadas: - Se você considerar certos recursos ou comportamentos de usuários como mais arriscados (por exemplo, uso de e-mail descartável). - Se quiser implementar regras com base na forma de pagamento (por exemplo, bloquear automaticamente pagamentos de débito automático SEPA que excedam determinada pontuação de risco). - Se quiser implementar regras com base em valores de pagamento ou nível de risco percebido (por exemplo, revisar automaticamente pagamentos acima de US$ 500, permitir automaticamente pagamentos abaixo de US$ 5)? - Se seus pagamentos contestados e reembolsados apresentarem padrões comuns (por exemplo, valores semelhantes, tipos de cartão ou países)? - Se tiver regras existentes que deseja migrar para a Stripe. O modelo de IA da Stripe pode já cobrir muitas dessas regras, e você pode verificar como nosso sistema funciona para sua empresa antes de personalizá-lo. - Se quiser acionar revisões automaticamente e, opcionalmente, pausar repasses em contas. Isso se aplica apenas a plataformas. ### Criar regras eficazes Embora regras possam ajudar a automatizar fluxos de trabalho existentes, elas também podem prejudicar sua empresa se usadas incorretamente. Por exemplo, uma regra pode permitir automaticamente um grande volume de pagamentos de risco elevado ou alto, ou bloquear um grande número de pagamentos legítimos, se não estiver configurada corretamente. Lembre-se do seguinte ao configurar regras: - Por padrão, as regras se aplicam a todas as [formas de pagamento compatíveis](https://docs.stripe.com/radar/supported-payment-methods.md), a menos que uma forma de pagamento específica seja definida no predicado da regra usando o atributo `payment_method_type`. - As regras se aplicam apenas a pagamentos futuros e não se aplicam aos que já foram processados. - As regras Solicitar 3DS aplicam-se somente ao usar [Stripe Checkout](https://docs.stripe.com/payments/checkout.md), [Payment Intents](https://docs.stripe.com/payments/accept-a-payment.md) ou [Setup Intents](https://docs.stripe.com/payments/save-and-reuse.md), e são avaliadas antes das regras de análise, bloqueio e permissão. - Antes de implementar qualquer regra de bloqueio para bloquear todos os pagamentos ou pausar repasses de contas que atendam aos critérios, considere se é melhor revisar primeiro os pagamentos ou contas. - Implemente regras de permissão com moderação, porque elas substituem as regras padrão da Stripe, além de quaisquer outras regras personalizadas que correspondam aos mesmos critérios. - Você pode criar um máximo de 200 regras de transação e 100 regras de conta. ## Construir regras de transação Você pode adicionar e gerenciar regras na [página de Regras do Radar](https://dashboard.stripe.com/test/radar/rules) no Dashboard. #### Para adicionar uma regra de transação 1. Clique em **+ Adicionar regra**. 1. Selecione o tipo de regra. 1. No editor de regras, crie uma regra usando a sintaxe `{action} se {attribute} {operator} {value}`, em que: - `{action}`: é como o Radar responde quando os critérios da regra são atendidos. Este valor é preenchido automaticamente de acordo com o tipo de regra selecionado. - `{attribute}`: é o elemento do pagamento a ser avaliado, como valor ou tipo de cartão. Comece digitando com `:` para abrir uma lista de atributos válidos. Você também pode avaliar seus metadados personalizados colocando-os entre dois pares de dois-pontos, por exemplo, `::product_sku::`. - `{operator}`: é como comparar o atributo ao valor, como `=`, `>`, `!=` e assim por diante. - `{value}`: é o valor do atributo a ser avaliado. 1. Clique em **Testar regra**. 1. Se necessário, corrija os erros de validação detectados. 1. Na página **Revisar nova regra**, revise como essa regra se comporta em relação aos seus pagamentos recentes para confirmar se deseja ativá-la. Se a regra puder afetar pagamentos de mais de uma forma de pagamento, use o filtro para visualizar o desempenho da regra por forma de pagamento (por exemplo, ACH ou cartões. 1. Clique em **Adicionar regra** para aplicar essa regra a todas as transações futuras. ### Usar o Radar Assistant O editor de regras da Stripe possui um assistente LLM integrado que desenvolve uma regra de transação do Radar a partir de um comando em linguagem natural. Saiba mais sobre [serviços de IA da Stripe](https://support.stripe.com/questions/use-of-artificial-intelligence-\(ai\)-in-stripe-services). > #### Consentimento para uso de dados de treinamento > > Ao usar o Radar Assistant, você concorda que a Stripe pode registrar e usar suas mensagens para treinar e melhorar as capacidades do Radar Assistant. Se não quiser que suas mensagens sejam usadas para esse fim, escreva regras manualmente. #### Para usar o Radar Assistant 1. Na [página de Regras do Radar](https://dashboard.stripe.com/test/radar/rules), clique em **+ Adicionar regra**. 1. Selecione o tipo de regra. 1. No editor de regras, clique em **Radar Assistant**. 1. No campo da mensagem, insira sua solicitação de regra. Você pode pedir para: - *Revise os pagamentos em que o país do cartão e do IP são diferentes.* - *Bloqueie pagamentos com cartão Discover de mais de US$ 1.000.* - *Permita pagamentos de endereços de e-mail stripe.com.* 1. Quando o Assistant retornar sua sugestão, você pode inserir um comando adicional para ajustar a regra ou clicar em **Testar regra** para ver como ela se comporta em relação ao seu histórico recente de transações. 1. Quando estiver satisfeito com a regra, clique em **Adicionar regra** para habilitá-la em todas as transações futuras. > #### Envie seus comentários > > Ajude-nos a continuar melhorando o Radar Assistant. Clique em **Enviar comentários** e conte-nos sobre o desempenho do Assistant e o que podemos fazer para melhorar. Aceitamos todas as opiniões, seja sobre a precisão da sugestão, a IU ou qualquer outro aspecto da sua interação. ### Regras de revisão A Stripe ainda processa pagamentos normalmente quando eles correspondem aos critérios de uma regra de revisão. Adicionamos esses pagamentos à sua [fila de revisão](https://dashboard.stripe.com/test/radar) para que sua equipe possa analisá-los com mais atenção. Configurar uma regra muito ampla pode resultar em muitos pagamentos sendo colocados em revisão, o que pode atrasar seus clientes e sobrecarregar sua equipe de revisão. A interface de teste de regras da Stripe executa uma simulação nos últimos seis meses de cobranças para determinar quantos pagamentos legítimos, fraudulentos e bloqueados teriam sido afetados pela regra, caso ela estivesse implementada. Ao testar uma regra e examinar os últimos seis meses, verifique que: - **O volume geral de pagamentos é baixo**. Revisar esses pagamentos não deve sobrecarregar sua equipe. - **Revisores humanos agregam valor**. Um revisor humano geralmente consegue identificar um pagamento de risco elevado ou alto com mais confiança do que o sistema automatizado. - **A regra resulta em uma combinação de pagamentos bem-sucedidos e reembolsados ou contestados**. Isso significa que uma inspeção adicional nesses tipos de pagamentos pode ajudar a separar pagamentos legítimos de pagamentos fraudulentos. A seguir há um exemplo de como melhorar uma regra de análise criada por uma empresa que deseja analisar cartões de crédito pré-pagos. | Regra original | Regra melhorada | | ---------------------------------------------------------- | ------------------------------------------------------------------ | | `if :card_funding: = 'prepaid'` | `if :is_disposable_email: and :card_funding: = 'prepaid'` | | Essa regra é muito ampla e resulta em excesso de revisões. | Essa regra é mais focada e resulta em um número menor de revisões. | ### Regras de bloqueio Você pode usar regras de bloqueio para bloquear pagamentos que você tem certeza de que são fraudulentos ou com base em restrições do seu negócio (como bloquear pagamentos de cartões pré-pagos). Se não tiver certeza de como aplicar regras de bloqueio, recomendamos usar uma regra de revisão para colocar pagamentos em revisão. Após revisar esses pagamentos em busca de possíveis falsos positivos, você pode confirmar se deseja criar uma regra de bloqueio. As regras de bloqueio afetam somente pagamentos fraudulentos e bem-sucedidos, porque pagamentos já bloqueados não são afetados. Ao testar uma regra, não se esqueça de: - **Reduzir ao máximo os falsos positivos**. Durante os testes, a Stripe identifica a quantidade de pagamentos bem-sucedidos e malsucedidos que teriam sido correspondidos pela regra. Uma boa regra de bloqueio resulta em muito mais bloqueios fraudes do que de pagamentos legítimos. - **Minimizar regras desnecessárias**. Se uma regra parece funcionar bem, mas já está coberta por outra existente, a nova regra pode ser desnecessária. Da mesma forma, se os resultados durante os testes forem mistos, considere configurar uma regra de revisão para reunir mais informações sobre esses tipos de pagamentos. A seguir está um exemplo de como melhorar uma regra de bloqueio criada por uma empresa que enfrenta um nível elevado de fraude em pagamentos fora dos EUA. | Regra original | Regra melhorada | | ---------------------------------------------------------------------------- | ------------------------------------------------------------------ | | `if :card_country: != 'US'` | `if :card_country: != 'US' and :risk_level: = 'elevated'` | | Esta regra é ampla demais e bloqueia um número alto de pagamentos legítimos. | Essa regra é mais focada e resulta em um número menor de revisões. | ### Regras de permissão Se quiser a capacidade de criar regras de permissão, [entre em contato conosco](https://support.stripe.com/contact). As regras de permissão se sobrepõem às outras regras, por isso devem ser usadas com cautela. Muitas empresas talvez não precisem implementar regras de permissão. Se você teme que uma regra de permissão possa deixar passar um pequeno número de pagamentos fraudulentos, considere fazer alguns ajustes para restringir ainda mais essas regras antes de implementá-las. As regras de permissão se aplicam a novos pagamentos assim que você cria a regra. Isso inclui pagamentos que sejam similares aos pagamentos já bloqueados. Enquanto testa uma regra, certifique-se de: - **Examinar o número de pagamentos anteriormente bloqueados que teriam sido permitidos**. As regras de permissão substituem todas as outras regras e a avaliação de risco da Stripe. Ao testar uma nova regra de permissão, todos os pagamentos exibidos teriam sido permitidos se essa regra estivesse ativa. Isso pode incluir pagamentos que foram bloqueados ou contestados, afetando suas futuras taxas de contestação. - **Continuar bloqueando todos os pagamentos de alto risco**. Bloqueie pagamentos de alto risco adicionando o seguinte a qualquer regra de permissão: `and :risk_level: != 'highest'` - **Avalie um histórico de transações legítimas na sua empresa**. Você pode analisar as conexões entre seus clientes para permitir um volume maior de transações com base em um histórico de compras legítimas. Isso ajuda você a bloquear menos pagamentos de clientes que têm um histórico comprovado na sua empresa. Para fazer isso, consulte a [lista de atributos](https://docs.stripe.com/radar/rules/reference.md#supported-attributes) e procure atributos que incluam a palavra “customer”. A seguir está um exemplo de como melhorar uma regra de permissão para uma empresa que geralmente (mas não sempre) recebe pagamentos legítimos de clientes no Reino Unido: | Regra original | Regra melhorada | | ------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | `if :ip_country: = 'GB'` | `if :ip_country: = 'GB' and :risk_level: != 'highest'` | | Esta regra é ampla demais e permite alguns pagamentos fraudulentos. | Esta regra é mais focada e permite um número menor de pagamentos fraudulentos. | ## Manter suas regras À medida que sua empresa cresce, garanta que suas regras continuem refletindo os tipos de clientes com os quais você deseja fazer negócios. A seguir estão algumas práticas recomendadas para manter as regras atualizadas conforme a realidade da sua empresa. ### Monitorar regularmente as regras para garantir que continuam eficazes #### Métricas das regras Os padrões de fraude mudam constantemente, por isso, fornecemos [métricas](https://dashboard.stripe.com/settings/radar/rules) para mostrar o desempenho dessas regras. Essas métricas variam dependendo do tipo de regra, pois os tipos de regra realizam ações diferentes. ![](https://b.stripecdn.com/docs-statics-srv/assets/rule-performance.8d495f28c352641ff7b710df3c3df2ed.png) Você pode notar uma diferença entre o número de pagamentos que corresponderam às regras de revisão e o número de pagamentos enviados à sua fila de revisão no mesmo período. Como apenas pagamentos *bem-sucedidos* são enviados para revisão, pagamentos que correspondem aos critérios de uma regra de revisão, mas são recusados pelo emissor, por exemplo, não são enviados para sua fila de revisão. Use o **gráfico de desempenho das regras** para entender o comportamento das regras do Radar. Procure picos ou quedas inesperadas no número de pagamentos que correspondem às suas regras, como regras de permissão permitindo pagamentos demais ou regras de bloqueio bloqueando pagamentos demais. Esses picos podem indicar mudanças nos tipos de pagamentos que sua empresa recebe ou a necessidade de atualizar as regras. **Linhas com códigos de cores** acompanham o número de pagamentos que correspondem a regras de [3DS](https://docs.stripe.com/issuing/3d-secure.md), regras de permissão, regras de bloqueio e regras de revisão. Regras atualizadas são exibidas como **símbolos triangulares** nas linhas do gráfico e ajudam a comparar o impacto de uma mudança antes e depois de sua aplicação. Clique no menu de navegação (⋯) para ver comandos adicionais para qualquer regra, incluindo **Desativar**, **Ativar**, **Editar** ou **Excluir**. Você também pode usar nossos produtos de relatórios, Sigma e Data Pipelines, para [consultar dados de contestações e fraude](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md), incluindo decisões de regras e atributos de cada pagamento individualmente. #### Avalie a eficácia das regras Você pode encontrar informações sobre a eficácia das suas regras e ver quantos pagamentos cada regra afetou. Também é possível visualizar e baixar uma lista filtrada de todos os pagamentos aos quais uma regra foi aplicada. Revise as perguntas de exemplo na tabela a seguir para ajudar a decidir se precisa alterar alguma regra ou removê-la completamente. | Tipo de regra | Avaliar | Ações a serem consideradas | | -------------- | ---------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Geral | Se esta regra não corresponder mais a nenhum pagamento. | Remova a regra. | | | Se a regra tem um comportamento anômalo, como permitir mais pagamentos do que em períodos anteriores. | Revisar manualmente os pagamentos que correspondem a essa regra para determinar se esse é o comportamento desejado. | | 3DS | Se a taxa de conclusão de 3DS for alta, mas o número de contestações ou alertas antecipados de fraude for baixo. | Remova a regra, pois você pode estar causando fricção desnecessária para seus usuários. | | | Se houver muitas fraudes em transações que passam pelo 3DS. | Considere modificar sua regra de 3DS para uma regra de bloqueio, para impedir que esses usuários passem por fluxos sem fricção (controlados pelos emissores) ou cometam fraude de primeira parte. | | | Se a taxa de conversão para 3DS for baixa. | Esta pode ser uma regra eficaz porque pode estar bloqueando principalmente fraudadores. Considere investigar manualmente os pagamentos correspondentes para garantir que seus bons usuários não estejam abandonando por causa da fricção adicional. | | Permitir | Se o número de contestações, alertas antecipados de fraude, reembolsos ou pagamentos falhos for alto. | Remova a regra que permite a aprovação de pagamentos incorretos. | | Bloquear | Se o número de bloqueios estiver diminuindo, mas sua fraude permanecer estável ou aumentar. | Modifique sua regra porque ela pode não ser mais eficaz. | | | Se o número de bloqueios estiver aumentando, mas as fraudes continuarem estáveis ou aumentarem. | Modifique sua regra, pois ela pode estar bloqueando bons usuários. | | | Se o número de bloqueios estiver aumentando e sua fraude estiver diminuindo. | Esta pode ser uma regra eficaz. Considere revisar manualmente algumas transações para garantir que você não esteja bloqueando bons usuários em demasia. | | Análise manual | Se a porcentagem de pagamentos analisados é baixa. | Torne a regra mais restritiva, pois ela pode estar ampla demais. | | | Se o número de pagamentos bem-sucedidos ou aprovados é alto. | Remova completamente a regra de revisão manual ou escreva uma regra de permissão para direcionar esses pagamentos. | | | Se o número de reembolsos ou contestações e alertas antecipados de fraude for alto. | Converta em uma regra de bloqueio. | #### Regras de solicitação de 3DS Para regras de solicitação de 3DS, exibimos **3DS Solicitado**, que é o número de vezes que uma regra acionou uma solicitação de 3DS. Você pode clicar em uma regra de 3DS para ver as seguintes métricas. ![](https://b.stripecdn.com/docs-statics-srv/assets/request-credentials-rule-details.c22b65bc432aafec9e5bcb6079c53528.png) **Regras de permissão** Se você usa o Radar for Fraud Teams, pode visualizar as seguintes regras de permissão: - **Pagamentos permitidos**: o número total de pagamentos permitidos pelas suas regras. - **Volume de pagamentos permitidos**: o valor total, na sua moeda local, associado aos pagamentos permitidos pelas suas regras. - **Pontuação de risco**: os [resultados de risco](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) atribuídos por nossos modelos de IA ao conjunto de pagamentos permitidos pelas suas regras. - **Contestações de sobreposições**: o número total de pagamentos permitidos que foram contestados. - **Volume de contestações com sobreposições**: o valor total, na sua moeda local, associado às contestações de pagamentos permitidos. > Se as métricas de contestações forem altas, considere escrever regras de permissão mais específicas para evitar permitir pagamentos que acabarão contestados. Selecione uma regra de permissão para ver as seguintes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/allow-rule-details.e8da078613fdbca5592d2f9330c0f6d4.png) **Regras de bloqueio** Você pode visualizar as seguintes regras de bloqueio: - **Pagamentos bloqueados**: o número total de pagamentos bloqueados pelas suas regras. - **Volume de pagamentos bloqueados**: o valor total, na sua moeda local, associado aos pagamentos bloqueados pelas suas regras. e você usa o Radar for Fraud Teams, também pode visualizar: - **Pontuação de risco**: os [resultados de risco](https://docs.stripe.com/radar/risk-evaluation.md#risk-outcomes) atribuídos por nossos modelos de IA ao conjunto de pagamentos permitidos pelas suas regras. - **Taxa estimada de falsos positivos**: a porcentagem estimada de pagamentos não fraudulentos que foram bloqueados, tanto para o conjunto de regras de bloqueio quanto para regras individuais. Essas estimativas são feitas usando as taxas estimadas de falsos positivos das pontuações de risco de IA correspondentes, calculadas com experimentos na rede da Stripe. - **Pagamentos fraudulentos evitados (estimado)**: o número estimado de pagamentos fraudulentos que suas regras de bloqueio evitaram. A Stripe usa pontuações de risco de IA, calculadas analisando milhões de transações na rede da Stripe, para prever pagamentos com alta probabilidade de serem contestados ou recusados por fraude e estimar quais desses pagamentos foram bloqueados com sucesso pelas suas regras. > Se as métricas de falsos positivos forem altas, considere escrever regras de bloqueio mais específicas ou revisar quais pagamentos estão sendo cobertos pela regra, para evitar bloquear pagamentos não fraudulentos. Selecione uma regra de bloqueio para ver as seguintes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/block-rule-details.5df9a2e8652f228cf61b525a32ef56da.png) **Regras de análise** Se você usa o Radar for Fraud Teams, pode visualizar as seguintes regras de revisão: - **Pagamentos enviados para revisão**: o número total de pagamentos enviados para revisão manual pelas suas regras. - **Volume de análises aprovadas**: o valor total, na sua moeda local, associado às revisões de pagamentos aprovadas. - **Taxa de reembolsos**: a porcentagem de revisões que foram reembolsadas. - **Contestações de revisões aprovadas**: o número total de pagamentos aprovados na revisão, mas que foram posteriormente contestados. - **Volume de contestações de revisões aprovadas**: o valor total, na sua moeda local, associado às contestações de revisões de pagamentos aprovadas. Selecione uma regra de revisão para ver as seguintes métricas: ![](https://b.stripecdn.com/docs-statics-srv/assets/review-rule-details.10851302ef65dee05ffce64f7989528f.png) #### Exibir histórico de regras Você pode ver um histórico de alterações feitas nas regras do Radar. Essa trilha de auditoria ajuda você a entender quando uma regra foi criada, editada, habilitada ou desabilitada e por qual usuário da sua equipe. Para ver a atividade de uma regra específica, acesse a guia [Regras](https://dashboard.stripe.com/radar/rules) na página do Radar e clique no nome da regra. O log **Atividade de regra** mostra um resumo de todas as modificações. Clique no evento específico para ver mais detalhes, como o predicado de regra completo antes e depois da atualização. Você só pode ver as alterações de regras dos últimos 180 dias. A revisão regular dessa atividade pode ajudar você a correlacionar as modificações de regras com seu impacto em sua empresa. ### Monitore regularmente sua fila de revisão manual Se sua fila de revisão estiver grande demais para ser administrada, verifique se você tem as regras corretas configuradas. Se a maioria das revisões resultar em reembolso por fraude, considere mais regras para bloquear pagamentos. Se a maioria dos pagamentos for aprovada, considere tornar suas regras de revisão mais focadas. ### Analise seus pagamentos contestados e reembolsados As [contestações](https://docs.stripe.com/disputes.md) estão diretamente ligadas à fraude, então quanto mais você reduzir a fraude, menor será sua taxa de contestação. Verifique se os pagamentos contestados compartilham características semelhantes (por exemplo, mesmas localidades ou valores parecidos). Você também pode fazer esse tipo de investigação analisando pagamentos reembolsados durante uma revisão. Se notar padrões, você pode testar e criar regras apropriadas. Se algum pagamento parecer fraudulento, reembolse e reporte como fraude para evitar contestações futuras. Também é possível usar nossos produtos de relatórios, o Sigma e o Data Pipeline, para [consultar dados de contestações e fraudes](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md). Você pode responder a qualquer nova contestação usando o Dashboard ou a API. A nossa [documentação de contestação](https://docs.stripe.com/disputes.md) inclui algumas sugestões sobre como apresentar um caso bem documentado. ### Antecipe grandes mudanças na sua empresa que possam impactar a taxa de fraudes Se estiver planejando um lançamento importante de produto ou mudanças no seu serviço (por exemplo, um novo produto de alto valor ou expansão do serviço para novos países), monitore esses pagamentos no começo. Para esses tipos de mudanças, uma prática recomendada é configurar algumas regras de análise para poder examinar todos os novos pagamentos. Ao analisar esses pagamentos e identificar padrões, você conseguirá criar regras e ajudar a proteger sua empresa contra fraudes. ## As regras são compatíveis com várias formas de pagamento Por padrão, as regras do Radar analisam pagamentos com cartão, ACH e débitos automáticos SEPA para a maioria dos usuários. Oferecemos suporte à regra de bloqueio de alto risco para todos esses métodos de pagamento. Se você usa o Radar for Fraud Teams ou o Radar for Platforms, também oferecemos suporte a regras personalizadas usando o atributo `:payment_method_type:` para criar regras aplicáveis apenas a métodos de pagamento específicos, por exemplo: `if :payment_method_type: = 'us_bank_account'`. Saiba mais sobre [atributos suportados](https://docs.stripe.com/radar/rules/supported-attributes.md). ## Construir regras de conta Com o Radar for Platforms, você também pode adicionar e gerenciar regras de conta na aba **Regras**, na página do Radar, no Dashboard. #### Para adicionar uma regra de conta 1. Clique em **+ Adicionar regra**. 1. Selecione o tipo de regra: **Revisão** ou **Pausa no repasse** (que aciona revisão E pausa de repasse). 1. No editor de regras, crie uma regra usando a sintaxe `{action} se {attribute} {operator} {value}`, em que: - `{action}`: é como o Radar responde quando os critérios da regra são atendidos. Este valor é preenchido automaticamente de acordo com o tipo de regra selecionado. - `{attribute}`: é o elemento do pagamento a ser avaliado, como o valor ou o tipo de cartão. Comece digitando com `:` para abrir uma lista de atributos válidos. - `{operator}`: é como comparar o atributo ao valor, como `=`, `>`, `!=` e assim por diante. - `{value}`: é o valor do atributo a ser avaliado. 1. Clique em **Testar regra**. 1. Se necessário, corrija os erros de validação detectados. 1. Na página **Revisar nova regra**, visualize as contas que corresponderiam a essa regra hoje para confirmar se deseja ativá-la. 1. Clique em **Ativar regra** para aplicar essa regra a todas as contas existentes e futuras. Testar regras em nível de conta leva mais tempo do que testar regras de transação, porém recomendamos testar para evitar acionar revisões de contas ou pausar repasses automáticos de forma não intencional. Primeiro, teste o comportamento de acionar contas para revisão. Em seguida, teste pausas automáticas de repasse quando estiver seguro de que a regra afeta as contas conforme esperado. ## See also - [Exemplos de regras do 3DS](https://docs.stripe.com/radar/rules.md#request-3d-secure) - [Guia de gestão contínua de fraudes](https://stripe.com/guides/improve-fraud-management-with-radar-for-fraud-teams-and-stripe-data) - [Consultar dados de contestações e fraudes](https://docs.stripe.com/stripe-data/query-disputes-and-fraud-data.md) - [Referência de regras](https://docs.stripe.com/radar/rules/reference.md) - [Atributos suportados](https://docs.stripe.com/radar/rules/supported-attributes.md)