Skip to main content
ElasticFunnels sends automated emails at key points in the subscription lifecycle. When a renewal charge fails, the dunning system retries it on a schedule, emails the subscriber after each failed attempt, and can pass the subscriber to your call center.

Subscription Email Templates

Five subscription-specific email templates are sent:

Renewal Success

Sent after a successful subscription charge. Confirms the renewal and shows the next billing date.

Renewal Failed

Sent after every failed charge attempt until the subscription is canceled. The tone escalates with each attempt and ends in a final notice.

Pre-Renewal Reminder

Sent 3 days before the next charge, so the customer knows the charge is coming and can contact you first.

Subscription Paused

Confirms that billing has been paused. Shows the resume date if one is set.

Subscription Canceled

Confirms cancellation, including a cancel after the last retry fails. Includes a soft win-back CTA.
Older brands also have Dunning Final Notice (dunning-final) and Payment Method Expiring (payment-method-expiring) templates, and Settings → Subscriptions has pickers for them. Nothing sends either one today, so a choice saved there has no effect. The final notice is part of the Renewal Failed email instead (see below).

How Renewal Failed escalates

The default renewal-failed template changes with subscription.retry_count, the number of failed attempts so far. The failed renewal itself is attempt 1. With the default Max Retries of 6, the email after attempt 5 is the final notice and the last Renewal Failed email. If attempt 6 fails, the subscription is canceled and the Subscription Canceled email goes out instead. You can edit the wording in the email editor. The conditions in the default template look like this:
There is no page yet where a customer can enter a new card. The default template’s Update Payment Method button opens your /members page, which has no card form. Edit that button to point to your support email or phone number, so a customer who wants to keep the subscription can reach you. The template also prints brand.support_phone and brand.support_email when they are set in Brand Settings.

Template Variables

All subscription email templates receive the standard purchase data (products, amounts, customer info) plus these subscription-specific fields:

Setting Up Subscription Emails

1

Open your merchant settings

Go to Settings → Merchants and click to edit your NMI or Stripe merchant.
2

Go to the Email tab

Switch to the Email tab. You’ll see the standard order email section, plus two new sections: Subscription Emails and Dunning Configuration.
3

Create email templates

In the Subscription Emails section, click Create next to each template type. This generates a pre-built template you can customize in the email editor. Then select the template from the dropdown.
4

Configure dunning settings

In the Dunning Configuration section, set your retry schedule and escalation rules.
Subscription emails need a sender: brand SMTP, or an Email Integration on the merchant (Amazon SES, Postmark, Brevo, Resend, Mailgun, SendGrid or Mailrelay). Without one, no emails will be sent. See Email Sending Accounts.
Renewals and retries run for NMI, Stripe, PayPal and Authorize.net merchants. The Subscription Emails and Dunning Configuration sections show on NMI and Stripe merchants; PayPal and Authorize.net subscriptions use the default retry schedule below and the brand’s default subscription emails from Settings → Subscriptions.

Dunning Configuration

Dunning is the process of retrying failed subscription charges. When a renewal fails, the subscription enters a retry cycle according to your schedule.
The Callcenter Escalation After Retry # and Send to Callcenter on Cancel settings decide whether to send a call center event for that merchant. The integration controls which providers receive it, when they receive it, and which decline codes qualify. See External Call Center Integrations for the per-event configuration.

How the Retry Schedule Works

Each number in the schedule is how many days to wait after a failed attempt before the next one. With the default schedule 1, 3, 5, 7, 10, 14 and Max Retries 6:
  1. Renewal fails on the charge date. Retry in 1 day.
  2. Retry 1 fails. Retry in 3 days.
  3. Retry 2 fails (call center escalation fires here when set to 3). Retry in 5 days.
  4. Retry 3 fails. Retry in 7 days.
  5. Retry 4 fails. Retry in 10 days.
  6. Retry 5 fails: that is the sixth failed attempt, so the subscription is canceled, about 26 days after the first failure.
So the five retries fall on days 1, 4, 9, 16 and 26 after the failed renewal. On the default schedule the waits also adapt to the decline reason (longer for insufficient funds and for cards that cannot be used again), and American Express and Discover cards get one extra day. A schedule you set yourself is used as entered. See Dunning for the table. In days after the first failure, insufficient funds retries on days 2, 7, 17, 32 and 53, and unusable cards on days 3, 10, 24, 45 and 73. Other stored cards are tried at once. When an NMI renewal is declined, ElasticFunnels immediately tries the customer’s other cards stored in the brand; for Stripe, the other cards on the Stripe customer. A card that succeeds becomes the subscription’s card, and no retry is needed.

Where the schedule is set

The first one that applies wins:
  1. Organization or brand schedule: Call Center → Billing → Dunning. An active schedule there overrides the merchant’s. Its offsets are in hours and are rounded up to whole days.
  2. Merchant schedule: the merchant’s Email tab → Dunning Configuration. You can edit it on NMI and Stripe merchants only.
  3. Default: the decline-aware schedule above, used by every other merchant, PayPal and Authorize.net included.
The hint under Retry Schedule in the app says the days count from the initial failure. The billing job counts each wait from the previous attempt, as described above.
Start from the default: retries a few days apart catch a payday or a new monthly limit, while retries hours apart on the same card usually collect the same decline. If the Dunning Recovery card shows few recoveries, set your support phone and email in Brand Settings so every Renewal Failed email tells customers how to reach you, and turn on call center escalation if you have a team that can call.

Pre-Renewal Reminders

Pre-renewal emails are sent automatically 3 days before the next scheduled charge to customers with an active subscription and a valid email address. They go out only for merchants that have a Pre-Renewal Reminder template picked on their Email tab and a working sender (brand SMTP, or the merchant’s email integration).
Pre-renewal emails are recommended for legal compliance in some jurisdictions (e.g., FTC negative-option guidelines in the US).

Where Events Go

When a dunning event fires (renewal failed, cancel, winback), it’s routed through three layers:
  1. Subscription emails: the templates described above, sent to the customer directly.
  2. Merchant-level callcenter gate: the Callcenter Escalation After Retry # and Send to Callcenter on Cancel settings decide if a call-center send is attempted.
  3. Per-integration event config: with the in-house call center connected (the Organization Callcenter integration), the lead goes to your agents, who get leads one at a time in the Agent Workstation. Each external call-center integration decides which events it receives, how long to wait before sending, and which decline codes to filter.

Further reading

For detailed documentation on email template design, available variables, and editing, see the dedicated Emails section: