Esta tradução é fornecida para conveniência. A versão em inglês é a que tem valor legal.
1. Custódia de chaves
Este é o importante, então leia duas vezes. Por padrão, os endereços de recebimento são derivados de material chave mantido pelo Operador, não por você: os pagamentos vão para os endereços do Operador e são creditados ao seu saldo, e você retira de lá. A assinatura não é automatizada — a aplicação web não tem um caminho que transmite uma transferência por conta própria; retiradas e pagamentos são revisados, assinados e transmitidos pelo Operador fora dela. Um comerciante que não deseja que o Operador mantenha seus fundos pode solicitar a derivação de seu próprio xPub; então os pagamentos se estabelecem em endereços que apenas aquele comerciante controla, e o Operador nunca tem as chaves deles.
2. Integridade da API e webhook
2.1 Assinatura
As solicitações de API e webhooks são assinados com HMAC-SHA256, com uma janela de timestamp para limitar a reprodução, e chaves de idempotência para que uma chamada repetida não atue duas vezes. As assinaturas são comparadas em tempo constante.
2.2 Webhooks de saída
Webhooks de saída são protegidos contra SSRF: apenas https, enviados para a URL que o comerciante configurou, fixados a um endereço IP validado, com intervalos privados, CGNAT e NAT64 negados.
3. Credenciais em repouso
As senhas são hashadas com bcrypt. O api_secret é criptografado em repouso com AES-256-GCM. Chaves privadas, frases-semente e números de cartão nunca são armazenados.
4. Segurança da conta
Autenticação de dois fatores TOTP opcional com códigos de recuperação. As sessões são rastreadas no lado do servidor e podem ser revogadas. Tokens CSRF protegem solicitações que alteram o estado. Limitação de taxa se aplica por IP e por chave.
5. Transporte e fortalecimento do navegador
HSTS, uma Política de Segurança de Conteúdo, X-Frame-Options definido como NEGAR, X-Content-Type-Options nosniff e uma Política de Referência.
6. Integridade do dinheiro
As liquidações são registradas em um livro razão apenas para anexação com um âncora de idempotência ÚNICA, de modo que o mesmo depósito não pode ser creditado duas vezes. Bloqueios consultivos serializam as mudanças de saldo, de modo que operações concorrentes não podem correr para um saldo em um estado errado.
7. O que não reivindicamos
A Payora não possui certificação PCI-DSS, SOC 2 ou ISO 27001, e nenhuma licença de regulador. Qualquer um que lhe disser o contrário está errado. O software fornece ao Operador configurações padrão fortes; a segurança de uma instância em execução também depende do servidor, hospedagem e práticas do Operador.
8. Seu lado disso
Mantenha seu segredo de API e senha privados. Ative a autenticação de dois fatores. Verifique as assinaturas do webhook em vez de confiar na carga útil. Verifique os endereços de pagamento cuidadosamente, incluindo qualquer tag de destino ou memo, porque uma transação enviada não pode ser recuperada.
9. Relatando uma vulnerabilidade
Relate problemas de segurança ao Operador em support@payora.money. Por favor, forneça detalhes suficientes para reproduzir, e não teste contra contas ou dados de outras pessoas.
Última atualização: 16 de julho de 2026. Se fizermos alterações materiais nesta página, a versão atualizada será postada aqui.
