Infraestrutura de pagamento vive e morre pela postura de segurança. Aqui está exatamente o que a gente faz, o que não faz e o que a gente não vai fingir ter ainda.
1. Não-custodial por design
A garantia de segurança mais forte que a gente oferece é arquitetural: a gente não segura fundos do merchant. Nunca. Quando o cliente paga com cartão, a on-ramp converte fiat em cripto e nosso splitter on-chain roteia atomicamente pro seu endereço de wallet na mesma transação, quase sempre na Ethereum (ETH ou USDC), às vezes na Polygon. Nossos servidores veem um evento, não um saldo. Não tem hot wallet, não tem tesouraria pooled, não tem conta omnibus, então não tem honeypot pra um atacante invadir. Se o PeptidePay sumir amanhã, seus pagamentos passados ainda estão on-chain na sua wallet.
2. Infraestrutura
Hosting: Vercel, com rede edge global e proteção DDoS.
State store: Upstash Redis com TLS em trânsito e AES-256 at rest.
Liquidação: on-chain, quase sempre Ethereum mainnet, às vezes Polygon. Mesmas premissas de segurança da própria rede.
DNS & CDN: endurecidos com HSTS preload, registros CAA fixando a CA, DNSSEC ativo.
Secrets: armazenados no env store criptografado da Vercel; rotacionados no offboarding de funcionário.
3. Autenticação
Só magic link — sem senha, nada pra phishar, nada pra reusar de um breach.
Magic links são de uso único e expiram em 15 minutos.
Sessions do dashboard duram pouco (7 dias) e ficam vinculadas ao browser que fez login.
Cookies de session são HTTP-only, Secure, SameSite=Lax.
Logins suspeitos (país novo, ASN novo) disparam alerta por email e podem ser revogados de qualquer session ativa.
4. Webhooks
Todo webhook é assinado com HMAC-SHA256 usando o secret da sua conta; verifica antes de confiar no payload.
Header de assinatura inclui timestamp; rejeita qualquer coisa mais velha que 5 minutos pra prevenir replay.
Fila de retry com backoff exponencial (30s, 2m, 10m, 30m, 1h, 3h, 12h, 24h) depois dropa.
Webhooks dropados ficam replayáveis pelo dashboard por 30 dias.
A gente publica o range de IP de egress atual pra você colocar no allowlist do firewall.
5. API keys
Keys são mostradas uma vez, armazenadas hasheadas (bcrypt) server-side; a gente não consegue recuperar pra você.
Rotacionáveis a qualquer momento em /app/settings — keys velha e nova funcionam em paralelo por 24 horas pra você deployar sem downtime.
Scoped keys estão planejadas pro Q3 2026; por enquanto keys têm acesso total.
Rate-limitadas por key: 100 req/segundo soft, 1000/segundo hard.
6. Criptografia
Em trânsito: TLS 1.3 em todo endpoint; TLS 1.2 permitido só pra consumers de webhook legacy e flagged pra deprecation.
At rest: AES-256 no Upstash Redis e no blob storage da Vercel.
Emails de cliente são hasheados (SHA-256 com salt por merchant) antes de ir pros logs de servidor; só o dashboard do merchant renderiza em claro.