Modelo de segurança

Limites de confiança

Principal	Credencial	Pode
Seu servidor	Chave de API live secreta (gp_live_…), com escopos — disponível quando sua conta for ativada	Usar a API de lojistas para a sua organização e o seu ambiente
Sua equipe	Sessão do painel (cookie HttpOnly mantido no servidor), baseada em funções, MFA disponível	Gerenciar a organização dentro da sua função
Seu cliente	Id de sessão de checkout impossível de adivinhar	Ver uma visão sanitizada de um pagamento e agir no checkout dele
Operadores da plataforma	Identidade separada com MFA obrigatório	Trabalho de suporte e risco; ações relevantes (decisões de KYB, resoluções manuais, flags, modo live) exigem a aprovação de um segundo operador. Um operador também revisa todo saque
Watchers de cadeia	Credencial interna em um listener interno	Enviar observações, que o gateway valida de novo

A organização é sempre derivada do principal autenticado — nunca do corpo da requisição. O isolamento entre tenants é aplicado nas consultas e, como defesa em profundidade, pela segurança em nível de linha (row-level security) do banco de dados para o papel da aplicação.

O que nunca pedimos

• Chaves privadas, frases-semente ou arquivos de carteira.
• Números de cartão ou CVV (não oferecemos processamento de cartões; seriam necessários campos hospedados por um parceiro).
• O seu segredo de assinatura de webhook depois que ele foi exibido a você.

Segredos e dados em repouso

• Chaves de API e tokens de sessão são armazenados apenas como hashes com chave; o valor completo é exibido uma única vez.
• Segredos de assinatura de webhook, seeds de MFA e chaves públicas estendidas de carteiras são criptografados em repouso; as chaves estendidas nunca são retornadas pela API (apenas a impressão digital).
• Os logs nunca contêm cabeçalhos Authorization, segredos de assinatura ou dados pessoais completos. Os logs de requisições registram método, caminho, status, latência e o prefixo da chave — não os corpos.
• Os dados de clientes são minimizados: um e-mail e/ou a sua referência, apenas se você os enviar.

Saída de webhooks (proteção contra SSRF)

As URLs dos endpoints precisam ser HTTPS públicas. No momento da entrega, o endereço de destino é verificado quando a conexão é feita, de modo que um DNS rebinding não consegue apontar um hostname para um serviço interno. Faixas privadas, de loopback, link-local, de NAT de operadora (CGNAT) e de metadados são recusadas; redirecionamentos são informados, não seguidos; tamanhos e tempos de requisição e resposta são limitados.

Integridade dos registros financeiros

• Mudanças de estado de pagamento, alocações da cadeia, lançamentos do razão e eventos de auditoria são append-only no nível do banco de dados.
• Os lançamentos do razão precisam fechar por moeda, ou a transação é rejeitada.
• O log de auditoria é encadeado por hash por organização (GET /v1/audit-events retorna chain_valid para a janela).
• Os operadores não podem marcar um pagamento externo como confirmado sem evidência documentada e a aprovação de um segundo operador; os eventos originais são preservados.

Custódia live

Os pagamentos live são em custódia e são ativados após a verificação e aprovação da sua conta. Para uma conta ativada:

• Os fundos recebidos ficam nas carteiras Bitcart da plataforma. O saldo de cada organização é a soma de movimentos append-only do razão em unidades base inteiras, e uma fatura só pode ser creditada uma vez.
• Os corpos dos callbacks da Bitcart nunca são considerados confiáveis: o FeitPay busca de novo a fatura ou o saque na Bitcart com a credencial da plataforma, e os workers também fazem polling.
• Os saques vão apenas para endereços da lista de permitidos que passaram por uma verificação de formato e checksum e por um período de espera. O valor fica retido quando o saque é solicitado, um segundo membro da organização o aprova (ativado por padrão), um operador do FeitPay sempre o revisa e a Bitcart o envia a partir da carteira quente da plataforma. Um envio nunca é repetido automaticamente.
• O próprio FeitPay não armazena chaves privadas nem frases-semente: as chaves das carteiras da plataforma ficam na conta Bitcart dela, que assina os saques.

Suas responsabilidades

• Mantenha as chaves secretas e os segredos de webhook em um gerenciador de segredos; troque-os quando houver mudanças na equipe ou suspeita de exposição.
• Verifique as assinaturas de webhook sobre o corpo bruto e descarte duplicatas pelo event_id.
• Entregue somente quando fulfillable, confirmando com a API.
• Exija MFA dos membros da equipe com funções de alto impacto.

Como relatar uma vulnerabilidade

Relate suspeitas de vulnerabilidade pelo formulário de contato do site (assunto Segurança). Inclua o request id de qualquer chamada afetada e evite testar contra dados de outros lojistas.