Summary

  • Os atributos de frequência do Stripe Radar excluem o pagamento em análise. authorized_charges_per_email_hourly vale zero na primeira tentativa daquele e-mail na hora anterior; se ela for autorizada, a segunda vê um.
  • Com as duas primeiras tentativas autorizadas dentro dessa janela, > 1 coincide pela primeira vez com a terceira; >= 1 pode coincidir com a segunda. Outras regras e o emissor ainda participam do resultado final.

Uma cobrança entra, a memória espera

Quem administra um checkout sabe o custo de uma sequência de tentativas: pode ser teste de cartões, pode ser um cliente legítimo tentando terminar a compra. Uma regra de frequência parece uma resposta direta. O problema mora no instante em que a Stripe mede a frequência. Segundo o guia do Radar, o pagamento que está sendo processado fica fora do contador. A regra julga a bagagem que chegou com ele.

No exemplo oficial, authorized_charges_per_email_hourly soma autorizações bem-sucedidas associadas ao e-mail na hora precedente. A primeira tentativa encontra zero. Depois de autorizada, a próxima encontra um. Se também for autorizada, a terceira encontra dois. Uma condição > 1 começa a coincidir nessa terceira; >= 1 começa na segunda. A hora é uma janela móvel: quando uma autorização antiga sai dela, o número cai, mesmo que o e-mail continue ativo.

O verbo embutido no atributo importa. A Stripe oferece medidas separadas para autorizações, tentativas de cobrança, recusas do emissor e bloqueios feitos pelos modelos de aprendizado de máquina do Radar. Uma série de recusas não eleva o contador de autorizações aprovadas. Um bloqueio por regra personalizada não deve ser lançado na conta de bloqueios do modelo. Se o lojista observa tentativas e configura autorizações, a tela pode mostrar calmaria justamente quando o fluxo está mais barulhento.

A documentação atual da Stripe diz que todas as transações passam pelas regras padrão; criar regras próprias exige um plano Radar que ofereça o recurso. O guia ainda descreve a precedência das regras de permitir, bloquear e revisar. O valor zero em um atributo de frequência nunca decide sozinho o destino do pagamento. Uma regra anterior, outra verificação ou o emissor podem mudar a saída.

O prejuízo potencial aparece dos dois lados. Um IP compartilhado pode juntar compradores honestos no mesmo histórico; e-mails descartáveis podem dividir a atividade de quem testa cartões. Os documentos públicos descrevem o mecanismo, mas não trazem a configuração de um comércio específico nem sua taxa de pedidos perdidos. Para avaliar um caso, é preciso a expressão ativa e os valores e decisões registrados em cada pagamento.

Sources