Pular para o conteúdo

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.

Por Equipe Pervian Tech 11 min de leitura
Neste artigo

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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

  1. Regras escritas: proporcionalidade, troca de plano, tolerância, suspensão e cancelamento.
  2. Assinatura, fatura, tentativa e pagamento separados no modelo.
  3. Pix Automático testado em homologação, com recusas e cancelamentos.
  4. Módulo de pagamentos com adaptador por fornecedor.
  5. Webhook autenticado, idempotente e assíncrono, mais reconciliação diária.
  6. Régua revisada pelo financeiro e pelo comercial.
  7. Emissão fiscal e ERP testados de ponta a ponta.
  8. 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.

PixCobrança RecorrentePagamentosFinanceiroServiço: Aplicações Web

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

Continue lendo

  • Automação de processos 11 min de leitura

    Como automatizar a admissão de funcionários

    Coleta de documentos, exame admissional, assinatura eletrônica e envio ao eSocial: como automatizar a admissão sem planilha e sem correr atrás de papel.

Fale conosco

Conte o problema que precisa resolver

Respondemos em até um dia útil com uma avaliação técnica inicial. Sem custo e sem compromisso.

Usamos seus dados apenas para responder este contato.