TODOS OS SISTEMAS OPERACIONAIS 14 REGIÕES · ESCUDO DE 1.2 TBPS RECARREGAR COM BTC · XMR · LTC · ETH · USDT +3 MOEDAS

TUTORIAIS

Como aceitar pagamentos em Bitcoin você mesmo com o BTCPay Server

11 min de leitura

Como aceitar pagamentos em Bitcoin você mesmo com o BTCPay Server

Todo processador de pagamentos hospedado é uma empresa que pode congelar você. Isso não é hipótese para quem recebe em Bitcoin: os grandes processadores adicionaram verificação de identidade, limites de repasse e regras de liquidação anos atrás, e um comerciante que falha em uma dessas verificações costuma descobrir isso com o dinheiro já em trânsito. O BTCPay Server existe exatamente por causa disso. É um software livre e de código aberto que transforma um servidor sob seu controle no seu próprio checkout — faturas, uma tela de ponto de venda, plugins de loja, Lightning — sem nenhuma empresa no meio, sem percentual retido e sem conta para perder. Instalá-lo é genuinamente o trabalho de uma tarde. O que decide se o resultado é bom é a máquina por trás dele, e o punhado de detalhes que uma instalação padrão silenciosamente deixa apontando de volta para você.

O que o BTCPay Server realmente substitui

Um processador hospedado fica entre o seu cliente e a sua carteira. Ele gera o endereço, observa a cadeia, converte o valor, retém os fundos por algum período e, por fim, repassa o pagamento a você. Cada uma dessas etapas é algo que ele aprende sobre você e um ponto em que pode recusar. O BTCPay faz o mesmo trabalho em um hardware que você aluga, e a diferença no que ele sabe é total.

  • Os pagamentos caem direto na sua própria carteira. Você entrega ao BTCPay uma chave pública estendida, ele deriva um endereço novo para cada fatura e fica observando — nunca guarda uma chave privada para pagamentos on-chain e não consegue movimentar um único satoshi.
  • Não há taxa nem conta. O software é de código aberto, você mesmo o roda, e não existe nada para solicitar nem nada de onde você possa ser suspenso.
  • Ele cuida das partes tediosas de construir: vencimento de faturas, conversão de taxa em tempo real, pagamentos a menor e a maior, pagamentos parciais, reembolsos e um recibo que o cliente pode verificar de forma independente.
  • Ele já vem com as interfaces que a maioria das pessoas precisa — uma tela de ponto de venda, botões de pagamento, uma página de crowdfunding, plugins para as plataformas de e-commerce mais usadas — e uma API completa para quem for integrá-lo ao próprio software.
  • O Lightning vem na mesma implantação se você quiser, e é isso que torna viáveis pagamentos abaixo de alguns dólares.

Vale deixar esse limite claro. O BTCPay não transforma Bitcoin na sua moeda local, e não elimina a exchange ou o banco se for para lá que o dinheiro eventualmente precisa ir. O que ele elimina é o processador — o intermediário que ficava com uma parte, retinha seus fundos no meio do caminho e exigia sua identidade para isso. O que você ganha em troca tem o mesmo formato de um site que você mesmo hospeda: mais controle, e o trabalho que vem junto com ele.

Você se torna o processador de pagamentos

Esse trabalho é o custo honesto de se auto-hospedar, e é muito melhor entendê-lo antes da instalação do que depois. Ninguém monitora o seu uptime, ninguém restaura o seu backup, e não há ninguém do outro lado de uma linha de suporte no momento em que um cliente insiste que pagou e você não consegue ver isso.

  • O uptime é seu. Uma fatura não pode ser criada enquanto o servidor está fora do ar, então um checkout que precisa funcionar sempre exige uma máquina que alguém de fato monitore.
  • Os backups são seus. Perder o servidor é sobrevivível; perder o descritor da carteira ou o estado dos canais Lightning não é.
  • A custódia de chaves se divide em duas. Os fundos on-chain ficam em uma carteira que o BTCPay apenas observa, que é o arranjo seguro. Os fundos do Lightning ficam em uma carteira quente no próprio servidor, o que não é — trate esse saldo como capital de giro, nunca como poupança.
  • As disputas não têm árbitro. Não existem chargebacks, o que é em grande parte o objetivo, mas também significa que todo reembolso é uma decisão que você toma e uma transação que você envia.
  • As atualizações são suas. Por baixo da interface amigável existe uma stack de containers com um nó de Bitcoin dentro dela, e isso exige a mesma disciplina de manutenção de qualquer outra coisa deixada rodando em um IP público.

Nada disso é pesado. São alguns minutos por mês depois que a coisa está rodando, mais uma tarde cuidadosa no início. Simplesmente não é zero, e a taxa de um processador estava, em parte, pagando exatamente por isso.

Dimensionando a máquina: o nó por trás decide tudo

O BTCPay em si é uma aplicação leve. O nó de Bitcoin contra o qual ele roda não é, e quase todo erro de dimensionamento aqui vem de planejar para a aplicação web em vez de para a cadeia por baixo dela. Uma implantação padrão sobe o Bitcoin Core, um indexador que rastreia suas carteiras, um banco de dados, um proxy reverso e a aplicação — e é o Core que exige disco, memória e paciência.

  • O armazenamento é a decisão que escolhe o seu plano. Uma cadeia sem poda já passa de 750 GB hoje e cresce cerca de 7 GB por mês. A implantação já vem com presets de economia de armazenamento que limitam os dados de blocos a cerca de 100, 50 ou 25 GB, e cada um deles continua sendo um nó completo de verdade, que verifica cada regra por conta própria.
  • A poda não encurta a primeira sincronização. De qualquer forma, o Core baixa e verifica cada bloco desde o gênese; a poda só decide o que ele guarda depois.
  • A memória é de onde vem a velocidade de sincronização. 4 GB já rodam, 8 GB sincronizam visivelmente mais rápido e deixam espaço para o Lightning e para um banco de dados que não disputa cache com o nó.
  • O NVMe não é opcional. A sincronização inicial é dominada por leituras e escritas aleatórias no banco de dados de UTXOs, então o mesmo trabalho em um disco lento leva dias em vez de horas.
  • A banda é irrelevante depois que você está sincronizado, mas a primeira sincronização baixa a cadeia inteira. Um plano com contagem de tráfego é o formato errado para isso.

Na prática isso recai sobre o VPS-8 a $13.99/mo — 4 vCPU EPYC, 8 GB DDR5 ECC e 120 GB de NVMe Gen4 — como o padrão sensato para um nó podado com Lightning, com o VPS-16 a $26.99/mo se você preferir nunca mais pensar no disco. Todo nível de VPS vem com NVMe Gen4 em RAID-10 e transferência ilimitada, então a capacidade é a única variável real. Se você quiser a cadeia sem poda — para re-escanear uma carteira antiga, ou para rodar um servidor Electrum ao lado da loja — esqueça de vez toda a gama de VPS: um servidor dedicado a partir de $64/mo com 2 × 1 TB NVMe é ao mesmo tempo mais barato e bem mais espaçoso que o maior VPS, e a conta só piora com o tempo. Os trade-offs são os mesmos cobertos em rodar um nó completo de Bitcoin, porque é exatamente isso que você está fazendo aqui, com um checkout acoplado em cima.

A poda tem uma consequência que as pessoas descobrem tarde demais: um nó podado não consegue re-escanear a cadeia além dos blocos que ainda guarda. Aponte o BTCPay para uma carteira já existente que já tenha histórico e esses pagamentos mais antigos simplesmente não serão encontrados. Comece a loja com uma conta nova, ou rode o nó sem poda.

Passo a passo: de uma VPS nova a um checkout no ar

  1. 01Implante a VPS e blinde-a primeiroUma máquina Debian ou Ubuntu, SSH só por chave, firewall que nega tudo por padrão — antes de qualquer coisa de valor entrar nela. A versão em ordem desse checklist é um guia à parte.
  2. 02Aponte um domínio para o servidor e abra as portas 80 e 443O BTCPay emite seu próprio certificado na primeira inicialização, o que só funciona se o hostname já resolver para a máquina e as duas portas estiverem alcançáveis. Inverter essa ordem é, disparado, a causa mais comum de instalação malsucedida.
  3. 03Clone a implantação Docker oficialO projeto distribui uma configuração de containers com as decisões já tomadas. Use-a em vez de montar as peças na mão — é contra ela que o caminho de atualização é testado.
  4. 04Decida suas opções antes da primeira execuçãoRede, hostname, implementação de Lightning e preset de armazenamento são variáveis de ambiente lidas uma única vez na configuração. Mudar o nível de poda depois não sai de graça, então decida agora.
  5. 05Rode o script de configuração e deixe sincronizarTudo sobe em containers e o Bitcoin Core começa seu download inicial de blocos. Essa é a parte longa — várias horas em NVMe — e a única etapa que você não pode apressar.
  6. 06Registre a conta de administrador imediatamenteA primeira conta cadastrada se torna a administradora. Faça isso no instante em que a interface responder, não na manhã seguinte.
  7. 07Anexe uma carteira à sua lojaCrie uma loja e depois conecte uma carteira importando uma chave pública estendida de uma carteira de hardware ou de uma conta dedicada no seu próprio software. O BTCPay observa os endereços; ele nunca assina nada.
  8. 08Teste com um pagamento real e só depois conecte a interfaceEnvie um valor pequeno para você mesmo e confirme que a fatura é liquidada. Só então conecte a tela de ponto de venda, o plugin da loja ou a API que o seu site vai realmente chamar.
Conecte a carteira com uma chave pública estendida, nunca com uma seed phrase. Um xpub deixa o BTCPay derivar endereços e detectar pagamentos; uma seed transformaria uma aplicação web voltada para o público em uma carteira quente guardando tudo o que você já recebeu. Todo o modelo de segurança do lado on-chain se apoia nessa única escolha.

Lightning: vale a pena, e o que isso realmente custa

Pagamentos on-chain funcionam em qualquer lugar e custam o que quer que o mempool esteja cobrando naquele dia, o que torna qualquer coisa abaixo de alguns dólares estranha e às vezes absurda. O Lightning resolve isso, e o BTCPay sobe um nó para você na mesma implantação. Para pagamentos pequenos ou frequentes, é a resposta certa. Também é um compromisso operacional de um tipo diferente do de um nó de Bitcoin, e vale a pena conhecer as diferenças antes de ativá-lo.

  • Você precisa de liquidez de entrada antes de conseguir ser pago. Abrir seu próprio canal te dá capacidade para gastar, não para receber. Até que alguém abra um canal na sua direção ou você adquira capacidade de entrada, seu nó não consegue aceitar nada.
  • O saldo é quente por design. Os fundos dos canais vivem em uma carteira no servidor, online porque precisam estar. Mantenha ali só o capital de giro e varra o restante para on-chain.
  • O estado dos canais não se salva copiando arquivos. Restaurar um snapshot antigo de um nó Lightning pode custar exatamente os canais que ele descreve. Use o mecanismo de backup da própria implementação e entenda o que ele de fato restaura.
  • O downtime custa mais caro aqui do que on-chain. Um nó offline não consegue rotear nem receber, e um estado desatualizado que volta a ficar online pode ser penalizado.
  • Os canais têm custos on-chain nas duas pontas. Abrir e fechar são transações, então o hábito de manter muitos canais pequenos sai caro silenciosamente.
  • Seu nó fica visível se você deixar. Um nó anunciado publicamente transmite seu alias e seu endereço de rede para todo mundo, o que coloca seu servidor em um mapa que qualquer um pode ler.

Um meio-termo sensato é usar Lightning com canais não anunciados — você consegue ser pago sem publicar sua infraestrutura — e on-chain como padrão para qualquer coisa grande. Se você quiser que o nó seja alcançável sem ser atribuível, rode-o sobre o Tor, o mesmo raciocínio que coloca um nó de Bitcoin atrás de um serviço onion em vez de um IP público.

Os vazamentos de identidade que uma instalação padrão deixa no lugar

Esta é a seção que importa se você escolheu o BTCPay especificamente para escapar de um processador que sabia quem você era. O software remove esse processador com perfeição. Ele não remove sozinho tudo o mais que liga o checkout a uma pessoa — e a maioria dessas coisas vem de etapas que parecem não ter relação nenhuma com pagamentos.

  • O domínio. Um registrador guarda sua identidade mesmo quando o WHOIS público está redigido, e precisa de um endereço válido para manter o nome ativo. O hostname é, disparado, a forma mais comum de rastrear um checkout auto-hospedado até o dono.
  • Transparência de certificados. No momento em que um certificado é emitido, o hostname exato é publicado em logs públicos que qualquer um pode pesquisar. Um subdomínio que você imaginava ser privado — pay.algumacoisa, btcpay.algumacoisa — é anunciado para o mundo inteiro, com um timestamp junto.
  • A hospedagem. Se o servidor foi comprado com um cartão no seu nome legal, a máquina está no seu nome legal, não importa o que rode nela. Isso é decidido no cadastro, bem antes da primeira fatura.
  • A chave pública estendida. Entregar um xpub ao BTCPay permite que ele observe cada endereço que essa chave deriva, incluindo saldos e histórico que você nunca pretendeu expor a uma aplicação web. Use uma conta dedicada para a loja, nunca o xpub da sua carteira principal.
  • O nó Lightning. Um nó anunciado publica um alias e um endereço. Um alias com a sua marca, em um IP que também serve o seu checkout, liga os dois permanentemente em um grafo público.
  • Chamadas de saída. Provedores de cotação, plugins e integrações de notificação fazem chamadas para fora a partir da máquina, e as notificações por e-mail passam pela conta SMTP que você configurou. Cada um desses é um terceiro que enxerga o seu servidor.
  • O caminho do repasse. As moedas que saem da loja em direção a uma conta verificada de exchange chegam lá com o histórico grudado nelas. Esse vazamento vem depois do BTCPay na cadeia, e é o que mais costuma desfazer todo o cuidado tomado antes dele.
A forma útil de pensar nisso é que o BTCPay remove o intermediário do pagamento, não do resto da stack. Um checkout auto-hospedado é tão privado quanto a coisa menos privada de que ele depende — o domínio, a hospedagem, e para onde o dinheiro vai depois.

Fechar essas brechas é trabalho comum, não algo exótico. Escolha um registrador que aceite cripto e colete o mínimo possível, e forneça a ele um endereço que não esteja ligado à sua identidade. Coloque a máquina em uma hospedagem que nunca perguntou quem você é e pague por ela a partir de um saldo em cripto — o Bitcoin é pseudônimo, não anônimo, então recarregar em Monero é o que fecha o rastro on-chain, se isso importar para você. E acesse a interface de administração por um túnel WireGuard em vez de expor uma tela de login para algo que guarda dinheiro. Cada uma dessas é uma pequena decisão tomada uma única vez; juntas, são a diferença entre "sem processador" e genuinamente privado.

Mantendo tudo no ar depois do lançamento

Um checkout que funciona há um ano é um checkout que ninguém olha há um ano. Uma breve rotina de manutenção evita que isso vire uma queda justo no seu dia mais movimentado.

  • Atualize no ritmo do projeto, não no seu. A implantação tem um caminho de atualização que move versões combinadas de containers juntas; subir peças isoladas na mão é como uma stack funcional vira uma stack quebrada.
  • Faça backup do que não pode ser regenerado: o banco de dados e a configuração da loja, o descritor da carteira, e o backup do Lightning, se você rodar um. A blockchain não é um backup — ela baixa tudo de novo.
  • Restaure uma vez, de propósito, enquanto nada está quebrado. Um backup nunca testado de um sistema de pagamentos é uma hipótese sobre a sua receita.
  • Fique de olho no disco. Um nó podado tem uma pegada estável, mas logs e bancos de dados não têm, e um disco cheio para o nó, o que para as faturas.
  • Mantenha a máquina corrigida e as portas fechadas. Tudo no checklist de blindagem dos primeiros dez minutos se aplica aqui, com bem mais em jogo.

Já aproveite e adicione uma verificação externa na loja. Algo tão simples quanto um monitor batendo no endpoint da fatura de fora conta a você que o checkout caiu antes que um cliente descubra, o que é praticamente toda a diferença prática entre se auto-hospedar e estar inalcançável. E trate a máquina em si do jeito que os primeiros dez minutos em uma VPS nova descrevem, porque o que está em jogo é maior em uma máquina que guarda dinheiro.

Erros que custam dinheiro de verdade

  • Importar uma seed phrase em vez de uma chave pública estendida, transformando uma aplicação web pública em uma carteira quente guardando todo pagamento já recebido.
  • Configurar o DNS depois de rodar o instalador, e depois ficar se perguntando por que o certificado nunca foi emitido e o site não carrega.
  • Escolher o preset de poda mais agressivo, e depois tentar anexar uma carteira com anos de histórico que o nó não consegue mais re-escanear.
  • Tratar o saldo do Lightning como poupança em vez de capital de giro que por acaso vive online.
  • Fazer backup de um nó Lightning copiando seu diretório de dados e supor que isso é um caminho de restauração válido.
  • Comprar um plano dimensionado para a aplicação web e ficar sem disco no meio da sincronização inicial.
  • Deixar a interface de administração aberta para a internet inteira, atrás de uma senha reaproveitada de outro lugar.
  • Registrar o domínio e alugar o servidor no seu próprio nome, depois de acertar tudo o mais.

O BTCPay é um dos poucos softwares que elimina um intermediário por completo, em vez de trocá-lo por um mais simpático. A instalação é uma tarde e a sincronização é uma noite. O que sobra é um checkout que aceita Bitcoin e Lightning, não cobra nada, não custodia nada e não responde a ninguém — rodando em uma máquina que você pode pagar com o mesmo saldo que ela recebe. Dimensione o disco para o nó, mantenha a seed fora do servidor, e coloque a máquina em algum lugar que nunca perguntou o seu nome.

Pronto para experimentar?Implante VPS Offshore a partir de $3.99/mês — sem KYC, pago em cripto. Começar