Saltar al contenido principal

Pago y baja

La regla de oro del Dunning es simple: ningún mensaje después del pago. Esta página explica cómo el pago entra al sistema, qué sucede en la baja y cómo funcionan la verificación de "ya pagué" y el bloqueo jurídico.

Cómo llega el pago​

Todo pago entra como un evento de pago, con origen y evidencia registrados:

  • Webhook del gateway (Kobana) — en el modo integrado, la confirmación llega en tiempo real y la baja es automática. Las entregas de webhook se deduplican: las reentregas del proveedor no generan efecto doble.
  • Integración (PSP/CNAB) — señales provenientes de otros proveedores de pago o de archivos de retorno bancario.
  • Manual — el operador registra el pago en el cobro (por ejemplo, una transferencia recibida por fuera), informando monto y fecha.

Cada evento lleva un nivel de confianza según el origen — una confirmación del gateway vale más que un relato sin comprobante — y eso es lo que separa la baja inmediata de la verificación humana.

Qué sucede en la baja​

Cuando un pago se confirma:

  1. El cobro pasa a Pagado, con Fecha de Pago y Monto Pagado registrados.
  2. La regla se completa y todo envío aún no disparado se suprime al instante — incluidos mensajes ya en cola. Como garantía final, el sistema reverifica el estado del cobro milisegundos antes de cada envío; si el pago llegó en ese intervalo, el mensaje se suprime con el motivo registrado.
  3. Si el cobro estaba vencido, en regla o negociado, la recuperación se registra en las métricas de recuperación.
  4. El cliente se reclasifica automáticamente (el pago cambia su historial).

Casos derivados:

  • Pago parcial — el título original se liquida por el monto pagado (liquidación parcial: pasa a Pagado, cierra la regla de ese título y registra la recuperación del monto recibido) y el sistema crea un cobro hijo para el saldo. Ese cobro hijo vence en la fecha del pago, reentra en la regla desde el inicio y los intereses pasan a incidir sobre el saldo (ya no sobre el monto total). El cobro hijo apunta al título de origen en metadata.partialPaymentParentChargeId.
  • Reverso — el cobro se reabre (vuelve a Vencido) y reinicia la regla desde el inicio (nuevo ciclo de cobranza), reenviando los avisos. Las acciones de negativación/protesto aún activas no se duplican.

"Ya pagué": verificación antes de insistir​

Cuando el deudor afirma que ya pagó (por el portal o registrado por el operador), el sistema nunca contesta con datos viejos. El flujo:

  1. La regla se pausa al instante y los envíos pendientes se cancelan.
  2. Se registra un evento de pago "alegado", de baja confianza, con la evidencia que haya.
  3. Una tarea de verificación entra en la cola del operador, y aparece una alerta en la campana.
  4. El operador verifica el comprobante y resuelve: confirmado — el cobro se paga y se cierra; no confirmado — la regla se reanuda exactamente donde quedó.

El campo paymentClaimed marca el cobro durante la verificación, y la tarjeta de estado en el detalle muestra la pausa con el motivo.

El bloqueo jurídico (legalHold, con motivo en legalHoldReason) bloquea el cobro por razones legales — deuda en discusión judicial, prescripción. Con el bloqueo activo:

  • Ningún mensaje de la regla sale: la verificación previa al envío suprime cualquier etapa, con el motivo registrado.
  • Las acciones de negativación y protesto quedan bloqueadas.

El bloqueo no cancela la deuda; congela la actuación hasta que la situación jurídica se resuelva.

Auditoría​

Cada evento de pago, baja, supresión y verificación queda en el registro de auditoría, que es inmutable (los registros no pueden alterarse ni borrarse). Si alguien pregunta "¿por qué dejaron de cobrar?" o "¿por qué cobraron después del pago?", la respuesta está registrada — y la segunda pregunta no debería tener motivo para existir.