Segurança

Visão geral — chaves, idempotência, webhooks, PCI, fraude e checklist obrigatório antes do GA.

Pagamentos têm consequência financeira direta — uma integração descuidada vira chargeback, fraude ou vazamento. Esta seção é o manual obrigatório antes de você gerar uma zsk_live_*.

Tópicos

Chaves de API

Publishable, secret, restricted — uso correto e rotação

Idempotência

Por que e como em todo POST financeiro

Webhooks

Verificação HMAC, retry, DLQ

Prevenção de fraude

Smart routing por BIN, circuit breaker, 3DS

Checklist antes do GA

Itens obrigatórios antes de subir live

Princípios

A segurança da Zhex se apoia em três princípios:

Defesa em profundidade. Várias camadas — chave + idempotência + webhook signing + 3DS + scoring de fraude. Comprometer uma não compromete o sistema.
Princípio do menor privilégio. Use sempre a chave mais restrita possível. Restricted (zrk_*) > Secret (zsk_*). Test mode (*_test_*) > Live (*_live_*).
Observabilidade obrigatória. Logs, métricas e alertas em chargeback rate, payment_failed rate, latência de webhook. Sem visibilidade você não detecta ataque.

O que NUNCA fazer

Receber PAN/CVV no seu form. Te joga em PCI-DSS SAQ-D (auditoria pesada). Use zhex.js sempre.
Comitar zsk_* em repositório. Mesmo privado. Mesmo "só para teste". Use env vars.
Confiar em webhook sem verificar assinatura. Ataque trivial: qualquer um disparar POST /webhooks/zhex com payload falso e creditar acesso.
Logar body de webhook em plaintext. PAN nunca chega lá, mas email, customer.id, amount estão. PII no log = vazamento.
Pular Idempotency-Key em POST financeiro. Retry de network duplica cobrança — incidente garantido.

Esta página foi útil?