docs

Checklist antes do GA

12 itens obrigatórios antes de gerar uma zsk_live_*. Imprima, marque, suba.

Antes de gerar uma zsk_live_* e processar transação real, passe por todos os 12 itens abaixo. Cada um previne uma classe específica de incidente.

Checklist

Trocou todas as chaves zsk_test_* por zsk_live_* em variável de ambiente (não em código). Verifique grep -r "zsk_" src/ e git log -S 'zsk_'.
Configurou WebhookEndpoint apontando para HTTPS de produção, com whsec_live_* rotacionado nos últimos 90 dias.
Implementou verificação de assinatura HMAC em todos os endpoints de webhook. Sem exceções. Veja Webhooks.
Tratamento idempotente de webhooks — event.id como dedup key em tabela processed_events. Mesmo evento chegando 2x não duplica side-effect.
Sempre envia Idempotency-Key (UUIDv4) em POSTs financeiros (/payment_intents, /refunds, /transfers, /subscriptions). Veja Idempotência.
Testou em test mode os 6 fluxos: success, decline, 3DS frictionless, 3DS challenge, refund total/parcial, dispute. Para fixtures, veja Cartões de teste.
Logs do servidor não contêm PAN, CVV, zsk_*, whsec_* nem token (tok_* é OK pois é single-use). Configure logger (Pino, Winston) para mascarar Authorization headers automaticamente.
Alarme em logs para risk_score > 70 ou taxa de payment_failed > 5%. Spike inesperado é incidente em formação.
Plano de rotação de chaves documentado: 90 dias para zsk_live_*, 180 dias para whsec_live_*. Tarefa recorrente no calendário.
Restricted keys (zrk_*) usadas em workers/ETL/integrações com escopo mínimo. zsk_* apenas no servidor principal de cobrança. Veja Chaves.
Rate limiting na sua aplicação. A Zhex tem 100 req/s por IP, mas você precisa do seu (proteção contra bot enumerando catálogo).
Monitoramento de chargeback rate (alvo: < 0,9% para Visa/Master, < 1% para Amex). Acima disso, fines de bandeira começam.

Pós-GA — primeiros 7 dias

Atenção redobrada na primeira semana de produção:

  • Diariamente: abra dashboard, cheque chargeback rate + payment_failed rate vs. baseline test mode.
  • Diariamente: abra Events no dashboard, verifique webhooks marcados failed ou em DLQ. Replay manualmente os recuperáveis.
  • 3º dia: chame GET /v1/events?limit=100 ou abra Events no dashboard — sanity check de que tudo está sendo entregue.
  • 7º dia: primeiro reconcile contábil — match de payouts Zhex × seu DB. Discrepância > 0,1% = abrir suporte.

Pós-GA — recorrente

  • Semanal: revisão de regras Radar — alguma com fall rate > 10%?
  • Mensal: rotação parcial. Mesmo sem incidente, gere nova zsk_live_* e revogue a anterior depois de 30 dias.
  • Trimestral: auditoria do checklist completo. Algum item degradou?
  • Anual: SAQ-A assinado e arquivado.

Em caso de incidente

  1. Pause as cobranças. Em emergência, desative o WebhookEndpoint (ou mude target para sumidouro) — para o efeito sem impactar API.
  2. Revogue a chave afetada. Dashboard → API keys → Revoke. Em < 5s globalmente.
  3. Audite os últimos 24h. Events no dashboard, filtro por created > 24h ago. Procure padrões anômalos.
  4. Restore controle. Nova chave, novo deploy, validação ponta-a-ponta em test mode antes de retomar.
  5. Postmortem. Documente o que houve. Se foi vazamento, notifique customers afetados em < 72h (LGPD/GDPR exigem).

Suporte de incidente 24/7 está disponível em planos Business+. Email incident@zhex.com ou hotline no dashboard.

Esta página foi útil?

Atualizado em

Nesta página

Checklist
Pós-GA — primeiros 7 dias
Pós-GA — recorrente
Em caso de incidente