Para aceitar pagamentos em criptomoedas no WHMCS você instala um módulo de gateway, cola uma chave de API, aponta para uma URL de webhook no seu servidor e marca a fatura como paga quando um webhook assinado chega. Essa parte é mecânica. A parte que vale a pena ler é tudo que é específico de hospedagem ao redor disso: seus compradores são incomumente nativos em criptomoedas, sua cobrança se repete a cada ciclo e estornos são um risco real de negócio. A criptomoeda muda os três — dois a seu favor e um que custa um processo manual que você deve decidir antes de ativá-lo.
Hospedagem não é uma loja normal
A maioria dos conselhos sobre "aceitar criptomoedas" é escrita para alguém que vende camisetas, onde a criptomoeda é um recurso opcional que talvez 1% dos compradores utilize. A hospedagem é diferente. As pessoas que compram um VPS, uma caixa dedicada ou um domínio são desenvolvedores, administradores de sistemas, empresas com mentalidade offshore e compradores em países onde um pagamento com cartão para uma empresa de hospedagem estrangeira é recusado pelo emissor sem motivo declarado. Para uma parte significativa deles, a criptomoeda não é uma conveniência — é a diferença entre uma venda e nenhuma venda.
Você pode ver isso na fila de suporte. Ninguém envia um e-mail para uma loja de roupas perguntando se aceitam USDT; as empresas de hospedagem recebem esse e-mail constantemente, e cada remetente já decidiu comprar.
A parte honesta: não há cartão armazenado
Aqui é onde você precisa de precisão em vez de marketing. A hospedagem é cobrança recorrente: o WHMCS existe para emitir uma fatura todo mês ou ano e coletar sem que o cliente pense nisso. Um gateway de cartão faz isso armazenando um token e retirando fundos na data de vencimento.
Um gateway de criptomoeda não custodial não pode. Não há token para armazenar e nenhuma autorização permanente para retirar da carteira de alguém — os fundos se movem apenas quando o titular da carteira assina uma transação. Portanto, "cobrança recorrente de criptomoeda" é honestamente descrita como uma fatura mais um pedido de pagamento que o cliente paga a cada ciclo, não uma cobrança automática silenciosa. O modelo completo, incluindo as abordagens de contrato inteligente e por que elas não se encaixam na maioria das cobranças, está em assinaturas de criptomoeda e pagamentos recorrentes explicados.
Tornando renovações indolores de qualquer maneira
A lacuna entre "cobrança automática" e "o cliente paga a cada ciclo" é um problema de UX, e é solucionável. O que funciona:
- Fature com bastante antecedência à data de vencimento.O WHMCS já gera faturas antecipadamente. Dê aos pagadores de criptomoeda uma margem de manobra maior do que um cliente de cartão — alguém movendo fundos de uma exchange precisa de dias, não minutos.
- Use uma janela de fatura generosa.Uma fatura de criptomoeda é cotada a uma taxa que se mantém por um curto período, então gere o pedido de pagamento quando o cliente estiver pronto para pagar, e não semanas antes.
- Deixe as pessoas pagarem antecipadamente.Clientes nativos de criptomoeda ficarão felizes em pagar um ano adiantado para não ter que pensar nisso, e cada ano pré-pago é uma renovação que você nunca persegue.
- Lembretes são seu auto-cobrança.Notificações de atraso, um link de pagamento claro, uma data de suspensão visível — o mesmo esforço que você usa para clientes de transferência bancária.
- Não suspenda no primeiro dia perdido.Um atraso na confirmação ou uma retirada de troca pendente não é um caloteiro. Inclua um período de carência.
Estornos: o problema mais caro da hospedagem
A hospedagem é um ímã de estornos e todos na indústria sabem por quê. Um cartão roubado compra um servidor, o servidor é usado para o que foi comprado — spam, varredura, mineração, pior — e então o verdadeiro titular do cartão reverte a cobrança. Você perde o dinheiro, os recursos que ele consumiu e a taxa, e sua taxa de estorno se aproxima do limite onde sua conta de comerciante recebe uma conversa que você não quer. A fraude não é incidental ao produto; o produtoéa ferramenta de fraude.
Os pagamentos em criptomoedas são finais. Uma vez que uma transação tenha as confirmações que você requer, não há emissor, não há janela de disputa e não há reversão. Ninguém solicita estorno de um servidor depois de usá-lo por três semanas. Para um negócio de hospedagem, esse é frequentemente o único argumento mais forte na coluna, e a economia está coberta em aceitar pagamentos sem uma conta de comerciante ou estornos.
A fraude não desaparece, para ser claro. Clientes abusivos ainda se inscrevem — eles apenas pagam com seu próprio dinheiro e não podem recuperá-lo. Seu tratamento de abusos permanece onde estava.
A troca, declarada claramente
A finalização corta para os dois lados. Porque ninguém pode reverter um pagamento para você, vocêé o único que pode devolver dinheiro — como um pagamento de saída, manualmente. Não há um botão de "reembolso" que desfaça uma transação liquidada. Isso significa duas decisões antes do lançamento:
- Cancelamentos proporcionais.Decida a política primeiro e escreva-a em seus Termos de Serviço. Muitos provedores de hospedagem emitem crédito de conta em vez de um reembolso on-chain, o que é mais limpo e mantém o cliente. Se você fizer reembolso on-chain, a taxa da rede será descontada e o preço terá mudado — reembolse o valor em fiat que você concordou ou o valor exato recebido, mas diga qual por escrito.
- Quem assina o pagamento de saída.Em uma configuração não custodial, os endereços de recebimento derivam apenas de material de chave pública e as chaves privadas nunca tocam o servidor, então reembolsos e pagamentos são assinados offline por um humano. Isso é um recurso — uma caixa de cobrança comprometida não pode drenar seus ganhos — mas reembolsos são um ato deliberado, não uma chamada de API. Seu saldo interno é onde você vê o que coletou e o move para fora; preços é 0% para aceitar, com taxas apenas quando o dinheiro sai: 1,5% em pagamentos, transferências e retiradas no plano Gratuito, além da taxa de rede da moeda em um pagamento ou uma retirada (retirada mínima de $50).
Provisionamento: confie no webhook, nunca no redirecionamento
Este é o detalhe que separa uma configuração funcional de uma explorável. Quando um cliente termina de pagar, seu navegador é redirecionado de volta para sua instalação do WHMCS. Esse redirecionamento não é prova de pagamento. É apenas uma URL, e qualquer um pode acessar sua URL de retorno.
Disposição sobre o webhook assinado e nada mais. A Payora assina cada callback com HMAC-SHA256 sobre a carga útil, com uma janela de timestamp e uma chave de idempotência. Seu endpoint verifica a assinatura, checa se o timestamp é recente, verifica se já processou essa chave e só então marca a fatura como paga e permite que a automação seja acionada. O docs cobre o esquema de assinatura e o SDK PHP de um arquivo que o gerencia.
A idempotência é mais importante aqui do que em uma loja: um webhook processado duas vezes em um pedido de hospedagem não apenas dobra o crédito de uma fatura, mas pode acionar uma segunda execução de provisionamento. Foque na chave de idempotência, não em "já vi este id de pedido".
Quais redes habilitar para provisionamento instantâneo
Se seu produto é provisionado instantaneamente, o tempo de confirmação é a experiência de checkout. Um cliente clicando em "pedir VPS" às 2 da manhã espera uma senha de root em minutos, e o tempo de bloco do Bitcoin não é uma boa opção — esperar por confirmações para um VPS de $6 é um ticket de suporte em formação. Prefira redes rápidas e baratas por padrão e deixe o Bitcoin como uma opção em vez de ser a principal:
| Rede | Cabe | Nota |
|---|---|---|
| TON (Gram) | Provisionamento instantâneo | Segundos para a finalização, taxas baixas |
| Tron | Públicos com alta concentração de USDT | O trilho padrão de USDT para grande parte do mundo |
| Solana | Provisionamento instantâneo | Rápido e barato |
| Bitcoin | Pedidos maiores e não urgentes | Planos anuais, servidores dedicados, depósitos |
As stablecoins merecem uma menção especial aqui: USDT e USDC precificam seu plano de $6/mês em $6, sem discussão sobre qual taxa se aplica. Quantas confirmações cada rede realmente precisa, e por que a resposta depende do valor do pedido, é abordado em quantas confirmações tornam um pagamento em cripto seguro.
Configure o módulo Payora para aceitar pagamentos em cripto no WHMCS
O módulo de gateway do WHMCS é uma das integrações gratuitas que publicamos em módulos, ao lado de 21 outros. É a maneira mais rápida de aceitar pagamentos em cripto no WHMCS sem escrever código. Em um nível alto:
- Instale o módulo de gateway na sua instalação do WHMCS e ative-o entre seus gateways de pagamento.
- Crie uma conta gratuita em registrar e cole a chave da API nas configurações do módulo.
- Defina a URL do webhook para o endpoint de callback do módulo para que as notificações assinadas cheguem até ele.
- Ative as moedas e redes que deseja oferecer e configure seu material de chave de recebimento.
- Faça um pequeno pedido real em uma rede barata e confirme que a fatura foi marcada como Paga no webhook.
A partir daí, o fluxo é o padrão descrito em aceitar pagamentos: a fatura contém seu id de pedido e valor, o cliente escolhe uma moeda no checkout hospedado, a Payora monitora a cadeia até a finalização daquela moeda, e seu servidor recebe o callback assinado. Se você preferir pular o módulo — muitos hosts executam um WHMCS fortemente personalizado — a API REST em JSON simples faz o mesmo trabalho.
Comece com uma rede rápida e uma stablecoin, observe o que os clientes realmente escolhem e adicione a partir daí.Crie uma conta, pegue uma chave de API e faça um pedido real de $5 através do seu próprio checkout antes de anunciá-lo.



Comments