Dunning & payment retries
This guide talks about ahat Solvimon does when an invoice is not paid: how payment attempts are retried, what dunning actions look like on the invoice, and how to drive reminders and escalation from workflows.
Why this matters
A failed payment is not an exception; on a card-based subscription book it is a steady percentage of every billing run. Dunning is the process that turns those failures back into cash: retry the payment, remind the customer, and escalate when the reminders do not work. Solvimon tracks the attempts and exposes the triggers; the retry cadence itself lives with your payment service provider.
How it works
Two separate mechanisms operate on an unpaid invoice.
Payment retries are attempts to charge the stored payment method again. For card payments through Adyen, this is Adyen Auto Rescue, which decides which refused or charged-back payments are worth retrying and picks the timing. Solvimon records each attempt.
Dunning actions are the collection steps Solvimon itself takes against an invoice: the payment requests it raises and their outcome. Each carries a status:
A dunning action references the payment_acceptor_id it was raised against and the first_payment_id of the attempt chain, so a sequence of retries on one invoice stays traceable to a single collection effort.
Retry counts and intervals are configured at the payment service provider, not in Solvimon. Solvimon exposes the resulting attempts (attempt, and whether a next_attempt_scheduled exists) but has no retry-schedule setting of its own.
Inspecting attempts
To see what has been tried on an invoice, read its payment attempts:
Each attempt carries the attempt number, an external_reference to the attempt at the provider, and next_attempt_scheduled, which tells you whether the provider intends to try again. When next_attempt_scheduled is false and the result is still unpaid, the automated retry chain is finished and the invoice needs human collection.
Payment results use a fixed set of values: AUTHORIZED, PENDING, REFUSED, CANCELLED, ERROR, REFUNDED, and CHARGED_BACK. result_details carries the provider’s reason, which is what you surface to the customer or to your collections team.
To see the payments themselves rather than the attempt chain, use GET /v{version}/invoices/{resourceId}/payments.
Stopping dunning on an invoice
When an invoice should no longer be chased, for example because it is disputed or is being settled by bank transfer, cancel its outstanding dunning actions:
Actions move to CANCEL_PENDING and then CANCELLED. Cancelling dunning does not change the invoice’s payment_status; the invoice stays unpaid until a payment is recorded or it is marked paid.
Cancelling a subscription can also cancel its dunning actions as part of the cancellation. See Subscription lifecycle.
A pending auto rescue is also cancelled automatically when the invoice is settled another way. If a payment was refused for insufficient funds, Solvimon schedules an automatic rescue with the payment provider; if the platform then pays the invoice directly through POST /v1/invoices/{id}/pay, that pending rescue is cancelled rather than firing later and charging the customer a second time. A second auto rescue is not started for an invoice that already has one active.
A call to the payment provider can itself fail with a rate-limit response (429) during a burst of payments, separately from the payment being refused. Solvimon retries a 429 with exponential backoff and jitter instead of failing the payment action, so a rate limit does not raise an alert or mark the action ERROR.
Reminders and escalation with workflows
Solvimon has no fixed dunning ladder. You build the reminder and escalation sequence with workflows, which gives you control over timing, channel, and wording per billing entity or customer segment.
The two triggers that matter:
- Failed payment. Fires when a payment attempt fails, so you can email the customer to update their payment method, notify an account owner, or open a task in your CRM.
- Overdue invoice. Fires on invoices past their due date, on the schedule you set, which is how you build the reminder ladder (for example at 3, 14, and 30 days overdue).
See Common use cases for a worked overdue-reminder sequence.
Recurring collection with payment schedules
For instalment plans and recurring collection outside the invoice cycle, a payment schedule collects on its own cadence. A schedule has a type of ONE_OFF, RECURRING, or INSTALLMENTS, and a status of ACTIVE, PAUSED, CANCELLED, or DONE.
Two fields matter for collections:
payment_method_fallbacknames the method to try when the primary method fails, so a failed card can fall back to direct debit without manual intervention.- Dunning can be enabled or disabled per schedule, so an instalment plan can be exempted from the standard chase.
Pause a schedule with POST /v{version}/payment-schedules/{resourceIdOrReference}/pause while a dispute is open, and activate it again afterwards, rather than cancelling and rebuilding it.
Edge cases
- Chargebacks are not failed payments. A
CHARGED_BACKpayment was collected and then reversed. It does not re-enter the retry chain; handle it as a dispute. - Partial payments leave the invoice
PARTIALLY_PAID. Dunning continues against the remaining balance. - Overpayments leave the invoice
OVERPAIDrather than creating a credit automatically. - Manual bank transfers arrive outside the PSP, so mark the invoice paid to stop the chase. See Payment collections.