Skip to main content

Payment promise

When the debtor says "I'll pay on the 15th", keeping the collection messages going until then only wears down the relationship. The payment promise records that commitment and pauses the rule until the promised date (with a short grace period) — and the engine itself resumes collection on its own if the payment does not come.

How to record it​

The promise is an interaction with the outcome promise_to_pay and a promised date (promise_date), recorded through the interactions API (POST /api/v1/interactions) — for example, when logging the result of a phone call. Optionally, record the promised amount (promised_amount) as well. The scope depends on the link:

  • With a linked charge (charge_id) — the promise applies only to that charge.
  • Without a charge — it applies to all of the person's open charges.

Two rules prevent ambiguity:

  • A promised date in the past has no effect: the interaction stays in the history, but nothing is paused.
  • A new promise replaces the previous one in the same scope (the old one is marked as superseded) — there are never two open promises fighting over the same charge.

Editing the interaction reconciles the promise with the new data; deleting it cancels the promise and resumes the rule.

The effect on the rule​

At recording time, the active enrollments in scope are paused with the reason promise_to_pay and pending sends are cancelled — someone who promised to pay does not keep receiving collection messages. The pause is not a compliance suppression: it is a recorded, audited business courtesy that the engine itself undoes when the deadline passes.

Kept or broken​

A daily check (in the early hours) re-evaluates open promises whose deadline has passed. The promise has a 2-calendar-day grace period after the promised date — promised for Friday, the debtor can pay through Sunday; on Monday the system resolves it:

  • Kept — the charges in scope were paid (or left the picture: negotiated, cancelled, written off). The promise closes as kept, without fanfare: the payment itself had already ended the rule instantly, through the normal settlement flow.
  • Broken — some charge in scope is still open. The rule resumes where it left off (except for charges covered by another still-open promise), the charge.promise_broken webhook is emitted per charge and the team gets an alert in the bell ("Payment promise broken") to decide the next step with the debtor.

A payment before the date does not wait for the check: it closes the charge immediately through the normal flow — the promise is simply marked as kept in the next scan.

Audit and events​

Recording, keeping and breaking all enter the audit trail (promise.registered, promise.kept, promise.broken), and the charge.promise_registered and charge.promise_broken webhooks notify your systems per affected charge.

Don't confuse​

  • Payment promise — "I'll pay by day X". Pauses the rule until the date + grace period; broken, the rule resumes.
  • "I already paid" — "this is already paid". Pauses the rule and opens a proof-of-payment verification task.
  • Agreement — a formal renegotiation with installments. Takes the charge out of the rule while the agreement stands.