Pular para o conteúdo principal

Pagamento e baixa

A regra de ouro do Dunning é simples: nenhuma mensagem depois do pagamento. Esta página explica como o pagamento entra no sistema, o que acontece na baixa e como funcionam a verificação de "já paguei" e a trava jurídica.

Como o pagamento chega​

Todo pagamento entra como um evento de pagamento, com origem e evidência registradas:

  • Webhook do gateway (Kobana) — no modo integrado, a confirmação chega em tempo real e a baixa é automática. As entregas de webhook são deduplicadas: reentregas do provedor não geram efeito duplo.
  • Integração (PSP/CNAB) — sinais vindos de outros provedores de pagamento ou de arquivos de retorno bancário.
  • Manual — o operador registra o pagamento na cobrança (por exemplo, uma transferência recebida por fora), informando valor e data.

Cada evento carrega um nível de confiança conforme a origem — uma confirmação do gateway vale mais que um relato sem comprovante — e é isso que separa a baixa imediata da verificação humana.

O que acontece na baixa​

Quando um pagamento é confirmado:

  1. A cobrança vira Paga, com Data de Pagamento e Valor Pago registrados.
  2. A régua é concluída e todo envio ainda não disparado é suprimido na hora — inclusive mensagens já na fila. Como garantia final, o sistema reconfere o estado da cobrança milissegundos antes de cada envio; se o pagamento chegou nesse meio-tempo, a mensagem é suprimida com o motivo registrado.
  3. Se a cobrança estava vencida, em régua ou negociada, a recuperação é registrada nas métricas de recuperação.
  4. O cliente é reclassificado automaticamente (o pagamento muda o histórico dele).

Casos derivados:

  • Pagamento parcial — o título original é liquidado pelo valor pago (baixa parcial: vira Paga, encerra a régua daquele título e registra a recuperação do valor recebido) e o sistema cria uma cobrança-filha para o saldo. Essa filha vence na data do pagamento, reentra na régua desde o início e os juros passam a incidir sobre o saldo (não mais sobre o valor cheio). A filha aponta para o título de origem em metadata.partialPaymentParentChargeId.
  • Estorno — a cobrança reabre (volta para Vencida) e recomeça a régua do início (novo ciclo de cobrança), reenviando os avisos. Ações de negativação/protesto ainda ativas não são duplicadas.

"Já paguei": verificação antes de insistir​

Quando o devedor afirma que já pagou (pelo portal ou registrado pelo operador), o sistema nunca rebate com dado velho. O fluxo:

  1. A régua pausa na hora e os envios pendentes são cancelados.
  2. Um evento de pagamento "alegado", de baixa confiança, é registrado com a evidência que houver.
  3. Uma tarefa de verificação entra na fila do operador, e um alerta aparece no sino.
  4. O operador verifica o comprovante e resolve: confirmado — a cobrança é paga e encerrada; não confirmado — a régua retoma exatamente de onde parou.

O campo paymentClaimed marca a cobrança durante a verificação, e o card de status no detalhe mostra a pausa com o motivo.

A trava jurídica (legalHold, com motivo em legalHoldReason) bloqueia a cobrança por razões legais — dívida em discussão judicial, prescrição. Com a trava ativa:

  • Nenhuma mensagem da régua sai: a checagem pré-envio suprime qualquer etapa, com o motivo registrado.
  • Ações de negativação e protesto ficam bloqueadas.

A trava não cancela a dívida; ela congela a atuação até a situação jurídica se resolver.

Auditoria​

Cada evento de pagamento, baixa, supressão e verificação fica na trilha de auditoria, que é imutável (registros não podem ser alterados nem apagados). Se alguém perguntar "por que pararam de cobrar?" ou "por que cobraram depois do pagamento?", a resposta está registrada — e a segunda pergunta não deve ter motivo para existir.