Prevenção de fraude

A Zhex aplica roteamento por risco automaticamente em cada PaymentIntent antes de a transação chegar no adquirente: BIN, geo, padrão de tentativas, histórico de circuit breaker. O resultado é uma decisão de qual adquirente atende e em que condições.

O que não existe hoje é um motor de regras customizáveis (estilo Stripe Radar) exposto via API ou dashboard. Smart routing acontece sob o capô; configuração explícita de regras if X then Y no seu lado é roadmap.

O que a Zhex já faz

Smart routing por BIN

O primeiro 6 dígitos do cartão (BIN) tem histórico:

• BIN com aprovação alta no adquirente A → roteia para A.
• BIN historicamente recusado em adquirente cross-border → vai para o BR doméstico.
• BIN pré-pago restrito → roteia para adquirente que aceita pré-pago (alguns recusam).

Você não configura nada — o roteamento é automático e auditável no dashboard (Transações → detalhe → Roteamento).

Circuit breaker

Cada adquirente tem CIRCUIT por provider × payment method × region. Quando taxa de erro spikes (5xx, timeouts), o circuit abre e o tráfego é desviado para o secundário em segundos. Você não vê — só sente que aprovação se mantém estável mesmo quando um adquirente cai.

3DS automático

Para cartão BR > R$ 200 ou perfil de risco elevado, a Zhex aciona 3DS automaticamente. O resultado:

A decisão é interna; o PaymentIntent que cair em 3DS challenge entra em requires_action (gerenciado pelo checkout hosted) até o cliente concluir a autenticação no app do banco.

O que cabe ao seu lado

Sem motor de regras customizado exposto, sua defesa concentra-se em decisões pré-cobrança:

1. Limites por customer/IP no seu sistema

Antes de chamar POST /v1/payment_intents, conte tentativas recentes:

const recentAttempts = await db.paymentAttempts.count({
  where: {
    customerId,
    createdAt: { gte: new Date(Date.now() - 60 * 60_000) },
  },
});

if (recentAttempts > 5) {
  return res.status(429).json({ error: 'too_many_attempts' });
}

const intent = await zhex.paymentIntents.create({ /* … */ });
await db.paymentAttempts.create({ data: { customerId, ip: req.ip } });

2. Email reputation

Bloqueie domínios descartáveis e emails muito recém-criados na sua camada de signup. Listas públicas (mailcheck, disposable-email-domains) cobrem 95% dos casos.

3. CPF/CNPJ duplicado em cartões diferentes

Mesmo customer.document aparecendo com 3+ cartões diferentes em janela curta é forte indicador de fraude. Trate como suspeito antes de criar o intent.

4. Sempre confirme via webhook

Não confie no body do POST — pode ser interceptado/modificado por proxy. payment_intent.succeeded é a única fonte da verdade, e ele vem assinado HMAC.

Métricas a monitorar

Em Dashboard → Transações, acompanhe:

Boas práticas

• 3DS em ticket alto sempre. R$ 200+ no BR ou US$ 50+ internacional. Custo zero em frictionless e liability shift garantido.
• Refund proativo > chargeback. Se cliente reclamou e tem razão, refunde antes que vire disputa.
• Whitelist customers conhecidos. Customer recorrente sem chargeback histórico = não dispare fricção extra.
• Statement claro. "ZHEX*MEUSITE_PREMIUM" reduz "não reconheço a cobrança" — fonte número 1 de chargeback.
• Cancelamento auto-servido em assinatura. Sem isso, cliente cancela via cartão = chargeback.