Skip to main content

Payment and settlement

Dunning's golden rule is simple: no messages after payment. This page explains how payments enter the system, what happens at settlement, and how the "I already paid" verification and the legal hold work.

How payment arrives​

Every payment enters as a payment event, with its origin and evidence recorded:

  • Gateway webhook (Kobana) — in integrated mode, confirmation arrives in real time and settlement is automatic. Webhook deliveries are deduplicated: provider redeliveries have no double effect.
  • Integration (PSP/CNAB) — signals from other payment providers or from bank return files.
  • Manual — the operator records the payment on the charge (for example, a transfer received externally), entering amount and date.

Each event carries a confidence level based on its origin — a gateway confirmation counts for more than an unsupported claim — and that is what separates immediate settlement from human verification.

What happens at settlement​

When a payment is confirmed:

  1. The charge becomes Paid, with Payment Date and Paid Amount recorded.
  2. The rule is completed and every send not yet fired is suppressed on the spot — including messages already queued. As a final safeguard, the system rechecks the charge's state milliseconds before each send; if payment arrived in the meantime, the message is suppressed with the reason recorded.
  3. If the charge was overdue, enrolled in a rule, or negotiated, the recovery is recorded in the recovery metrics.
  4. The customer is automatically reclassified (the payment changes their history).

Derived cases:

  • Partial payment — the original charge is settled for the amount paid (partial settlement: it becomes Paid, ends the rule for that charge and records the recovery of the amount received) and the system creates a child charge for the remaining balance. That child charge is due on the payment date, re-enters the rule from the start, and interest now accrues on the remaining balance (no longer on the full amount). The child charge points back to its source charge in metadata.partialPaymentParentChargeId.
  • Chargeback — the charge reopens (returns to Overdue) and restarts the rule from the beginning (a new collection cycle), resending the notices. Credit bureau registration/protest actions still active are not duplicated.

"I already paid": verify before insisting​

When the debtor claims they have already paid (through the portal or recorded by the operator), the system never pushes back with stale data. The flow:

  1. The rule pauses immediately and pending sends are cancelled.
  2. A low-confidence "claimed" payment event is recorded with whatever evidence exists.
  3. A verification task enters the operator's queue, and an alert appears in the bell.
  4. The operator checks the proof of payment and resolves it: confirmed — the charge is paid and closed; not confirmed — the rule resumes exactly where it left off.

The paymentClaimed field flags the charge during verification, and the status card on the detail view shows the pause with its reason.

The legal hold (legalHold, with the reason in legalHoldReason) blocks the charge for legal reasons — debt under litigation, statute of limitations. With the hold active:

  • No rule message goes out: the pre-send check suppresses any step, with the reason recorded.
  • Credit bureau registration and protest actions are blocked.

The hold does not cancel the debt; it freezes activity until the legal situation is resolved.

Audit​

Every payment event, settlement, suppression, and verification lives in the audit trail, which is immutable (records cannot be altered or deleted). If anyone asks "why did you stop collecting?" or "why did you collect after payment?", the answer is on record — and the second question should never have a reason to exist.