WebApp Modules

Dunning & Failed Payment Recovery

Automatically retry failed subscription charges on a configurable schedule and cancel subscriptions after exhausting all retries.

Overview

Dunning is the process of recovering revenue from failed subscription payments. When a card charge fails — due to insufficient funds, expired card, or a temporary bank block — DashNex automatically retries the payment according to your configured schedule instead of immediately cancelling the subscription.

Each retry attempt fires a payment_failed lifecycle event, which you can use to send automated emails asking the customer to update their payment method.

Configuring Dunning Settings

Go to Settings → Dunning in your WebApp admin to configure your retry schedule.

Retry Schedule

Set the days after the initial failed charge on which retries should be attempted. The default schedule is Day 1, Day 3, Day 5, Day 7.

Example with default schedule:
Day 0 — Initial charge fails
Day 1 — First retry
Day 3 — Second retry
Day 5 — Third retry
Day 7 — Final retry → if still failed, subscription is auto-cancelled (if enabled)

You can add or remove retry days to match your business needs. Fewer retries are less disruptive; more retries recover more revenue but extend the window of uncertainty.

Auto-Cancel After Exhaustion

When enabled, a subscription is automatically cancelled after all retry attempts have been exhausted and the payment is still failing. This fires asubscription_cancelled event, which can trigger access revocation and win-back automations.

Note: With auto-cancel disabled, failed subscriptions remain in a failed state indefinitely. You will need to manually cancel them or resolve the payment issue.

How Retries Work

Retries are executed by the Payment Processor worker, not the WebApp. The Offers module reads the dunning settings and passes them to the processor when a subscription is created. The processor handles the actual retry scheduling and execution.

On each retry attempt:

  1. Payment Processor attempts to charge the customer's saved payment method
  2. If the charge succeeds, the subscription continues normally and a subscription_renewed event fires
  3. If the charge fails, a payment_failed event fires and the next retry is scheduled
  4. After the final retry fails (and auto-cancel is on), a subscription_cancelled event fires

Recovery Emails via Automations

Combine dunning with email automations to recover more revenue. A recommended setup:

Trigger: payment_failed (attempt 1)

Send a friendly "heads up" email: "We had trouble processing your payment. We'll try again in a few days — no action needed unless your card has changed."

Trigger: payment_failed (attempt 3)

Send an urgent email with a direct link to update their billing info: "Your subscription will be cancelled soon. Update your payment method to continue."

Trigger: subscription_cancelled

Send a cancellation confirmation with a re-subscribe link and optionally offer a discount to win the customer back.

Customer Self-Service

Customers can update their payment method from the Billing tab in their WebApp account. Updating to a valid card before the final retry attempt allows the next retry to succeed and the subscription to continue without interruption.

Next Steps

  • Lifecycle Events — Trigger recovery emails from payment_failed and subscription_cancelled events
  • Payment Methods — How customers update their saved cards during dunning
  • Automations — Set up email sequences for failed payment recovery