Regras
As regras de prevenção a fraudes permitem que você tome medidas sempre que um pagamento cumpre determinados critérios.
O Stripe Radar oferece regras prontas para ajudar todos os usuários da Stripe a detectar e se proteger contra riscos de fraude.
Os usuários do Radar for Fraud Teams podem usar o Dashboard para criar regras personalizadas de acordo com a lógica comercial da sua empresa. Por exemplo, você pode:
- Solicitar 3D Secure para todos os pagamentos em que ele é aceito e 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 USD 1.000 que foram feitos com um cartão pré-pago
Cuidado
Comerciantes na UE podem ser afetados pelo Regulamento de Bloqueio Geográfico e as proibições de bloquear pagamentos de clientes localizados em estados-membros da UE.
Regras integradas
As regras a seguir são habilitadas por padrão para todos os usuários do Radar.
Verificações de risco por machine learning
O Stripe Radar e o Stripe Radar for Fraud Teams fornecem um conjunto de regras padrão baseadas nas avaliações dos nossos modelos de machine learning, que são:
Bloquear if :risk_level: =
'highest'
A regra bloqueia e não processa pagamentos com um alto risco de fraude. Essa regra é habilitada por padrão para usuários do Radar ou Radar for Fraud Teams.
Revisar if :risk_level: =
'elevated'
O comportamento padrão do Stripe Radar for Fraud Teams é analisar os pagamentos com suspeita de risco elevado de fraude.
Verificações de cartão tradicionais
Um pagamento ainda pode ser bem-sucedido mesmo que a verificação de CVC ou de endereço (AVS) falhe, porque os emissores de cartão consideram vários sinais ao decidir sobre a aprovação ou recusa de um pagamento. Em alguns casos, um emissor de cartão ainda pode aprovar um pagamento que considerar legítimo, mesmo que ocorra falha na verificação do CVC ou do código postal.
A Stripe tem regras integradas que permitem bloquear até mesmo pagamentos aprovados pelo emissor do cartão. Essas regras podem ser ativadas ou desativadas no Stripe Dashboard.
Essas regras também se aplicam ao processo de validação do cartão que ocorre ao anexar um cartão a um cliente. Nos casos em que você cria o cartão e o cliente juntos, a falha na validação de CVC ou código postal impede a criação bem-sucedida do registro do cliente. Essa regra pode não estar habilitada em sua conta por padrão, mas você pode habilitá-la ou desabilitá-la a qualquer momento usando o Dashboard.
Block if CVC verification fails
A Stripe bloqueia pagamentos reprovados na verificação de CVC do emissor do cartão. Se o cliente não informar o número de CVC, por exemplo, porque usa uma carteira, ou o emissor do cartão do cliente não aceitar a verificação, a regra não poderá bloquear o pagamento.
Block if postal code verification fails
A Stripe bloqueia os pagamentos quando há falha na verificação de código postal do emissor do cartão. Se o cliente não informar o código postal ou o emissor do cartão não aceitar a verificação, a regra não poderá bloquear o pagamento. Essa regra pode não estar habilitada por padrão para sua conta. É possível habilitá-la ou desabilitá-la a qualquer momento usando o Dashboard.
Regras integradas para solicitar 3D Secure
O uso do 3D Secure. exige que os clientes cumpram uma etapa de autenticação adicional para concluir o fluxo de compra. Se o 3D Secure autenticar um pagamento, a responsabilidade por qualquer contestação relacionada a fraude nesse pagamento normalmente muda do vendedor para o emissor. Isso significa que, na maioria dos casos, o vendedor não é responsável por custos de fraudes em pagamentos autenticados pelo 3D Secure.
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 (SCA) exigida 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 desativadas por padrão que você pode ativar para solicitar o 3DS dinamicamente ao usar o Radar com Payment Intents ou Setup Intents:
Request 3D Secure if 3D Secure is required for card
- Desativada por padrão. A ativação desta regra encaminha automaticamente o cliente para a autenticação 3D Secure se o cartão exigiu 3D Secure antes.
- A Stripe processa automaticamente códigos de recusa simples que indicam a exigência de 3DS pelos emissores. Além disso, também acionamos o 3DS quando necessário para cumprir regulamentos como a autenticação forte de cliente determinada pelo PSD2.
Request 3D Secure if 3D Secure is supported for card
- Desativado por padrão, mas similar à regra anterior. A ativação dessa regra encaminha o cliente para a autenticação 3D Secure, desde que o cartão seja compatível.
- Use essa regra em vez da anterior se quiser maximizar o número de pagamentos que têm transferência de responsabilidade. Esteja ciente de que esse requisito adicional pode diminuir as taxas de conversão.
Request 3D Secure if 3D Secure is recommended for card
- Desativado por padrão. A ativação dessa regra encaminha o cliente para a autenticação 3D Secure quando a Stripe acreditar que a autenticação 3D Secure possa ocorrer com impacto mínimo nas taxas de conversão.
- Habilite essa opção se desejar maximizar a quantidade de pagamentos que têm transferência de responsabilidade.
Como o 3D Secure exige que seu cliente passe por uma camada adicional de autenticação, o uso indiscriminado do 3D Secure pode reduzir as taxas de conversão. A Stripe recomenda que você somente ative as regras padrão “Request 3D Secure” se precisar que todos os pagamentos de cartões aceitos passem pelo 3D Secure.
A solicitação do 3D Secure não implica necessariamente em sua execução pelo emissor. Para obter mais detalhes sobre os possíveis resultados, consulte a documentação do 3D Secure.
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 e tentar a autenticação do 3D Secure, poderá avaliar o resultado com regras de permissão, bloqueio ou revisão.
Os atributos mais importantes para regras personalizadas do Radar são:
is_3d_secure
, que é verdadeiro quando o cartão é aceito, o 3D Secure foi tentado pelo emissor e o usuário não falhou na autenticação. Geralmente, recomendamos usar isso em regras de bloqueio.is_3d_secure_authenticated
, que é verdadeira quando o 3D Secure foi tentado pelo emissor e o usuário concluiu uma autenticação completa com êxito. O uso desse atributo em uma regra de bloqueio exclui transações legítimas que podem ter isenção de SCA ou não se enquadram em uma autenticação com falha ou êxito, como erros de processamento.has_liability_shift
, que é verdadeira quando a Stripe espera que o pagamento seja coberto pela regra de transferência de responsabilidade. Pode não ser sempre o mesmo que o 3D Secure (por exemplo, o Apple Pay em algumas regiões).
Para regras personalizadas, recomendamos manter as regras Solicitar 3D Secure
e Bloquear
dependendo do seu apetite por riscos. No entanto, não bloqueie transações quando o 3D Secure não for aceito, como algumas carteiras digitais.
Veja a seguir alguns exemplos que mostram como fazer isso em diferentes casos de uso:
Solicitar o 3D Secure com base no nível de risco do Radar
Recomendamos usar o Radar para solicitar o 3D Secure em todas as cobranças com base no nível de risco do Radar e acima de um determinado valor.
Regra do Radar | Descrição |
---|---|
Solicitar 3D Secure if :risk_level: != | Essa regra verifica o nível de risco do Radar e solicita o 3D Secure em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3D Secure não são bloqueados. As tentativas de 3D Secure com falha 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
Recomendamos usar o Radar para solicitar o 3D Secure em todas as cobranças com base em um nível de risco elevado ou alto do Radar e acima de um determinado valor. É melhor recusar cartões que não aceitam o 3D Secure.
Regra do Radar | Descrição |
---|---|
Solicitar 3D Secure if :risk_level: != | Essa regra verifica o nível de risco do Radar e solicita o 3D Secure em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Bloquear if not :is_3d_secure: and :risk_level: != | Esta regra bloqueia pagamentos sem um fluxo do 3D Secure para cobranças com nível de risco elevado ou alto e acima de um determinado valor. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA ou não se enquadrem em uma autenticaçã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. |
Somente aceite transações totalmente autenticadas pelo 3D Secure quando houver suporte para o 3D Secure
Você conta com a Stripe para ativar o 3D Secure quando necessário, em situações como autenticação forte de cliente (SCA), mas não deseja aceitar casos excepcionais, como erros de processamento.
Regra do Radar | Descrição |
---|---|
Block if :is_3d_secure: and not :is_3d_secure_authenticated: | Esta regra bloqueia pagamentos de cartões registrados no 3D Secure quando uma tentativa de autenticação no 3D Secure foi realizada, mas o usuário não conseguiu se autenticar. Cartões que não aceitam o 3D Secure; isenções de SCA; pagamentos fora da sessão, como cobranças recorrentes de assinaturas; 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 3D Secure em todas as cobranças com um atributo de metadados personalizado.
Regra do Radar | Descrição |
---|---|
Solicitar 3D Secure if ::foo:: = | Esta regra verifica uma condição de metadados e solicita o 3D Secure. Para verificar metadados do Cliente, substitua ::foo:: = 'bar' por um valor como ::customer:trusted:: = 'false' . |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3D Secure não são bloqueados. As tentativas de 3D Secure com falha 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 3D Secure em todas as cobranças 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:: = | Esta regra verifica uma condição de metadados e solicita o 3D Secure. Para verificar metadados do Cliente, substitua ::foo:: = 'bar' por um valor como ::customer:trusted:: = 'false' . |
Bloquear if ::foo:: = | Esta regra bloqueia pagamentos sem um fluxo de 3D Secure para cobranças com um atributo de metadados personalizado. No entanto, ela 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 revise se o 3D Secure não era aceito
Recomendamos usar o Radar para solicitar o 3D Secure em todos os cartões novos e revisar manualmente as cobranças de cartões que não aceitam o 3D Secure.
Regra do Radar | Descrição |
---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Esta regra solicita o 3D Secure 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 3D Secure somente se :risk_level: != . |
Request 3D Secure if :is_new_card_on_customer: | Como alternativa à regra acima, esta regra solicita o 3D Secure em todos os cartões usados pela primeira vez em um Customer. Para reduzir o atrito dos usuários, você pode adicionar uma condição para solicitar o 3D Secure somente se :risk_level: != . |
Revisar if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Esta regra marca os pagamentos nos quais o 3D Secure é esperado, mas não é aceito para análise manual. Ela ignora pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. Os pagamentos marcados para análise continuam para a autorização e podem fornecer sinais adicionais, como verificações de CVC do emissor. |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3D Secure não são bloqueados. As tentativas de 3D Secure com falha 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 3D Secure em todas as cobranças de emissores de cartão originários de países em uma lista personalizada 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 se há uma condição com base em emissores de cartão originários de países e os compara com uma lista personalizada. Quando correspondem, a regra solicita o 3D Secure. |
Bloquear if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Esta regra bloqueia pagamentos sem um fluxo do 3D Secure para cobranças originadas de países na lista personalizada. No entanto, ela 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. |
Sempre exija o 3D Secure com base no nível de risco do Radar e analise os casos extremos
Recomendamos usar o Radar para solicitar o 3D Secure em todas as cobranças com base no nível de risco do Radar e bloquear cartões que não aceitam o 3D Secure, mas analisam manualmente casos extremos.
Regra do Radar | Descrição |
---|---|
Solicitar 3D Secure if :risk_level: != | Essa regra verifica o nível de risco do Radar e solicita o 3D Secure em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Bloquear if not :is_3d_secure: and :risk_level: != | Esta regra bloqueia pagamentos sem um fluxo do 3D Secure para cobranças com nível de risco elevado ou alto acima de um determinado valor. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. |
Revisar if not :is_3d_secure_authenticated: and :risk_level: != | Esta regra marca os pagamentos para análise manual que estavam usando o 3D Secure, mas não resultaram em um fluxo totalmente autenticado. Isso analisaria casos extremos como attempt_acknowledged e também marcaria pagamentos legítimos apesar das isenções de SCA. Como as regras de análise são avaliadas após as regras de bloqueio, os cartões que não aceitarem o 3D Secure são bloqueados. |
Quando criar regras
As regras padrão da Stripe podem bloquear uma quantidade considerável de pagamentos fraudulentos. As empresas que precisam aumentar o controle sobre quais pagamentos desejam revisar, permitir ou bloquear podem criar regras personalizadas por meio do Radar for Fraud Teams.
Considere as seguintes questões ao decidir se deseja ativar regras personalizadas:
- Você considera determinados recursos ou comportamentos de usuário como mais arriscados (por exemplo, uso de um e-mail descartável)?
- Você deseja implementar regras baseadas em valores de pagamentos ou nível de risco percebido (por exemplo, revisar automaticamente pagamentos superiores a US$ 500 ou permitir automaticamente pagamentos inferiores a US$ 5)?
- Os seus pagamentos contestados e reembolsados atualmente têm algum padrão em comum (por exemplo, valores, tipos de cartão ou países similares)?
- Você tem regras que deseja migrar para a Stripe? Muitas dessas regras podem já fazer parte dos modelos de machine learning da Stripe. Vale a pena observar o desempenho de nosso sistema para sua empresa antes de personalizá-lo.
Como criar regras eficazes
Embora as regras possam ajudar você a automatizar seus fluxos de trabalho existentes, também podem afetar negativamente seu negócio se forem usadas incorretamente. Por exemplo, uma regra pode permitir automaticamente uma grande quantidade de pagamentos fraudulentos ou bloquear uma grande quantidade de pagamentos legítimos se não for definida corretamente.
Algumas dicas úteis ao configurar regras:
- As regras aplicam-se somente a pagamentos futuros e não a pagamentos já processados.
- As regras Solicitar 3D Secure aplicam-se somente ao usar o Stripe Checkout, Payment Intents ou Setup Intents, e são avaliadas antes das regras Revisar, Bloquear e Permitir.
- Antes de implementar qualquer regra para bloquear todos os pagamentos que cumprem os critérios, avalie se não é melhor revisar os pagamentos antes.
- Implemente regras de permissão o mínimo possível, pois elas substituem as regras padrão da Stripe por outras regras personalizadas que correspondem aos mesmos critérios.
- Você pode criar um máximo de 200 regras em todos os tipos de regras por conta.
Regras de criação
Você pode adicionar e gerenciar as regras na guia Regras da página do Radar no Dashboard.
Para adicionar uma nova regra:
- Clique em + Adicionar regra.
- Escolha o tipo de regra no submenu.
- 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 cumpridos. Esse valor é pré-preenchido com base na seleção de tipo de regra que você escolheu.
- {attribute}: o elemento da transação a avaliar, como o valor ou tipo de cartão. Comece a digitar com
:
para abrir uma lista de atributos válidos. Para avaliar seus metadados personalizados, coloque-os entre dois-pontos duplos. Por exemplo,::product_sku::
. - {operator}: como comparar o atributo ao valor, por exemplo
=
,>
,!=
e assim por diante. - {value}: o valor do atributo a ser avaliado.
- Clique em Testar regra.
- Se necessário, corrija os erros de validação detectados.
- Na página Revise a nova regra, analise o desempenho da regra em relação às suas transações recentes para confirmar se deseja habilitá-la.
- Clique em Adicionar regra para começar a aplicar a regra em todas as transações futuras.
Usar o Radar Assistant
O editor de regras da Stripe tem um assistente de LLM integrado que cria uma regra do Radar a partir de um instrução de linguagem natural.
Para usar o Radar Assistant:
- Na guia Regras da página do Radar no Dashboard, clique em + Adicionar regra.
- Escolha o tipo de regra no submenu.
- No editor de regras, clique em Radar Assistant.
Criação manual de regras
Radar Assistant
- 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.
- Quando o Assistant retorna uma sugestão, você pode inserir um comando adicional para fazer ajustes na regra ou clicar em Testar regra para comparar o desempenho da regra em relação ao seu histórico recente de transações.
- Quando estiver satisfeito com a regra, clique em Adicionar regra para habilitá-la em todas as transações futuras.
Consentimento de dados de treinamento: ao usar o Radar Assistant, você aceita que a Stripe registre e use os dados que você insere no chat para treinar e melhorar as funções do Radar Assistant. Se você não quiser que seus dados inseridos no chat sejam usados para essa finalidade, escreva as regras manualmente.
Saiba mais sobre os serviços da Stripe IA.
Regras de revisão
A Stripe ainda processa pagamentos normalmente quando eles cumprem os critérios de uma regra de análise. No entanto, nós os colocamos em sua fila de análises para que sua equipe possa analisá-los mais detalhadamente. Definir uma regra muito abrangente pode colocar muitos pagamentos na fila de análises, atrasando as entregas e sobrecarregando sua equipe.
A interface de testes 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 tivesse sido implementada. Enquanto testa uma regra e examina os últimos seis meses, certifique-se de que:
- O volume geral de pagamentos seja baixo. A análise desses pagamentos não deve sobrecarregar sua equipe.
- Os revisores humanos agreguem valor. Um revisor humano normalmente pode identificar melhor fraudes em pagamentos do que o sistema automatizado.
- A regra resulte 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 os legítimos dos 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 |
---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
Muito abrangente: resulta em excesso de análises | Mais concentrada: resulta em um número menor de análises |
Regras de bloqueio
É possível usar regras de bloqueio para bloquear pagamentos se você tiver certeza de que são fraudes ou com base em restrições aplicadas por sua empresa (como bloquear pagamentos de cartões pré-pagos). Se não souber aplicar regras de bloqueio, recomendamos usar uma regra para enviar pagamentos para análise. Depois de analisar esses pagamentos para verificar falsos positivos, você poderá definir se deseja criar uma regra de bloqueio.
As regras de bloqueio só afetam fraudes em pagamentos bem-sucedidos, pois 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 a sua regra parece ter um ótimo desempenho, mas já está abrangida por uma regra existente, a nova regra pode não ser necessária. Igualmente, se os resultados durante os testes parecerem mistos, considere configurar uma regra de análise para reunir mais informações sobre esses tipos de pagamento.
A seguir há um exemplo de como melhorar uma regra de bloqueio criada por uma empresa que está sofrendo com um nível elevado de fraude em pagamentos fora dos EUA:
Regra original | Regra melhorada |
---|---|
Block if :card_country: != | Block if :card_country: != |
Muito abrangente: alta quantidade de pagamentos legítimos bloqueados | Mais concentrada: resulta em um número menor de análises |
Regras de permissão
As regras de permissão sobrepõem as demais regras, incluindo os modelos de machine learning da Stripe, por isso você deve usá-las cuidadosamente. Várias empresas podem não precisar implementar regras de permissão. Se você teme que uma regra de permissão possa deixar passar uma pequena quantidade de fraudes, considere realizar ajustes para restringir ainda mais essas regras antes de implementá-las. Como as regras de permissão sobrepõem as demais regras, incluindo as avaliações de machine learning da Stripe, você deve criar regras de permissão que continuem a bloquear todos os pagamentos que acreditamos ser fraudulentos.
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 a quantidade de pagamentos já bloqueados que teriam sido permitidos. As regras de permissão sobrepõem as demais regras e a avaliação de risco da Stripe. Ao testar uma nova regra de permissão, todos os pagamentos mostrados teriam sido permitidos se essa regra estivesse ativa. Isso pode incluir pagamentos que foram bloqueados ou contestados, impactando suas futuras taxas de contestação.
- Continuar a bloquear todos os pagamentos de alto risco. É possível fazer isso com esta regra de permissão:
and :risk_level: !=
'highest'
- Avalie um histórico de transações legítimas na sua empresa. Você pode aproveitar 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 e procure atributos que incluam a palavra “customer”.
A seguir temos um exemplo de como melhorar uma regra de permissão para uma empresa que normalmente (mas nem sempre) vê bons pagamentos vindos de clientes no Reino Unido:
Regra original | Regra melhorada |
---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
Muito abrangente: alguns pagamentos fraudulentos são autorizados | Mais concentrada: menos pagamentos fraudulentos são autorizados |
Mantenha suas regras
À medida que sua empresa continua a crescer, é importante que suas regras continuam a refletir os tipos de clientes com os quais deseja fazer negócio. Veja algumas práticas recomendadas para manter as regras alinhadas ao estado da empresa.
Monitore as regras regularmente para verificar se continuam eficazes
Métricas das regras
Os padrões de fraude mudam constantemente, por isso, fornecemos métricas para mostrar o desempenho dessas regras. Essas métricas variam dependendo do tipo de regra, pois os tipos de regra realizam ações diferentes.
Use o quadro de desempenho da regra para entender o comportamento das suas regras do Radar. Busque picos ou quedas inesperadas no número de pagamentos que correspondem às suas regras, como regras de permissão que aceitam muitos pagamentos ou regras de bloqueio que bloqueiam em excesso. Esses picos podem indicar uma mudança nos tipos de pagamentos que sua empresa está recebendo ou que podem justificar atualizações às próprias regras. As atualizações feitas às regras são exibidas como triângulos no gráfico e podem ajudar você a comparar o impacto da mudança antes e depois de fazê-la.
As linhas codificadas por cores acompanham a quantidade de pagamentos que correspondem às regras do 3D Secure, regras de permissão, regras de bloqueio e regras de análise. Os símbolos triangulares nessas linhas do gráfico representam atualizações às regras do tipo correspondente.
Mostramos informações sobre a eficácia das suas regras e em quantos pagamentos cada uma agiu. Também é possível filtrar e baixar uma lista com todos os pagamentos aos quais uma regra foi aplicada. Avalie essas informações para decidir se é preciso mudar ou remover alguma regra.
Para ver comandos adicionais, clique no ícone de três pontos (•••). Os comandos adicionais incluem: Desativar, Ativar, Editar ou Excluir para qualquer regra.
Opcionalmente, você pode usar os nossos produtos de geração de relatórios Sigma e Data Pipelines para consultar dados de contestações e fraudes, incluindo decisões e atributos de regras para cada pagamento individual.
Avalie a eficácia das regras
Mostramos informações sobre a eficácia das suas regras e quantos pagamentos cada uma afetou. Também é possível filtrar e baixar uma lista com todos os pagamentos aos quais uma regra foi aplicada. Revise as questões de amostra na tabela a seguir para ajudar você a decidir se é preciso mudar ou remover alguma regra.
Tipo de regra | Avaliar | Ações a serem consideradas |
---|---|---|
Geral | Esta regra não corresponde mais a nenhum pagamento? | Remova a regra. |
Esta regra tem um comportamento anômalo, como permitir mais pagamentos do que em períodos anteriores? | Revise manualmente os pagamentos que corresponderam a essa regra para determinar se esse é o comportamento desejado. | |
3DS | A taxa de conclusão do 3DS é alta, mas o número de contestações/EFWs é baixo? | Remova a regra, pois você pode criar empecilhos para bons usuários. |
O número de fraudes em transações aprovadas no 3DS é alto? | Considere modificar sua regra 3DS para uma regra de bloqueio para evitar que esses usuários passem por um fluxo sem atritos (controlado por emissores) ou cometam fraudes primárias. | |
A taxa de conversão do 3DS é baixa? | Essa pode ser uma boa regra, pois bloqueia principalmente fraudadores, mas considere investigar manualmente os pagamentos correspondentes para garantir que bons usuários não desistam devido a empecilhos adicionais. | |
Permitir | O número de contestações, EFWs, reembolsos ou pagamentos malsucedidos é alto? | Remova a regra que permite a aprovação de pagamentos incorretos. |
Bloquear | O número de bloqueios está diminuindo, mas sua fraude continua estável ou está aumentando? | Modifique sua regra, pois ela pode não funcionar mais. |
O número de bloqueios está aumentando, mas sua fraude continua estável ou está aumentando? | Modifique sua regra, pois ela pode estar bloqueando bons usuários. | |
O número de bloqueios está aumentando e sua fraude está diminuindo? | Isso sugere que sua regra é eficaz, mas considere revisar manualmente algumas transações para assegurar que não esteja bloqueando muitos usuários válidos. | |
Análise manual | A porcentagem de pagamentos revisados é baixa? | Torne a regra mais restritiva, pois ela pode ser muito ampla. |
O número de pagamentos bem-sucedidos ou aprovados é alto? | Remova totalmente a regra de análise manual ou crie uma regra de permissão para esses pagamentos. | |
O número de reembolsos ou contestações e avisos antecipados de fraude é alto? | Converta em uma regra de bloqueio. |
Regras para solicitação de 3DS
Para as regras para solicitação de 3DS, exibimos:
- 3DS solicitado — a quantidade de vezes que uma regra acionou uma solicitação de 3DS.
Clique em uma regra 3DS para ver as seguintes métricas:
Regras de permissão
Nas regras de permissão, os usuários do Radar for Fraud Teams visualizam:
- Pagamentos permitidos — a quantidade total de pagamentos permitidos por suas regras.
- Volume de pagamentos permitidos — o valor total, na sua moeda local, associado com pagamentos permitidos por suas regras.
- Pontuação de risco – os resultados de risco correspondentes atribuídos pelos modelos de machine learning da Stripe para a definição de pagamentos permitidos pelas suas regras.
- Contestações de sobreposições — a quantidade total de pagamentos permitidos que foram contestados.
- Volume de contestações de sobreposições — o valor total, no sua moeda local, associado com contestações de pagamentos permitidos.
Clique em uma regra de permissão para ver as seguintes métricas:
Regras de bloqueio
Nas regras de bloqueio, exibimos:
- Pagamentos bloqueados – a quantidade total de pagamentos bloqueados por suas regras.
- Volume de pagamentos bloqueados – o valor total, na sua moeda local, associado com pagamentos bloqueados por suas regras.
Os usuários do Radar for Fraud Teams também visualizam:
- Pontuação de risco – os resultados de risco correspondentes atribuídos pelos modelos de machine learning da Stripe para a definição de pagamentos permitidos pelas suas regras.
- Taxa estimada de falsos positivos – a porcentagem estimada de pagamentos não fraudulentos que foram bloqueados por suas regras de bloqueio e por regras individuais. Essas estimativas são feitas usando as taxas estimadas de falsos positivos das pontuações de risco de machine learning correspondentes, que calculamos com experimentos em toda a rede Stripe.
- Estimativa de contestações evitadas – a quantidade estimada de contestações que suas regras de bloqueio evitaram. Essa estimativa é feita usando a precisão das pontuações de risco de machine learning correspondentes, que calculamos com experimentos em toda a rede Stripe.
Clique em uma regra de bloqueio para ver as seguintes métricas:
Regras de análise
Nas regras de análise, os usuários do Radar for Fraud Teams visualizam:
- Pagamentos enviados para análise — a quantidade total de pagamentos que foram enviados para análise manual por suas regras.
- Volume de análises aprovadas — a quantidade total, na sua moeda local, associada com análises de pagamentos aprovadas.
- Taxa de reembolso — a porcentagem de análises que foram reembolsadas.
- Contestações de análises aprovadas — a quantidade total de pagamentos que foram aprovados na sua análise, mas que foram contestados.
- Volume de contestações de análises aprovadas — o valor total, no sua moeda local, associado com contestações de análises de pagamentos aprovados.
Clique em uma regra de revisão para ver as seguintes métricas:
Monitore regularmente sua fila de análise manual
Se a sua fila de análises estiver ficando longa demais, verifique se está aplicando regras adequadas. Se a maior parte das análises forem reembolsadas por fraude, pode ser recomendável acrescentar algumas regras para bloquear pagamentos. Já se a maioria dos pagamentos for aprovada, pode ser melhor restringir as regras de análise.
Analise seus pagamentos contestados e reembolsados
As contestações são inerentemente vinculadas a fraudes, por isso, quanto mais você reduzir as fraudes, menor será a taxa de contestações. Você deve verificar se os pagamentos contestados têm características similares (por exemplo, dos mesmos locais ou de valores similares). Também é possível realizar esse tipo de investigação ao analisar pagamentos que foram reembolsados durante uma revisão. Se você identificar tendências, é possível testar e criar as regras apropriadas. Se os pagamentos parecerem ser fraudes, reembolse e reporte-os como fraude para evitar possíveis contestações.
Opcionalmente, você pode usar os nossos produtos de geração de relatórios Sigma e Data Pipelines para consultar dados de contestações e fraudes.
Você pode responder a qualquer nova contestação usando o Dashboard ou a API. A nossa documentação de contestação inclui algumas sugestões sobre como apresentar um caso bem documentado.
Antecipe grandes mudanças no seu negócio 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ê pode criar regras e proteger sua empresa contra fraudes.