Bot de vendas fora do ar: o que se perde em 24 horas

A queda aparece de um jeito sempre igual: uma pessoa manda print do Pix no seu privado dizendo que pagou e não recebeu nada, depois outra, e só então você descobre que o bot de vendas ficou fora do ar por algumas horas. A primeira reação é achar que as vendas desse intervalo se perderam. Quase nunca é o caso, e entender o porquê muda o que você faz nos primeiros minutos.

Resposta primeiro: numa queda, a venda não se perde no momento em que acontece. O Pix continua funcionando, e quem já tinha o código paga e o dinheiro fica registrado na sua conta. O que o bot deixa de fazer é transformar esse pagamento em acesso e responder quem chega para comprar, cujo pedido fica esperando na fila. A perda de verdade vem depois, em relógios diferentes: o Telegram guarda as mensagens enviadas ao bot por no máximo 24 horas, a cobrança aberta tem prazo para expirar, e o aviso automático do banco não tem regra de reenvio descrita no padrão do Banco Central. Por isso o tamanho do estrago depende de duas coisas só: quanto tempo a queda durou e se a sua ferramenta sabe reconciliar quando volta.

Bot de vendas fora do ar: o que continua funcionando sem ele

Resposta primeiro: tudo que não passa pelo servidor do bot continua de pé. O grupo ou canal segue existindo, os membros continuam dentro, e o pagamento continua sendo aceito.

O motivo do último item está na definição do próprio arranjo. O Regulamento Pix, anexo da Resolução BCB nº 1/2020, define pagamento instantâneo como a transferência "cujo serviço está disponível durante 24 (vinte e quatro) horas por dia e em todos os dias no ano". O Pix não sabe que o seu bot caiu. Se a cobrança foi gerada antes da queda, ou se o cliente tinha o código na mão, o valor entra. Quem chega depois que o bot caiu é outro caso: sem o bot, ninguém gera cobrança nova, e o clique em comprar fica guardado na fila do Telegram esperando resposta.

O que para são as três tarefas que só o bot executa:

• Liberar acesso a quem pagou, gerando o convite ou aprovando o pedido de entrada.
• Responder a quem clica em comprar, pede o código ou tira dúvida.
• Remover quem venceu e não renovou, o que numa queda longa vira acesso de graça por algumas horas.

Exemplo trabalhado para dimensionar. Uma operação que vende 12 assinaturas por dia a R$ 39,90, distribuídas de forma uniforme, recebe em média um pedido de compra a cada duas horas. Numa queda de 6 horas, cerca de 3 pessoas tentam comprar, somando R$ 119,70. Quem já tinha o código na mão antes da queda paga e fica sem acesso; quem clicou em comprar depois fica sem código, com o pedido parado na fila. Nenhum dos dois casos é venda perdida ainda: o dinheiro de quem pagou não sumiu, e o pedido de quem não conseguiu pagar continua guardado. O que está em risco é a relação com essas 3 pessoas, e isso tem prazo.

Os quatro relógios de uma queda

Resposta primeiro: cada coisa que o bot deixou de processar espera por um tempo diferente, e esses tempos estão escritos em documentação oficial, não em opinião de fornecedor.

O que ficou pendente	Quanto tempo espera	Fonte
Pix pago	Não depende do bot	Regulamento Pix
Mensagens e cliques no bot	Até 24 horas	Bot API
Cobrança aberta, prazo padrão	24 horas da criação	API Pix
Aviso automático do banco	Prazo de cada instituição	API Pix
Bot escrever a quem pediu entrada	5 minutos	Bot API

O pagamento em si não corre contra relógio nenhum; os quatro relógios são as outras linhas. O primeiro é o que mais pesa. A documentação da Bot API diz, na parte sobre recebimento de atualizações, que elas "are stored on the server until the bot receives them either way, but they will not be kept longer than 24 hours". Atualização, aqui, é tudo o que um cliente faz com o bot: o comando de início, o clique no botão de plano, a mensagem pedindo ajuda. A documentação fixa 24 horas como limite máximo, não como prazo garantido: dentro dele, a fila normalmente está lá quando o bot volta; passado ele, o que chegou primeiro começa a ser descartado.

O segundo relógio é da cobrança. Na especificação da API Pix mantida pelo Banco Central, o tempo de vida de uma cobrança imediata é "especificado em segundos a partir da data de criação", com valor padrão de 86.400 segundos, ou seja, 24 horas. A ferramenta pode escolher outro prazo (o exemplo do próprio documento usa 3.600, uma hora), e é por isso que vale perguntar qual ela usa.

O terceiro, o do aviso automático do banco, fica para a seção sobre reconciliação. O quarto é curto e pouco conhecido. Quando alguém pede para entrar num grupo com aprovação, a Bot API diz que o bot pode usar o identificador dessa pessoa "for 5 minutes to send messages until the join request is processed, assuming no other administrator contacted the user". Passados os 5 minutos, ou antes disso se o pedido for processado ou outro administrador falar com a pessoa, o bot perde esse canal de conversa com quem ainda não é membro.

Queda de 20 minutos, de 6 horas e de 30 horas

Resposta primeiro: a mesma falha tem três tamanhos de prejuízo, e a fronteira entre eles é a marca das 24 horas.

Mantendo a operação do exemplo, com 12 vendas por dia e uma venda a cada duas horas em média:

• 20 minutos. O mais provável é nenhum pedido cair no intervalo (a média é um sexto de pedido). Quem clicou em comprar esperou um pouco mais pela resposta, e o bot processa a fila ao voltar. Praticamente invisível, se a ferramenta não descartar nada ao reiniciar.
• 6 horas. Cerca de três pedidos caem no intervalo. As mensagens devem continuar guardadas pelo Telegram, então o bot pode responder e gerar a cobrança ao voltar, se a pessoa ainda quiser comprar. O ponto fraco é quem já tinha o código e pagou durante a queda: se a liberação dependia só do aviso automático do banco e esse aviso se perdeu, essa venda fica parada até alguém conferir o extrato.
• 30 horas. Cerca de quinze pedidos caem no intervalo. Os enviados nas primeiras 6 horas passaram do limite de 24 horas e podem ter sido descartados, então o bot não tem mais o pedido de quem escreveu cedo. As cobranças geradas pouco antes da queda, no prazo padrão, expiraram por volta da 24ª hora, e quem deixou para pagar depois disso encontrou um código morto.

Caso de borda que merece nota: se você vende em Stars, pelo pagamento do próprio Telegram, a queda é mais dura. A Bot API avisa que "The Bot API must receive an answer within 10 seconds after the pre-checkout query was sent", e a documentação de pagamentos em Stars completa que, sem essa resposta no prazo, "the transaction is canceled". Essa é a etapa de confirmação final da compra, e com o bot fora não existe quem responda. No Pix, o dinheiro entra e o acesso atrasa; nesse caso, a compra nem se completa. É a venda perdida, mas também é o único trilho em que ninguém fica com dinheiro pago e sem acesso. A comparação dos dois trilhos está em Telegram Stars ou Pix para vender conteúdo.

Por que o bot voltar não significa que a fila voltou

Resposta primeiro: o Telegram guarda a fila, mas uma configuração de reinício pode jogá-la fora em um segundo, e isso é decisão de quem programou a ferramenta.

A Bot API oferece, ao registrar ou apagar o webhook, o parâmetro drop_pending_updates, descrito como "Pass True to drop all pending updates". No modo de consulta, o parâmetro de deslocamento negativo tem o mesmo efeito para o que ficou para trás: "All previous updates will be forgotten". Existe motivo técnico para usar essas opções (por exemplo, não reprocessar pedidos antigos depois de uma troca de código), e existe o custo: numa queda de 6 horas, apagar a fila é apagar o pedido de quem tentou comprar.

O outro ponto é o webhook do próprio Telegram. Quando o servidor do bot não responde, a documentação diz que o Telegram "will repeat the request and give up after a reasonable amount of attempts". Não há número nem intervalo publicado. Uma leitura prudente é tratar essa insistência como um bônus, e não como garantia.

Passo concreto para saber o que aconteceu na sua queda: a Bot API expõe, nas informações do webhook, os campos pending_update_count ("Number of updates awaiting delivery"), last_error_date e last_error_message. Quem tem acesso técnico ao bot consegue ver, durante a queda ou logo depois da volta, quantas atualizações aguardam entrega, a data do erro mais recente e a mensagem desse erro. Os campos de erro só existem quando o bot usa webhook. Se a ferramenta é de terceiros, peça esses três dados no suporte; a resposta diz muito sobre ela.

A reconciliação que salva quem pagou durante a queda

Resposta primeiro: quem pagou durante a queda só é liberado com segurança se a ferramenta consultar os pagamentos recebidos, em vez de esperar um aviso que talvez não chegue.

A especificação da API Pix deixa claro que o aviso automático não tem garantia de prazo escrita no padrão: "O SLA específico a ser definido no contexto dos acionamento dos callbacks fica a cargo de cada PSP recebedor", embora o mesmo trecho oriente um prazo razoável, já que a expectativa é de um aviso "on-line" do pagamento. Não encontramos, nem nela nem no Manual de Padrões para Iniciação do Pix, regra de reenvio desse aviso quando o servidor de quem recebe está fora. E o manual registra a premissa que uma queda quebra por definição: "o usuário recebedor possui uma infraestrutura de TI apta para tratar os webhooks".

A saída está no mesmo padrão. A API tem o serviço "Consultar Pix recebidos", com dois filtros obrigatórios, a data de início e a de fim do período, e o de consultar uma cobrança pelo seu identificador. O manual descreve a consulta como passo do fluxo e o webhook como alternativa: no fluxo do QR dinâmico, o recebedor "por meio de nova consulta à API Pix, verifica se o pagamento foi realizado", e em seguida vem "Alternativamente, o passo 4 pode ser realizado com o uso de webhooks".

Traduzindo para a operação: uma ferramenta que, ao voltar, pergunta ao banco "o que entrou entre 14h e 20h?" e cruza com as cobranças que ela mesma criou libera quem pagou durante a queda sem você abrir o extrato. Uma ferramenta que só reage a aviso deixa essas pessoas esperando você.

Contra-argumento honesto: essa reconciliação só funciona para cobrança com identificador. Pix mandado para a chave colada na bio não tem como ser associado a uma venda específica, e o manual é explícito ao dizer que, no webhook, "Pix recebidos que não estejam associados a um txid não gerarão chamadas". A consulta até devolve esses Pix, mas sem o vínculo com a venda. A diferença entre os dois tipos de cobrança está em QR Code Pix estático ou dinâmico.

Depois da volta: não despeje tudo de uma vez

Resposta primeiro: a fila acumulada precisa sair em ordem de prioridade e em ritmo controlado, porque o Telegram limita a velocidade de envio.

O FAQ de bots do Telegram orienta: "In a single chat, avoid sending more than one message per second". E, para disparo em massa, registra que os bots "are not able to broadcast more than about 30 messages per second, unless they enable paid broadcasts to increase the limit", com erros 429 para quem passa disso.

Numa queda de 30 horas, a fila típica mistura três grupos: quem pagou com código gerado antes da queda, os pedidos de compra que ficaram sem resposta, e os lembretes de renovação que deveriam ter saído no período. A ordem que protege a receita e a reputação:

1. Liberar quem pagou, com uma mensagem curta reconhecendo o atraso.
2. Responder quem estava no meio da compra, gerando cobrança nova para quem tinha a antiga expirada.
3. Retomar lembretes e remoções, escalonados, sem disparar tudo no mesmo minuto.

Quem mistura os três num único disparo arrisca o erro de limite justamente nas mensagens de quem pagou. A mecânica dos limites de envio está em envio em massa no Telegram.

O que perguntar à ferramenta antes de a queda acontecer

Resposta primeiro: todo servidor cai um dia; a diferença entre ferramentas está no que cada uma faz quando volta. Cinco perguntas separam as duas coisas:

• Ao voltar, vocês consultam os Pix recebidos no período ou dependem só do aviso? A resposta certa é consultar.
• O reinício descarta a fila pendente do Telegram? Se descarta, pergunte por quê.
• Qual o prazo de expiração das cobranças? Prazo curto demais gera código morto numa queda de poucas horas.
• Eu sou avisado da queda, ou descubro pelo cliente? Descobrir pelo print é o pior cenário.
• Quem pagou e ficou sem acesso é liberado sozinho, ou alguém precisa fazer na mão?

Dá para testar parte disso antes de vender, com a compra de teste descrita em como testar o bot de vendas. E se o problema já aconteceu com alguém específico, o roteiro de investigação caso a caso está em pagou e não entrou no grupo.

Erros comuns

• Estornar em pânico quem pagou durante a queda. O dinheiro entrou; o que falta é o acesso. Estornar transforma um atraso numa venda perdida.
• Mandar a pessoa pagar de novo. Sem conferir o extrato, você cria cobrança duplicada e um problema bem maior, explicado em cobrança duplicada.
• Confundir queda do bot com queda do Pix. São falhas de donos diferentes, e o roteiro para o segundo caso está em Pix fora do ar.
• Reiniciar com a fila descartada para "começar limpo" depois de uma queda longa.
• Tratar o reenvio do webhook como garantia. Nem o Telegram publica quantas vezes insiste, nem o padrão do Pix descreve reenvio do aviso.
• Deixar a remoção de vencidos para depois indefinidamente. Numa queda longa, quem venceu segue dentro; retome a rotina logo depois de liberar quem pagou.

Conclusão

Um bot de vendas fora do ar não apaga as vendas do intervalo na hora: o Pix funciona 24 horas por dia, o dinheiro de quem tinha o código entra do mesmo jeito e o pedido de quem chegou durante a queda fica guardado. O que a queda cria é uma fila de gente que pagou ou tentou comprar e espera resposta, e essa fila tem prazo. O Telegram guarda as mensagens por até 24 horas, a cobrança aberta vale 24 horas no padrão, e o aviso automático do banco não tem reenvio descrito. O que recupera tudo é a ferramenta consultar os Pix recebidos no período e liberar em ordem.

O próximo passo cabe numa mensagem: mande as cinco perguntas acima para o suporte da ferramenta que você usa hoje e guarde as respostas. Se estiver comparando opções, a página de preço da Afroditte mostra a taxa fixa de R$ 0,69 por transação, sem mensalidade, e você pode criar sua conta para ver o fluxo por dentro antes de decidir. Para o quadro geral de riscos de operar com bot, o guia de como evitar banimento do bot no Telegram é o ponto de partida do cluster.