What happens to dunning campaign fields when a customer pays

When a customer pays their overdue balance during a dunning campaign, Lago resets the in-progress state but keeps the campaign linked to the customer. The attempt counter and timestamp go back to their idle values so the customer is no longer treated as actively delinquent, while the campaign association is preserved so dunning re-engages automatically if a new overdue balance appears later.

How dunning field state works

The customers table tracks dunning state across three fields:

• applied_dunning_campaign_id: the campaign associated with the customer. Set when a campaign is applied, and not cleared on payment.

• last_dunning_campaign_attempt: attempts made in the current cycle. Reset to 0 when a dunning payment request is paid.

• last_dunning_campaign_attempt_at: timestamp of the last attempt. Returns to NULL once the customer has no remaining dunning in progress.

When the customer pays a dunning payment request, the counter resets to 0 and the timestamp clears, while applied_dunning_campaign_id stays as it was, ready to run again on a future overdue balance. These field names and reset behavior are implementation details that can change without notice; the stable part is the observable outcome, dunning stops once the balance is paid and resumes if the customer falls overdue again.

Identifying customers who resolved a dunning campaign

These fields are a convenience signal, not an authoritative record of whether a dunning cycle was resolved. The idle state, counter at 0 and timestamp NULL, is shared by a customer who never fell overdue, and by a customer who paid one balance but still has dunning in progress elsewhere. In both cases the fields can read as "resolved" while money is still owed.

So if you are building a data pipeline or data lake view, do not treat the three fields as a "this customer is resolved" flag. Use them as a hint, then confirm against the customer's actual outstanding balance and payment records before acting on it.

This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.