Cobrança recorrente com Pix Automático no seu sistema
Como integrar Pix Automático, Pix com vencimento, boleto e cartão ao seu sistema, com régua de cobrança, retentativas e baixa automática via webhook.
Neste artigo
- Recorrência não é só gerar uma cobrança por mês
- Quando vale construir, e quando não vale
- Pix Automático, Pix com vencimento, boleto e cartão: quando cada um
- Como funciona a autorização do Pix Automático
- Assinatura, fatura e pagamento: o modelo de dados
- Webhooks, baixa automática e idempotência
- Régua de cobrança, inadimplência e retentativas
- Escolhendo o PSP ou gateway sem ficar preso a ele
- Erros que aparecem com frequência
- Como medir depois do lançamento
- Checklist antes de ligar a cobrança automática
- Do diagnóstico à primeira cobrança automática
Todo sistema que vende assinatura, mensalidade ou contrato contínuo chega ao mesmo ponto: o financeiro passa os primeiros dias do mês gerando cobrança, conferindo extrato e mandando mensagem para quem não pagou. A tentação é contratar um gateway que "faz recorrência" e dar o assunto por encerrado.
O gateway resolve a parte de movimentar o dinheiro. Não resolve o que importa para o seu negócio: quem está em dia, quem está suspenso, o que foi cobrado e o que acontece quando o pagamento não vem. Essa parte mora no seu sistema, e é dela que este texto trata, com o Pix Automático no centro, porque ele mudou quais meios fazem sentido para recorrência no Brasil.
Recorrência não é só gerar uma cobrança por mês
Se recorrência fosse "todo dia 10, gere um Pix", um agendador resolveria. Na prática, as perguntas difíceis aparecem já no segundo mês:
- O cliente trocou de plano no dia 17. A próxima fatura é proporcional ou cheia?
- O pagamento de março caiu duas vezes. Qual vale, e como devolver o outro?
- O débito falhou por falta de saldo. Tenta de novo quando? Avisa quem?
- O contrato foi cancelado no meio do ciclo. Cobra o mês cheio, proporcional ou nada?
Cada resposta é uma regra de negócio. Se ela não está no sistema, está na cabeça de alguém do financeiro.
Recorrência é uma máquina de estados, não um agendamento. A assinatura passa por ativa, em atraso, suspensa e cancelada. A fatura passa por aberta, paga, vencida, cancelada e estornada. O meio de pagamento é só um dos atores que empurram esses estados.
Quando vale construir, e quando não vale
Vale quando a cobrança está amarrada ao produto: o acesso depende do pagamento, o valor varia com uso, existem planos e contratos com regras próprias, ou você cobra em nome de terceiros. É o caso típico de SaaS, escolas, clínicas com planos e prestadores de serviço contínuo.
Não vale quando a recorrência é simples e isolada: valor fixo, poucos clientes, nenhuma consequência automática no produto se o pagamento atrasar. Aí o módulo de assinaturas do gateway ou a cobrança do ERP resolvem.
O cenário mais comum fica no meio: o PSP ou gateway gera a cobrança, liquida e notifica; o seu sistema guarda o estado da assinatura, a régua e a baixa.
Pix Automático, Pix com vencimento, boleto e cartão: quando cada um
Não existe meio único ideal. Cada um tem um perfil de atrito para quem paga e de previsibilidade para quem recebe:
| Meio | O que o pagador faz | Bom para | Cuidado |
|---|---|---|---|
| Pix Automático | Autoriza uma vez no app do banco; os débitos seguintes acontecem sem ação dele | Mensalidades e contratos contínuos, inclusive de quem não tem cartão | O pagador pode cancelar a autorização quando quiser |
| Pix com vencimento | Paga cada cobrança pelo QR Code ou código copia e cola | Faturas de valor variável, clientes que aprovam cada pagamento | Depende de o cliente lembrar |
| Boleto com QR Code Pix | Paga o boleto no banco ou pelo Pix impresso nele | Empresas cujo contas a pagar só trabalha com boleto | Compensação mais lenta quando pago como boleto |
| Cartão recorrente | Cadastra o cartão uma vez | Consumidor final, venda online | Cartão vence, é trocado ou bloqueado; existe chargeback |
Na prática, B2B tende a ficar entre boleto, Pix com vencimento e Pix Automático; B2C, entre cartão e Pix Automático. Um sistema bem desenhado aceita mais de um meio por assinatura e deixa o cliente trocar sem perder histórico.
Não confunda Pix Automático com Pix agendado recorrente. No agendado, é o pagador quem programa as transferências no próprio app: você não envia cobrança, não controla o valor e não fica sabendo quando ele desiste.
Como funciona a autorização do Pix Automático
O Pix Automático foi lançado pelo Banco Central em 2025 para cobrir o que faltava ao Pix: pagamento recorrente sem o pagador agir a cada ciclo. Em linhas gerais:
- O recebedor pede a autorização por meio do seu PSP (o banco ou instituição de pagamento que recebe para você). O pedido chega ao pagador como solicitação no app da instituição dele ou por um QR Code, que pode vir combinado com o primeiro pagamento.
- O pagador autoriza uma única vez, no app da própria instituição, vendo recebedor, periodicidade e condições. Ele pode definir um valor máximo por cobrança.
- A cada ciclo, o recebedor envia a cobrança pelo seu PSP, com a antecedência que o regulamento exige. A instituição do pagador avisa sobre o débito.
- O débito acontece na data, sem ação do pagador. Se faltar saldo, há retentativas dentro de limites definidos, quando a autorização as permite.
- O pagador pode cancelar a autorização a qualquer momento, e também um débito agendado antes que ele aconteça.
Dois pontos pesam no desenho do sistema.
A autorização é um objeto com vida própria. Ela fica pendente, aprovada, rejeitada, expirada ou cancelada, e o cancelamento pode partir do pagador a qualquer momento. Uma assinatura cuja autorização caiu não pode continuar marcada como "no automático".
Enviar a cobrança é responsabilidade sua. O Pix Automático não debita sozinho. Se a rotina que gera as cobranças falhar e perder a janela de antecedência, aquele ciclo não é debitado, e alguém só descobre no fechamento. Monitore esse envio como monitora os pagamentos.
Prazos exatos e número de retentativas seguem o regulamento do Pix e a implementação de cada PSP: confirme na documentação do seu e trate isso como requisito.
Assinatura, fatura e pagamento: o modelo de dados
É comum que os problemas de cobrança recorrente nasçam de um modelo que mistura coisas diferentes na mesma tabela. Separe quatro conceitos:
- Assinatura: cliente, plano, periodicidade, dia de cobrança, meio preferido e estado. Guarda a referência à autorização do Pix Automático ou ao cartão tokenizado, nunca o número do cartão.
- Fatura: o que se deve num ciclo. Tem itens (mensalidade, adicional, desconto, ajuste proporcional), vencimento e estado. É o que o cliente vê e o que gera nota fiscal.
- Tentativa de cobrança: cada vez que você pede o dinheiro por um meio. Uma fatura pode ter várias tentativas, em meios diferentes.
- Pagamento: o dinheiro que de fato entrou, com o identificador da transação no PSP.
Com essa separação, as perguntas difíceis ficam simples. Pagou duas vezes? Dois pagamentos para uma fatura, e um vira crédito ou devolução. Mudou de plano? A fatura seguinte ganha um item de ajuste.
Guarde os valores de cada fatura como foram cobrados, sem recalcular a partir do plano atual. Plano muda de preço; fatura emitida não muda.
Se cada cliente da sua plataforma tem os próprios assinantes e a própria conta de recebimento, o isolamento começa no modelo, como mostramos no texto sobre arquitetura SaaS multi-tenant.
Webhooks, baixa automática e idempotência
A baixa automática depende dos eventos que o PSP envia por webhook: autorização aprovada ou cancelada, cobrança agendada, pagamento liquidado, falha, devolução. Três regras evitam a maior parte dos incidentes.
Trate todo webhook como repetível. PSPs reenviam eventos quando não recebem confirmação e, às vezes, mesmo quando receberam. Use o identificador da transação e o da cobrança que você definiu como chave única; se o pagamento já foi registrado, o segundo evento é descartado sem erro. Sem essa idempotência, uma fatura recebe duas baixas e o crédito indevido só aparece meses depois.
Confirme na origem antes de agir. Valide a autenticidade da chamada do jeito que o PSP especifica (certificado mútuo, assinatura ou token) e, para eventos que liberam acesso ou emitem nota, consulte a API do PSP para confirmar o status. Um endpoint que aceita qualquer requisição é convite para "pagamentos" que nunca aconteceram.
Responda rápido, processe depois. O endpoint grava o evento numa fila e responde; baixa, nota e mensagem ao cliente acontecem em seguida, com retentativa própria.
Tenha também uma rotina periódica que consulta no PSP as cobranças em aberto e reconcilia o que o webhook deixou passar. Cruzada com o extrato, ela fecha o ciclo da conciliação bancária automática.
Com a baixa confiável, o resto encadeia: a fatura paga dispara a emissão automática da nota fiscal, atualiza o contas a receber no ERP, seja ele TOTVS, SAP, Omie ou Bling, e libera o que estava bloqueado.
Régua de cobrança, inadimplência e retentativas
Régua de cobrança é a sequência de ações antes e depois do vencimento. Uma estrutura de partida:
- Antes do vencimento: aviso com a fatura detalhada. No Pix Automático, a instituição do pagador já avisa do débito; o seu aviso diz o que está sendo cobrado.
- No dia: confirmação do pagamento ou, se o débito falhou, um Pix com vencimento como alternativa.
- Primeiros dias de atraso: lembretes por e-mail, no próprio sistema e pelo WhatsApp integrado via API oficial.
- Atraso prolongado: restrição parcial, depois suspensão, depois tratamento caso a caso pelo financeiro.
- Regularização: ao pagar, tudo volta sozinho, sem chamado de suporte.
Algumas decisões precisam estar escritas antes de qualquer código.
Retentativa não funciona igual em todo meio. No cartão, o motivo da recusa importa: cartão cancelado não adianta tentar de novo; falta de limite, talvez em outro dia. No Pix Automático, vale o que o arranjo e a autorização permitem. No Pix com vencimento não existe retentativa, existe lembrete.
Multa, juros e desconto precisam de uma fonte única. Pix com vencimento e boleto permitem configurar esses encargos na própria cobrança. Se o sistema calcula de um jeito e a cobrança foi gerada de outro, o valor pago não bate com a fatura e a baixa trava.
Suspensão é decisão de negócio, não de TI. Dias de tolerância, clientes que nunca são suspensos automaticamente, quem pode prorrogar: isso vem da diretoria. Deixe as regras configuráveis e registre quem alterou o quê.
Comunicação tem limite. Régua agressiva gera reclamação, e mensagens de cobrança carregam dados pessoais sujeitos à LGPD (Lei 13.709/2018).
Escolhendo o PSP ou gateway sem ficar preso a ele
Para receber por Pix Automático, você precisa de um PSP que ofereça o produto do lado recebedor. Bancos e gateways variam bastante em meios suportados, qualidade da API, ambiente de testes e suporte. Pergunte:
- Ele oferece na mesma conta os meios que você usa hoje e os que vai usar?
- A homologação simula de verdade autorizações, recusas e cancelamentos?
- Os webhooks são reenviados em caso de falha? Existe consulta para reconciliar?
- O que acontece com autorizações ativas e cartões salvos se você trocar de fornecedor?
O ponto de arquitetura é um só: o seu sistema não deve conhecer o PSP diretamente. Crie um módulo de pagamentos com interface própria ("criar autorização", "enviar cobrança", "consultar pagamento", "devolver") e um adaptador por fornecedor. O resto do sistema conversa com essa interface, nunca com os campos específicos de um gateway.
Essa camada é barata no começo e cara depois, e é ela que permite trocar ou somar fornecedores sem reescrever a cobrança.
Erros que aparecem com frequência
- Estado guardado só no gateway. Relatório, suspensão e nota fiscal viram exportação manual.
- Liberar acesso quando a cobrança é criada, e não quando o pagamento é confirmado.
- Data de corte mal definida. Uma cobrança gerada às 23h50 pode cair no ciclo errado.
- Testar só o caminho feliz. Pouca gente testa o webhook duplicado e o pagamento que chega depois do cancelamento.
Como medir depois do lançamento
Acompanhe no próprio sistema, por meio de pagamento:
- Proporção de faturas pagas até o vencimento e dentro da tolerância.
- Assinaturas migradas para Pix Automático e autorizações canceladas pelo pagador.
- Tempo entre o pagamento e a baixa, que deveria ser de minutos, não de dias.
- Baixas manuais e divergências na conciliação, com meta de tender a zero.
- Horas que o financeiro dedica à cobrança no início do mês, comparadas com o período anterior.
Sem esses números num painel, você só sabe que ninguém reclamou ainda.
Checklist antes de ligar a cobrança automática
- Regras escritas: proporcionalidade, troca de plano, tolerância, suspensão e cancelamento.
- Assinatura, fatura, tentativa e pagamento separados no modelo.
- Pix Automático testado em homologação, com recusas e cancelamentos.
- Módulo de pagamentos com adaptador por fornecedor.
- Webhook autenticado, idempotente e assíncrono, mais reconciliação diária.
- Régua revisada pelo financeiro e pelo comercial.
- Emissão fiscal e ERP testados de ponta a ponta.
- Migração dos clientes atuais planejada, com comunicação sobre a nova autorização.
Do diagnóstico à primeira cobrança automática
A Pervian Tech constrói esse módulo sob medida, dentro do sistema que você já tem ou como parte de uma plataforma nova de desenvolvimento web. O trabalho começa por um diagnóstico das suas regras de cobrança, dos meios que seus clientes usam e das integrações com ERP, emissão fiscal e banco. Dali saem o desenho da solução e as fases: protótipo da régua, MVP com o primeiro meio de pagamento e evolução com os demais. O cronograma é definido a partir desse diagnóstico, e o investimento é sob consulta, porque depende do seu contexto. Se a cobrança recorrente ainda consome o seu financeiro todo mês, conte como ela funciona hoje.
Quer uma solução assim na sua empresa?
Cada projeto é desenhado sob medida para o seu processo, e o investimento é definido sob consulta depois de entendermos o contexto. O diagnóstico inicial não tem custo: descreva o cenário e respondemos em até um dia útil.
Falar com a Pervian Tech