BTCPay Server é um processador livre de pagamentos com licença MIT, executável em uma instância própria ou em um host de terceiros. O projeto fornece software, não uma conta universal de custódia nem arbitragem de disputas com comerciantes. A confiança depende da conexão real entre servidor, carteira e serviços de pagamento.
O comerciante conecta o caixa ou a loja online a uma fatura e ao método de recebimento escolhido. BTCPay Server cria endereços on-chain e solicitações Lightning, acompanha os pagamentos e oferece uma visão das faturas. Também inclui aplicativos de ponto de venda e doações e interfaces de integração. O código aberto permite inspeção e alterações, mas não comprova sozinho a segurança de uma instalação específica. [BTCPay Server — Source repository]
Uma carteira on-chain existente pode ser conectada por uma chave pública estendida: o servidor deriva endereços de recebimento sem precisar de sua chave privada. Uma carteira quente criada no servidor tem outro modelo de risco. Permissões de um nó Lightning também podem permitir movimentar seus fundos. Separe chaves de recebimento, assinatura e administração; a palavra self-hosted não determina sozinha quem pode gastar o dinheiro. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Um terceiro mantém o servidor enquanto o usuário pode receber diretamente na própria carteira. Isso não elimina a confiança: um servidor malicioso ou comprometido pode substituir a chave pública e desviar pagamentos futuros. Moedas já recebidas na carteira e novos dados de pagamento exibidos são questões diferentes. Verifique o recebimento também independentemente do caixa. O mesmo ataque pode atingir uma instância própria comprometida; o host também influencia disponibilidade e privacidade. [BTCPay Server — Third-party hosting risks]
A loja configura moeda, fonte da cotação, validade e confirmações exigidas. Processing em um pagamento on-chain aguarda a condição definida; Settled indica seu cumprimento. Um pagamento Lightning bem-sucedido não precisa esperar um bloco. Trate pagamentos insuficientes, excessivos, atrasados e mudanças manuais de estado, que não criam confirmações da rede. Converter um preço para bitcoin não é vender por fiat: um plugin ou provedor de conversão acrescenta taxas e exigências próprias de confiança. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
A loja deve manter o vínculo entre pedido e identificador da fatura. Greenfield API permite delimitar permissões por loja; não dê à chave mais acesso do que o necessário. Verifique webhooks conforme a documentação e processe eventos repetidos sem um segundo despacho. O retorno do cliente a uma página de agradecimento não prova sozinho o pagamento. Após uma interrupção, reconcilie os registros locais com os estados reais de faturas e pagamentos. [BTCPay Server — eCommerce integration]
Um nó próprio requer disponibilidade, gestão de canais e liquidez de entrada. Um serviço de liquidez, um swap ou uma carteira custodial resolve partes diferentes do problema e não constitui o mesmo modelo. Em um serviço custodial, o controle dos fundos fica com o provedor; nas outras opções, verifique permissões e riscos concretos. O logotipo BTCPay Server não garante o sucesso de todo pagamento nem taxas nulas. [BTCPay Server — Lightning options]
Faça cópias dos dados das lojas, faturas, configuração e dados necessários das carteiras conforme a implantação; uma seed não substitui a base de pedidos. A documentação Docker exige verificar a restauração da cópia. Um estado antigo de canal Lightning pode causar perda de fundos se restaurado incorretamente. Uma migração planejada com o nó original encerrado corretamente difere da recuperação de desastre; depois de iniciar o substituto, não reinicie a cópia original do mesmo nó. O procedimento deve corresponder ao backend utilizado. [BTCPay Server — Backup and restore]
Planeje atualizações, proteção do acesso administrativo, exposição de rede, monitoramento de disponibilidade e backups verificados. Hospedagem, hardware, taxas de rede, liquidez e suporte podem custar dinheiro mesmo se o programa não cobrar porcentagem de cada pagamento. Limite os dados de clientes armazenados. O comerciante resolve reembolsos e disputas de entrega, não os desenvolvedores do projeto; exportar faturas não garante o cumprimento de todas as obrigações contábeis. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Uma falha no caixa não significa perder moedas já recebidas
Em uma loja hipotética, o servidor conhece apenas os dados públicos de uma carteira externa. Se a hospedagem falhar, as moedas on-chain já recebidas continuam controladas pelas chaves da carteira, mas o caixa pode deixar de criar faturas ou informar pagamentos. O operador restaura o serviço, verifica a configuração de recebimento e reconcilia pedidos com a carteira. O exemplo não vale para uma carteira quente no servidor perdido nem para um estado desatualizado de canais Lightning.
Para ter uma visão mais completa, leia este verbete junto com Bitcoin Payment Processor, Bitcoin Point of Sale, Autocustódia, Lightning Network, Merchant Adoption, Bitcoin. Também há referências a este verbete em Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01BTCPay Server significa automaticamente autocustódia?+
Não. Isso depende da carteira conectada, do serviço Lightning e das permissões reais. Receber em uma carteira externa somente por uma chave pública difere de uma carteira quente em um servidor alheio ou de um backend custodial. Também é preciso confiar na correção dos dados de pagamento exibidos.
02Um backup da seed basta para recuperar tudo?+
A seed pode restaurar a carteira on-chain correspondente, mas não automaticamente faturas, configurações das lojas e estados dos canais Lightning. Essas partes têm backups e procedimentos próprios. A recuperação deve ser testada; uma cópia desatualizada de um nó Lightning ativo não pode ser tratada com segurança como um backup comum de arquivos.