A OBV, de Oblivion, é uma comunidade no Discord. Como em qualquer servidor que cresce, chega um ponto em que boa vontade e meia dúzia de bots genéricos não dão mais conta: convites precisam ser contados com critério, sorteios precisam ser justos, a moderação precisa de registro, e quem quer apoiar a comunidade financeiramente precisa de um caminho simples e confiável para isso.
Este texto conta como construímos o bot que hoje cuida dessas rotinas, e principalmente por que tomamos certas decisões. A parte mais delicada não foi escrever comandos, foi garantir que dinheiro, cargos e benefícios nunca ficassem fora de sincronia.
O problema: administrar e monetizar sem perder o controle
Administrar um servidor envolve tarefas repetitivas que cansam rápido: dar e tirar cargos, acompanhar quem está em call, abrir e fechar tickets, registrar o que a moderação fez. Monetizar adiciona uma camada mais sensível. Quando alguém paga por um benefício, a expectativa é que ele chegue na hora, dure exatamente o combinado e saia sozinho no fim, sem planilha e sem alguém lembrando de remover cargo manualmente.
Também havia um requisito de confiança. Pagamento pela metade, cobrança duplicada ou VIP entregue sem pagamento confirmado são o tipo de erro que destrói a credibilidade de uma comunidade. O sistema precisava ser chato no melhor sentido: previsível, auditável e difícil de quebrar.
Um bot próprio, em TypeScript e Node.js
Optamos por um bot próprio em TypeScript, rodando em Node.js com a biblioteca discord.js. TypeScript pesou pela segurança na hora de mexer em regras de negócio: quando um tipo muda, o compilador aponta cada lugar que precisa acompanhar. Em um sistema que lida com pagamento, isso evita uma classe inteira de erros bobos.
Cada funcionalidade vive em um módulo próprio: convites, sorteios, logs, cargos automáticos, ranking de voz, proteção contra farm, tickets, cargos por tempo de voz, a loja VIP e as salas temporárias. Os módulos compartilham só o essencial (cliente do Discord, configuração, banco e logger), e um problema em um deles não derruba os outros. Quando um módulo perde uma permissão no servidor, por exemplo, ele pausa e registra o motivo, em vez de falhar em silêncio.
SQLite como fonte da verdade
Todo o estado do bot fica em SQLite, usando o módulo nativo do Node.js. Para um único servidor, ele resolve muito bem: é um arquivo, não depende de outro serviço rodando e aguenta com folga o volume de escrita de uma comunidade.
O schema evolui por migrations numeradas e com checksum. Se alguém tentar subir uma versão antiga do bot sobre um banco mais novo, ele se recusa a iniciar em vez de corromper dados. Várias regras ficam no próprio banco, em constraints e triggers: um pedido de VIP não muda de valor depois de criado, um pedido finalizado não volta a ficar aberto e um registro de pagamento não pode ser apagado. O código pode ter bugs, mas algumas garantias não dependem só dele.
Os planos VIP: Eclipse, Nebula e Astral
A OBV tem três planos, cada um com 30 dias de duração e pagamento único, sem renovação automática. O Eclipse dá acesso ao chat e à call VIP e libera imagens e links no chat geral. O Nebula inclui tudo do Eclipse e uma sala de voz temporária própria. O Astral é o topo da hierarquia, com uma sala de voz mais personalizável.
Quem já tem um plano pode renovar (os dias se somam ao vencimento atual) ou fazer upgrade. No upgrade, o valor é proporcional ao tempo que ainda falta, e o vencimento não muda. A compra pode começar pelo painel no próprio Discord ou pelo site, e as duas portas usam exatamente as mesmas regras, o mesmo cálculo e a mesma trava por membro, o que impede, por exemplo, gerar duas cobranças ao mesmo tempo.
Pix pelo Mercado Pago, e por que a notificação não basta
O pagamento é por Pix, pela API de pedidos do Mercado Pago. O bot cria o pedido com uma chave de idempotência, recebe o QR Code e o código copia e cola e mostra isso só para quem está comprando.
Uma decisão importante: a notificação que o Mercado Pago envia (o webhook) nunca é tratada como prova de pagamento. Ela tem a assinatura conferida, mas serve só como um aviso de que algo mudou. O bot então consulta o pedido diretamente no Mercado Pago e só entrega o VIP se o valor, a moeda e o status baterem com o que foi cotado. Notificações repetidas, fora de ordem ou forjadas não têm efeito, e uma verificação periódica pega qualquer pagamento cuja notificação tenha se perdido.
Um detalhe que aprendemos em produção: o Pix gerado pelo Mercado Pago tem validade mínima de 30 minutos, e no início o nosso pedido interno durava menos que isso. Corrigimos para que o prazo do pedido acompanhe o do Pix, com uma pequena tolerância para a confirmação chegar. Pagamentos confirmados realmente fora do prazo não são ativados automaticamente: vão para uma fila de análise, com alerta privado para o responsável, e são resolvidos por reembolso ou concessão manual registrada.
Entrega automática de cargos e benefícios
Confirmar o pagamento no banco é metade do trabalho. A outra metade é o cargo aparecer no Discord. Cada mudança de assinatura gera, na mesma transação, uma entrada numa fila de sincronização de cargos. Uma rotina separada aplica o cargo certo e tenta de novo se o Discord estiver instável. Quando a assinatura vence, o cargo sai pelo mesmo caminho, sem ninguém precisar lembrar.
Separar as duas coisas deixa o sistema mais simples de raciocinar: o banco diz qual cargo cada membro deveria ter, e o processo de sincronização garante que o Discord reflita isso. Se o bot reiniciar no meio do caminho, a fila continua de onde parou.
Salas de voz temporárias
Membros Nebula e Astral criam a própria sala de voz entrando num canal específico. O bot cria a sala, move a pessoa para dentro e publica um painel de controle no chat da sala, com nome, limite de pessoas, trancar, convidar e bloquear. O Astral tem limites maiores, áudio de melhor qualidade e a opção de ocultar a sala.
Algumas escolhas foram de segurança: o dono da sala nunca recebe permissões de gerenciar canal ou mover membros, porque todas as alterações passam pelo bot, que valida o plano a cada ação. Salas vazias são removidas depois de um tempo de tolerância, e quem perde o plano perde a sala (quem cai de Astral para Nebula mantém a sala, ajustada aos limites do Nebula). Quem entra no canal de criação sem um plano elegível é desconectado e recebe uma mensagem privada explicando o motivo. A primeira versão desconectava em silêncio, o que parecia um bug para quem estava do outro lado.
Comandos administrativos /vip
O comando /vip status mostra para qualquer membro o próprio plano, os benefícios e o vencimento. Os demais subcomandos (consultar, dar, renovar, remover e lista) são exclusivos do dono do servidor, conferido pela identidade que o próprio Discord informa, e não por cargo de administrador. Todas as respostas são privadas.
O /vip dar concede um VIP de presente, sem criar pedido nem cobrança. A regra mais importante aqui é de convivência: um presente nunca substitui uma assinatura comprada, e renovar ou remover só vale para presentes. Se um pagamento já estendeu aquela assinatura, o comando recusa e não altera nada. A remoção pede confirmação, e cada ação fica registrada no histórico.
Anúncios automáticos de compras e presentes
Quando alguém compra um VIP ou recebe um presente, o bot publica um anúncio no chat geral com a foto do membro, o plano e a cor correspondente. Renovações, upgrades e pedidos não pagos não geram anúncio.
O anúncio entra numa fila criada pelo próprio banco, dentro da mesma transação que entrega o VIP. Assim, uma concessão que falha não gera anúncio, e um webhook repetido não gera dois. O envio só acontece depois de o cargo estar aplicado, e uma combinação de trava no banco, identificador único da mensagem no Discord e verificação do canal após uma queda evita publicações duplicadas. Se o pagamento for estornado ou o presente for removido antes do envio, o anúncio é cancelado. E se o Discord falhar, o anúncio espera, mas a entrega do VIP nunca é desfeita.
A integração com o site da Vexor
A página da OBV no site da Vexor mostra os planos e permite comprar com login pelo Discord. O site nunca fala diretamente com o banco do bot. As requisições passam por uma camada intermediária que assina cada chamada com um segredo compartilhado, carimbo de tempo e um número de uso único, e o bot recusa qualquer chamada repetida, antiga ou com o conteúdo alterado.
O site também publica os termos de compra e a política de reembolso, e só libera o checkout quando os dados do vendedor e a data de vigência estão completos. É um detalhe chato, mas evita vender alguma coisa sem as condições estarem publicadas.
Segurança e prevenção de duplicações
Quase todas as operações sensíveis são idempotentes: cada uma tem uma chave, e repetir a mesma operação devolve o mesmo resultado, sem efeito duplicado. Isso vale para pagamentos, concessões manuais e comandos repetidos por um clique duplo ou uma nova tentativa do Discord. As escritas de assinatura só acontecem dentro de transações que conferem quem está agindo e por quê.
Os logs são estruturados e nunca guardam e-mail do pagador, tokens ou dados pessoais. O e-mail usado no Pix é validado e repassado ao Mercado Pago, mas não fica salvo no banco.
Hospedagem, backups e monitoramento
O bot roda num servidor Linux como serviço do sistema, que reinicia sozinho se o processo cair. Existe uma instância de homologação totalmente separada, com outro servidor do Discord, outro banco e credenciais de teste do Mercado Pago. A regra é que nada chegue à produção sem passar por ela.
Cada versão é empacotada com um hash SHA-256 conferido antes da instalação. A instalação prepara o código novo ao lado do atual, não roda se houver um Pix em andamento e faz backup do banco antes de trocar. Depois de iniciar, confere saúde, logs e se pedidos e assinaturas continuam intactos. Se algo der errado, volta sozinha para a versão anterior. O banco tem backup diário cifrado, com cópia fora do servidor e checagem de integridade, e o processo de restauração é coberto por testes.
Para monitorar, o bot expõe um endpoint de saúde e registra eventos estruturados. Situações que pedem uma decisão humana, como um pagamento em análise, chegam ao responsável por mensagem privada, com lembrete diário enquanto não forem resolvidas.
O que aprendemos
Para valer de verdade, uma regra de negócio precisa estar no lugar mais difícil de contornar. As garantias que estão no banco nunca nos surpreenderam. As que dependiam de cada caminho do código lembrar de fazer a coisa certa, às vezes sim.
Também aprendemos a desconfiar de suposições sobre serviços externos. O prazo mínimo do Pix, o cache parcial de membros do Discord (que fazia o bot achar que não tinha permissão num canal onde tinha) e a ordem em que notificações chegam só apareceram em uso real. A homologação com credenciais de teste pegou parte disso. O resto, pegamos com logs claros e testes escritos logo em seguida.
Por fim, a experiência de quem usa importa tanto quanto a correção técnica. Uma recusa sem explicação parece um defeito, mesmo quando é o comportamento certo.
Próximos passos
A base está estável, e os próximos passos são de refinamento, não de reconstrução. Entre o que estamos avaliando: publicar o anúncio de um presente logo depois da entrega do cargo, em vez de esperar o ciclo de manutenção, e deixar as mensagens dos comandos administrativos mais claras sobre o que acontece em seguida. Qualquer mudança passa pelo mesmo caminho de sempre: homologação primeiro, testes, e instalação com rollback pronto.