BTCPay Server auto-hospedado em um VPS: aceite Bitcoin e Lightning sem processador

O que o BTCPay Server realmente é, e o que ele substitui

BTCPay Server não é uma carteira, e não é uma empresa de pagamentos. É a camada de software que fica entre o seu site e o seu próprio nó Bitcoin, e faz o trabalho chato e necessário que um processador normalmente faz por você: gera um endereço novo ou uma fatura Lightning por pedido, cota um valor em moeda fiduciária a uma taxa que trava durante toda a vida da fatura, observa a cadeia à espera do pagamento, decide quando o pagamento conta como liquidado, e avisa a sua loja. O dinheiro nunca passa pela conta de ninguém a caminho de você, porque não existe conta nenhuma — os endereços pertencem a uma carteira que você controla, e o software está apenas observando-os.

Essa única diferença arquitetural é o motivo inteiro para rodar isso. Um processador hospedado é uma empresa com um departamento de compliance, um banco, e um documento de termos de serviço que reserva o direito de reter a sua liquidação enquanto revisa você. Ele vai pedir documentos de identidade, porque está movendo dinheiro em seu nome e o próprio regulador dele exige que saiba de quem é o dinheiro que está movendo. Auto-hospedar remove o intermediário em vez de negociar com ele: não existe onboarding, não existe revisão mensal de volume, não existe cronograma de liquidação, e não existe nada para um terceiro congelar, porque em nenhum momento um terceiro detém os fundos.

O que você ganha em troca do trabalho é um checkout genuinamente completo. Faturas com validade e uma taxa de câmbio travada. On-chain e Lightning na mesma fatura, para que um cliente pagando dois dólares não seja cobrado uma taxa de rede de três dólares. Uma página de ponto de venda, um botão de doação, uma página de financiamento coletivo, um botão de pagamento que você pode colar em qualquer HTML. Plugins para as plataformas de loja mais comuns, e uma API REST completa, caso a sua loja seja algo que você mesmo escreveu. Reembolsos, pull payments, repasses. Payjoin, se você se importa em quebrar a heurística de propriedade comum das entradas do lado de quem recebe.

Vale a pena ser preciso sobre o que não está incluído, porque a maior parte da decepção com pagamentos auto-hospedados vem de esperar um produto onde existe apenas um protocolo. Ninguém converte o seu Bitcoin para euros e transfere para um banco; se você precisa disso, ainda precisa de uma exchange, e a exchange ainda vai perguntar quem você é. Ninguém subscreve chargebacks, ainda que não haja nenhum para subscrever. Ninguém atende o telefone às duas da manhã quando o nó para de acompanhar a cadeia — isso agora é trabalho seu, e é a parte deste guia que as pessoas pulam.

A máquina: do que ela realmente precisa, e onde o plano barato para de dar conta

A aplicação é pequena. O stack por baixo dela não é. Uma implantação padrão roda o Bitcoin Core, um indexador de endereços chamado NBXplorer, um banco de dados PostgreSQL, a aplicação web do BTCPay, um reverse proxy que cuida dos certificados e — se você ativar — um nó Lightning, cada um no seu próprio container. A aplicação web ficaria feliz em um raspberry pi. O Bitcoin Core não ficaria.

Memória é a primeira coisa em que as pessoas economizam demais. Dois gigabytes tecnicamente sobem o stack e vão passar a sincronização inicial fazendo swap, o que em um NVMe compartilhado é uma boa forma de transformar um dia em três. Quatro gigabytes são um piso sensato só para on-chain. Oito é o piso realista quando o Lightning entra em cena, porque agora você está rodando um segundo daemon que mantém o seu próprio banco de dados e a sua própria visão do grafo, e porque o bitcoind tem um desempenho muito melhor durante o download inicial quando você consegue dar a ele um dbcache grande em vez do padrão conservador. As notas de reduce-memory do Bitcoin Core são a referência para saber quais parâmetros trocam RAM por tempo.

Disco é a segunda coisa, e é ela que decide o seu plano. A cadeia sem poda já passa de setecentos gigabytes e cresce mais ou menos sessenta por ano, então um nó de arquivo não cabe mais em nenhum nível de VPS que vendemos, e pertence a uma máquina dedicada, onde um par espelhado ainda deixa você com um terabyte sobrando. A poda muda isso completamente — o nó mantém uma janela móvel dos blocos recentes e descarta o resto, e para um endpoint de pagamento isso não é nenhum tipo de concessão, porque um lojista nunca precisa servir blocos históricos para ninguém. Some o banco de dados do indexador, o PostgreSQL, as imagens e volumes Docker, o armazenamento próprio do nó Lightning, e os logs, e uma implantação podada cabe confortavelmente em uma máquina da classe de cem gigabytes, com espaço para crescer.

CPU importa basicamente por uma semana da sua vida. A validação de assinaturas durante o download inicial dos blocos é a coisa mais pesada que este servidor jamais vai fazer; depois disso, verificar um bloco a cada dez minutos e responder a um punhado de solicitações de fatura fica perto do ócio. Compre núcleos para a sincronização, não para o regime permanente — ou compre o plano menor e aceite que a sincronização vai demorar mais, o que é uma troca perfeitamente razoável se você não está com pressa.

A poda economiza disco, não tempo — e a sincronização é o gargalo

O mal-entendido mais comum sobre rodar um nó é achar que a poda deixa isso mais rápido. Não deixa. Um nó podado baixa todo bloco a partir do bloco gênese e valida toda assinatura em cada um deles, exatamente como um nó de arquivo; a única diferença é que, assim que um bloco é validado e não é mais necessário, ele é apagado em vez de mantido. Você economiza disco. Você não economiza nada em banda e nada em tempo. Quem espera que um nó podado fique pronto em uma hora vai passar essa hora convencido de que algo está quebrado.

Quanto tempo isso realmente leva depende quase inteiramente de quanto cache você deu a ele e de quão rápido é o disco. Em NVMe com vários gigabytes de dbcache e quatro núcleos não compartilhados, um dia é uma expectativa razoável. Em um plano pequeno com o cache padrão e um vizinho barulhento, dois ou três dias é normal, e o processo passa a maior parte desse tempo escrevendo o conjunto UTXO em disco repetidas vezes, porque não consegue mantê-lo em memória. Este é o único momento em que um plano temporariamente maior vale dinheiro de verdade: suba de plano para a sincronização, desça de novo depois. Cobrança mensal sem contrato é exatamente o que torna essa manobra barata.

Depois, com a cadeia sincronizada, existe uma segunda espera que quase ninguém planeja. Quando você conecta uma carteira que já tem histórico — uma chave pública estendida de uma hardware wallet que você usa há um ano — o indexador precisa varrer a cadeia atrás de endereços derivados dela. Em um nó podado, essa varredura é limitada pelo que ainda está em disco, e é por isso que a ordem da instalação importa: aponte a carteira para o nó antes de os blocos antigos serem descartados, se você precisa que transações históricas apareçam, ou aceite que a loja começa do zero hoje, e trate isso como o começo limpo que normalmente é.

A regra prática de cronograma é que a máquina precisa estar em serviço e sincronizando bem antes de a loja precisar dela. Provisione-a, inicie o download, e use o dia de espera para fazer as partes que não dependem da cadeia: DNS, certificados, o plugin da loja, a carteira, a rotina de backup. Se você deixar o nó por último, vai descobrir que se comprometeu com uma data de lançamento amarrada a um processo que ninguém consegue acelerar.

Chaves: a decisão de arquitetura que você toma uma única vez

A pergunta que determina o quão ruim o seu pior dia pode ser é simples: o servidor consegue gastar o dinheiro? Para pagamentos on-chain, a resposta deveria ser não, e o BTCPay foi projetado para deixar você dizer não. Você importa uma chave pública estendida — um xpub, ou seus equivalentes modernos — derivada de uma hardware wallet ou de um assinador offline. O servidor deriva um endereço de recebimento novo por fatura a partir dessa chave, observa a cadeia à espera de pagamentos para esses endereços, e os reporta. Ele não consegue construir um gasto válido, porque nunca viu uma chave privada. Um comprometimento total da máquina então custa a você a máquina e os dados de pedidos dos seus clientes, o que é ruim, mas não custa a você o dinheiro recebido.

A alternativa — deixar o BTCPay gerar e manter uma carteira quente por conveniência — existe, ocasionalmente é a decisão certa para volumes bem pequenos, e deveria ser uma decisão deliberada, e não algo que aconteceu porque era o botão padrão. Se você optar por ela, trate o saldo naquele servidor como trataria o caixa de uma loja física: esvazie-o em um cronograma, mantenha só o que o comércio de um dia precisa, e entenda que a seed existe em um disco dentro de um datacenter.

O Lightning é a exceção que não dá para evitar. Um nó Lightning precisa assinar transações em tempo real para atualizar o estado do canal, então as chaves dele são necessariamente quentes, e não existe um modo apenas de observação que ainda deixe você receber. Isso não é um defeito do BTCPay; é o que o protocolo exige. A resposta correta é dimensionar o saldo Lightning para o trabalho — entrada suficiente para receber um dia ou uma semana de pedidos, não a sua tesouraria inteira — e mover os recebimentos acumulados para armazenamento frio regularmente, a mesma disciplina que qualquer loja aplica ao caixa.

Mais uma coisa pertence a essa decisão, porque é a parte que as pessoas deixam para depois do incidente: escreva onde a seed está, de um jeito que o seu sucessor consiga agir a partir disso, e guarde isso em algum lugar que não seja o servidor nem o mesmo prédio do servidor. A criptografia de disco completo na VPS protege o disco em repouso contra uma cópia offline; ela não faz nada por uma máquina em funcionamento, e definitivamente não ajuda se a única cópia da sua seed estava nela.

Lightning é um problema de liquidez disfarçado de software

Instalar um nó Lightning é fácil. Receber o primeiro pagamento nele não é, e o motivo pega quase todo mundo de surpresa. Um canal Lightning é um saldo de dois lados: quando você abre um canal e o financia, toda a capacidade fica do seu lado, o que significa que você consegue pagar outras pessoas, mas ninguém consegue pagar você. Receber exige capacidade de entrada — fundos sentados do outro lado de um canal, prontos para se mover na sua direção. Um nó recém-instalado com três canais de saída bem financiados ainda assim não consegue aceitar um único satoshi de um cliente, e o checkout simplesmente não vai oferecer o Lightning como opção.

Existem três formas honestas de resolver isso. Você pode comprar capacidade de entrada de um provedor de liquidez, que é a mais rápida e custa uma taxa proporcional ao valor e à duração. Você pode fazer um submarine swap — pagar via Lightning e receber on-chain, o que desloca o seu próprio saldo para o outro lado dos seus canais e converte saída em entrada ao custo da taxa do swap. Ou você pode pedir a um peer bem conectado que abra um canal na sua direção, o que é grátis se você tiver o relacionamento, e lento se não tiver. Seja qual for a sua escolha, orce isso antes do lançamento, e dimensione de acordo com o fluxo de pedidos esperado, em vez de escolher um número redondo.

Canais também precisam de manutenção de um jeito que o on-chain não precisa. A capacidade de entrada é consumida conforme os clientes pagam você: todo pagamento recebido move saldo do lado deles do canal para o seu, então uma loja que só recebe vai esgotar aos poucos a sua capacidade de receber, e vai precisar rebalancear ou fazer um swap de saída. Canais fecham, às vezes unilateralmente, quando um peer desaparece, e um force-close deixa os seus fundos atrás de um time lock por um tempo e custa uma taxa on-chain. Nós precisam estar online para aceitar pagamentos e para vigiar contrapartes trapaceiras. Nada disso é difícil, mas tudo isso é contínuo, e é o motivo pelo qual muitas lojas rodam Lightning para pedidos pequenos e liquidam discretamente tudo acima de um limite on-chain.

A recompensa por esse trabalho todo é real. As taxas on-chain são indiferentes ao tamanho do pagamento, o que torna um pedido de cinco dólares economicamente absurdo quando o mempool está congestionado, e perfeitamente tranquilo quando não está — e você não controla qual dos dois vai ser no dia do seu lançamento. Pagamentos Lightning liquidam em menos de um segundo por uma fração de centavo, independente do congestionamento, e para qualquer coisa precificada como um café, um download, uma recarga de API ou uma assinatura mensal, é a diferença entre um checkout que funciona e um que perde a venda silenciosamente.

O backup que te quebra: nunca faça rollback de um nó Lightning

Esta seção é o motivo para ler o guia, mesmo que você já saiba tudo o mais que está nele. Restaurar um nó Lightning a partir de uma cópia antiga dos seus dados não é um ato neutro, e, nas circunstâncias erradas, destrói os saldos dos seus canais. O instinto comum de administração de sistemas — tirar um snapshot, restaurar o snapshot quando algo quebra — é exatamente o instinto que causa a perda.

O mecanismo é a penalidade por trapaça do protocolo. Toda atualização de canal substitui a anterior, e cada lado entrega ao outro os meios de puni-lo caso ele algum dia publique um estado já substituído. É isso que torna um canal entre duas partes seguro sem precisar de árbitro. Isso também significa que um nó restaurado a partir da cópia de ontem genuinamente acredita que um estado antigo é o atual, e, se ele agir de acordo com essa crença — fazendo um force-close, ou simplesmente sendo solicitado a isso — a contraparte tem o direito de levar o saldo inteiro do canal, e o software dela vai fazer isso automaticamente. Você não pretendia trapacear. O protocolo não consegue distinguir a diferença, e não foi projetado para isso.

Por isso a regra é absoluta e vale a pena escrever na parede: nunca restaure um nó Lightning para um estado anterior. Nem a partir de um snapshot de filesystem, nem de um dump de banco de dados, nem de uma cópia do diretório de dados que você fez semana passada, e nem dos snapshots horários que vêm com o servidor. Snapshots são excelentes para o resto da máquina e perigosos exatamente para este diretório, e o perigo é silencioso — o nó vai iniciar, parecer saudável, e custar dinheiro a você depois.

O que você mantém em vez disso é um backup estático do canal: um arquivo pequeno, atualizado sempre que um canal abre ou fecha, que contém só o suficiente para pedir a cada contraparte que feche cooperativamente e devolva os seus fundos. O LND chama isso de channel.backup e documenta a semântica no seu guia de recuperação; o Core Lightning oferece um equivalente, junto com um plugin que mantém uma cópia replicada continuamente do banco de dados. Restaurar um desses não retoma os seus canais — ele fecha todos à força e recupera o saldo, que é o único resultado correto e seguro depois de uma perda total. Guarde-o fora da máquina, mantenha-o atualizado, e entenda que é uma apólice de seguro, não um botão de retomar.

Para tudo o mais, faça backup normalmente e com generosidade. A implantação do BTCPay vem com seu próprio script de backup, que para o stack, despeja o banco de dados e a configuração de forma consistente, e o inicia de novo; rode-o em um cronograma e copie a saída para outro lugar, idealmente um segundo servidor em uma jurisdição diferente. O banco de dados guarda as suas faturas, lojas, usuários, chaves de API e configurações — não o seu dinheiro, mas todo o seu histórico, que é o que você realmente vai sentir falta.

Onde o servidor fica é parte do stack de pagamento

É fácil pensar em hospedagem como uma commodity por baixo da parte interessante. Para um endpoint de pagamento não é, porque o checkout é o único componente cuja disponibilidade equivale diretamente a receita, e porque um servidor é um objeto físico em uma jurisdição legal, com um provedor que pode ser contatado sobre ele. Quando a sua infraestrutura de pagamento é um processador hospedado, a postura de compliance daquele provedor é a sua postura de compliance. Quando você se auto-hospeda, a postura do seu provedor de hospedagem assume esse papel — e se você se auto-hospedou especificamente para escapar da discricionariedade de uma empresa de pagamentos, seria descuidado entregar essa mesma discricionariedade para a empresa que roda a máquina.

Existem três propriedades sobre as quais vale a pena ser deliberado. A primeira é qual identidade o host detém: uma conta aberta com um endereço de e-mail e paga em criptomoeda não tem nada para entregar e nada para congelar, o mesmo raciocínio que levou você a se auto-hospedar em primeiro lugar. A hospedagem sem KYC explica o que isso significa e o que não significa na prática, incluindo o seu corolário desconfortável — um provedor que nunca soube quem você é não consegue devolver a sua conta se você perder o acesso a ela.

A segunda é jurisdição. Um endpoint de checkout que atende clientes em muitos países fica fisicamente em exatamente um só, e a lei desse único país determina quem pode compelir o provedor, com base em quê, e com que rapidez. As nossas quatro regiões — Islândia, Países Baixos, Romênia e Suíça — diferem de forma significativa nesse aspecto e na latência até diferentes bases de clientes, e escolher uma jurisdição percorre essas escolhas com o devido cuidado. Também existe um ângulo operacional mais mundano: coloque o nó perto dos seus clientes se a latência do checkout importa, e perto da sua outra infraestrutura se não importa.

A terceira é o pagamento da própria hospedagem, que é o elo que a maioria das pessoas deixa aberto. Rodar um checkout anônimo e não custodial em um servidor cobrado em um cartão de crédito no seu próprio nome cria exatamente o vínculo que você montou o resto do stack para evitar. Pagar a máquina em Monero ou Bitcoin fecha esse elo — o mesmo raciocínio, aplicado uma camada abaixo. Isso também significa que a fatura da infraestrutura não pode ser interrompida pelo próprio modelo de risco da bandeira do cartão, um modo de falha que genuinamente já tirou lojas do ar.

Por fim, os requisitos chatos de confiabilidade são mais rígidos aqui do que para um blog. Um nó Lightning que está offline não consegue receber, não consegue vigiar uma contraparte trapaceira, e pode ser fechado à força por peers que não conseguem alcançá-lo. Um nó Bitcoin que fica para trás na cadeia mostra aos clientes faturas que não consegue liquidar. Banda ilimitada importa mais do que parece, porque um nó que realmente participa da rede serve blocos para peers, e um plano medido vai apresentar a você uma fatura que não tem nada a ver com o tráfego da sua loja.

A ordem de instalação que evita uma segunda sincronização

A implantação que todo mundo usa é a distribuição Docker oficial: um repositório que você clona em um servidor novo, um conjunto de variáveis de ambiente que descrevem o que você quer, e um script de configuração que gera um compose file e sobe o stack inteiro. É genuinamente turnkey, e o motivo pelo qual instalações dão errado quase nunca é o script — é fazer as coisas em uma ordem que obriga você a refazer a etapa cara.

Comece com uma máquina limpa e o registro de DNS. O instalador solicita um certificado para o nome de host que você fornecer, e essa solicitação sai para uma autoridade certificadora que vai se conectar de volta ao seu endereço pela porta 80. Se o registro ainda não resolver, ou se as portas estiverem fechadas, o stack sobe sem TLS, e cabe a você descobrir qual das três coisas falhou. Crie o registro A, confirme que ele responde a partir de algum lugar que não seja o seu próprio notebook, abra as portas 80 e 443, e só então rode o instalador.

Decida os fragmentos antes da primeira execução, não depois. O ambiente diz ao gerador quais cadeias habilitar, qual implementação Lightning usar, se vai podar e o quão agressivamente, se vai expor um serviço onion ao lado do host clearnet, e qual reverse proxy configurar. Várias dessas coisas são baratas de mudar depois; as que tocam o nó — habilitar uma cadeia, ligar ou desligar a poda, trocar de implementação Lightning — significam ter que baixar ou reindexar alguma coisa de novo, e baixar alguma coisa de novo é o que custa um dia. Leia a lista de fragmentos uma vez, escolha com cuidado, e então rode.

Enquanto a cadeia baixa, faça o resto. Crie a sua loja e defina a moeda dela, a validade da fatura, e quantas confirmações você quer antes de uma fatura contar como liquidada — uma decisão que vale a pena tomar de propósito, porque aceitar com zero confirmações é rápido e ocasionalmente errado, e seis confirmações é seguro e leva uma hora. Importe a carteira apenas de observação. Instale o plugin da loja e aponte-o para o servidor com uma chave de API com escopo limitado, em vez da conta de administrador. Configure a fonte de cotação. Mande uma fatura de teste para você mesmo, de um valor irrisório, e pague-a, on-chain e via Lightning, a partir de uma carteira que não esteja na mesma máquina — o número de implantações que nunca foram testadas nem uma vez com dinheiro de verdade é maior do que qualquer um gostaria.

Depois, escreva o procedimento de atualização, porque ele existe e é um único comando. A distribuição vem com o seu próprio atualizador, que baixa as imagens novas e reinicia o stack na ordem certa, e um endpoint de pagamento rodando uma versão de um ano atrás está carregando todo bug corrigido desde então. Coloque isso em um calendário, leia as notas de versão antes de rodar, e tire o backup primeiro.

Hardening de uma máquina que guarda dinheiro

O conselho genérico se aplica por completo, e está detalhado no checklist de hardening: chaves em vez de senhas, sem login root via SSH, um firewall com negação por padrão, atualizações de segurança automáticas, e um log que você realmente lê. O que vem a seguir é a parte específica desta máquina, e o tema é que a superfície de ataque de um endpoint de pagamento não tem o mesmo formato da de um servidor web.

Mantenha a interface administrativa fora da internet pública, se puder. O dashboard do BTCPay é o plano de controle do seu dinheiro — ele consegue criar pull payments, trocar carteiras e emitir chaves de API — e não precisa ser alcançável pelo mundo inteiro só porque as páginas de fatura precisam ser. Vincular o caminho de administração atrás de uma VPN ou de um serviço onion, ou atrás de uma allowlist, remove uma categoria inteira de risco ao custo de um passo extra no seu próprio fluxo de trabalho. Um túnel WireGuard até o servidor é a versão menos intrusiva disso.

Trate as chaves de API como a credencial principal, e não como algo pensado depois. Na prática, é assim que a loja fala com o checkout, e é assim que um atacante também falaria. Emita uma chave por integração, restrinja o escopo dela à loja e às permissões que ela realmente precisa, guarde-a na configuração secreta da loja em vez de em um repositório, e rotacione-a quando alguém sair da equipe. Uma chave sem escopo definido em um host web comprometido é funcionalmente o mesmo que entregar o dashboard.

Fique de olho nos dois estados de falha exclusivos deste stack, porque nenhum dos dois parece uma indisponibilidade. Um nó que parou de acompanhar a cadeia vai continuar servindo o site e vai continuar mostrando aos clientes faturas que nunca vão liquidar. Um nó Lightning que perdeu conectividade com os seus peers vai continuar aceitando pedidos on-chain enquanto recusa silenciosamente todo pagamento Lightning. Monitore a altura do bloco contra uma referência pública, monitore o número de canais e o saldo de entrada, e alerte sobre os dois — esse é o monitoramento que ninguém configura até a primeira vez que isso custa um dia de pedidos.

Mantenha a máquina chata em todo o resto. Um endpoint de pagamento é um lugar ruim para também rodar o seu servidor de e-mail, o seu sandbox de desenvolvimento e um servidor de jogo para os seus amigos — não porque o software entra em conflito, mas porque todo serviço adicional é mais uma porta de entrada e mais uma coisa cuja atualização pode derrubar o checkout. Se você quer o resto, um segundo servidor pequeno custa menos do que as taxas de transação que você está evitando.

Monero e as moedas que o BTCPay não fala sozinho

Bitcoin e Lightning são cidadãos de primeira classe no BTCPay, e um punhado de cadeias próximas ao Bitcoin são suportadas diretamente. Tudo o mais chega através do sistema de plugins introduzido na segunda versão major, e vale a pena entender a diferença de maturidade antes de prometer um método de pagamento na sua página de checkout.

Monero é o que as pessoas mais perguntam, e funciona mesmo — através de um plugin apoiado no seu próprio monerod e em um daemon de wallet RPC, rodando ao lado do stack do Bitcoin. O design é igual ao do Bitcoin nos pontos que importam: você roda o nó, você guarda as chaves, o software vigia os pagamentos. O que muda é o custo operacional. É uma segunda blockchain para baixar e manter sincronizada, é um segundo daemon para monitorar e atualizar, e o plugin é mantido pela comunidade em vez de pela equipe principal, o que significa que o ritmo de lançamentos dele é próprio. Se Monero é só um bônus interessante, pese isso com honestidade; se privacidade no ponto de venda é o motivo inteiro pelo qual os seus clientes vieram, vale a pena o trabalho, e a comparação entre as duas cadeias explica o que cada uma realmente esconde.

A regra geral para qualquer cadeia adicional é perguntar quanto ela custa a você quando quebra. Toda cadeia que você habilita é um nó que pode ficar para trás, uma carteira que precisa de backup, uma fonte de cotação que pode ficar desatualizada, e uma conversa de suporte com um cliente cujo pagamento travou. Dois métodos de pagamento bem cuidados vencem seis negligenciados, e um checkout que oferece uma moeda cujo nó está fora de sincronia há uma semana é pior do que um que nunca ofereceu essa moeda.

Também existe um meio-termo legítimo que as pessoas esquecem: você não precisa rodar toda cadeia você mesmo para aceitá-la. Nada impede você de listar um endereço estático para uma cadeia que você liquida manualmente em baixo volume, ou de rodar a segunda cadeia em uma máquina separada, para que o perfil de recursos dela e as suas indisponibilidades fiquem isoladas do checkout que realmente importa. Auto-hospedar não é um compromisso tudo ou nada, e as configurações pragmáticas normalmente têm uma cadeia bem-feita e um fallback manual para o resto.

Quanto custa, contra quanto um processador cobra

A conta é incomumente fácil de fazer, porque um checkout auto-hospedado tem um custo fixo e nenhum percentual. Um nó Bitcoin podado com Lightning cabe em um plano na casa de poucas dezenas de dólares por mês; uma loja mais movimentada que quer folga fica um ou dois níveis acima disso. Pagamentos on-chain custam a taxa de rede, que o cliente paga, e pagamentos Lightning custam uma taxa de roteamento medida em frações de centavo. Não existe corte por transação, não existe mínimo mensal, não existe atraso de liquidação e não existe nível por volume.

Em comparação, um processador de cripto hospedado normalmente fica com cerca de um por cento de cada transação, e um processador de cartão fica com aproximadamente dois e meio a três por cento mais um valor fixo por transação. Com mil dólares de faturamento por mês, um por cento são dez dólares — genuinamente comparável ao servidor, e auto-hospedar é um empate que você faria por princípio, não por economia. Com vinte mil por mês, o processador fica com duzentos dólares, e o servidor continua custando os mesmos vinte, e a decisão se toma sozinha. O ponto de virada para a maioria das lojas fica em algum lugar na casa dos poucos milhares, e tudo acima disso é margem.

O custo que não aparece na fatura é a sua atenção. Chame de uma tarde para instalar, um dia esperando a cadeia, e algo como uma hora por mês depois disso, para atualizações, backups e uma olhada no monitoramento — mais uma tarde desagradável por ano, quando algo quebra na pior hora. Se a sua hora de trabalho torna isso mais caro do que as taxas, a resposta honesta é pagar as taxas. Ninguém deveria auto-hospedar um stack de pagamento por uma questão de ideologia enquanto o próprio negócio espera.

Uma ressalva pertence ao lado dessa tabela, porque omiti-la seria desonesto. A comparação assume que você está satisfeito em manter o que recebe. Se todo pagamento precisa virar fiat em uma conta bancária no mesmo dia, você reintroduziu uma exchange no fluxo, e a exchange tem as suas próprias taxas, os seus próprios requisitos de identidade e a sua própria discricionariedade. Auto-hospedar o checkout remove o processador. Não remove o banco, e as lojas que mais aproveitam isso são as que mantêm ao menos parte do que recebem na moeda em que foram pagas.

Quando você não deveria auto-hospedar isso

Existem situações em que a resposta certa é não fazer nada disso, e um guia que nunca diz isso está vendendo alguma coisa. Se o seu volume mensal é pequeno o bastante para que o percentual de um processador seja menor do que o custo do servidor, a conta não fecha — comece hospedado, e migre quando os números se cruzarem. Se ninguém na sua equipe está confortável em um prompt de shell, não faça do checkout o lugar onde essa habilidade vai ser adquirida; um endpoint de pagamento que você não consegue debugar é pior do que uma taxa que te incomoda.

Se você genuinamente precisa de liquidação em fiat no mesmo dia em uma conta bancária, auto-hospedar resolve a metade errada do seu problema. O processador que você está tentando remover também é a coisa que faz a conversão e a transferência bancária, e substituí-lo significa acrescentar uma exchange que vai pedir exatamente os documentos de identidade que você estava evitando. Isso ainda pode valer a pena pelas garantias de custódia, mas tenha os olhos abertos para o fato de que o KYC se mudou de lugar, em vez de desaparecer.

E se a sua carga de trabalho é irregular de um jeito que torna a indisponibilidade catastrófica — um lançamento, um drop, uma campanha de arrecadação com prazo — pense com cuidado antes de fazer a sua primeira implantação auto-hospedada às vésperas desse prazo. Rode-a em paralelo com outra coisa por um ciclo, aceite pagamentos reais por ela em baixo volume, e deixe que ela prove o seu valor antes de carregar o dia que realmente importa. Migrar depois é um problema resolvido; descobrir os modos de falha dela durante a sua hora mais movimentada não é.

Para todos os outros — uma loja com faturamento estável, um operador tranquilo com um terminal, um negócio que prefere guardar as próprias chaves a discutir com um departamento de risco — esta é uma das poucas peças de infraestrutura auto-hospedada que se paga em dinheiro, não em princípio. O stack é maduro, a implantação é um script, os modos de falha são conhecidos e estão documentados, e o único genuinamente implacável é a regra de rollback do Lightning lá no topo desta página. Acerte essa e o resto é administração de sistemas comum.

Se você quiser começar, um servidor leva cerca de um minuto para ser provisionado, e a cadeia vai estar ocupada sincronizando enquanto você lê o resto da documentação. Escolha um plano com oito gigabytes de memória se o Lightning estiver nos seus planos, coloque-o na jurisdição em que você realmente gostaria que ele estivesse quando alguém fizer perguntas incômodas, e pague por ele com a mesma moeda que você está prestes a começar a aceitar.