Automate Stripe Dunning Emails With Make

Every SaaS founder and subscription business owner eventually runs into the same painful pattern: a customer's card declines, nobody catches it in time, and the subscription quietly lapses. The customer didn't intend to churn — they just had an expired card or hit a temporary limit — but without a timely nudge, they're gone. Learning how to automate Stripe failed payment emails with Make is one of the highest-leverage operational improvements a subscription business can make. It turns a reactive scramble into a consistent, professional recovery sequence that runs without you.

This guide walks through the complete setup: what dunning is, why Stripe's built-in tooling has limits, how to wire up a Make scenario that listens to Stripe webhooks and fires targeted emails at the right moments, and what to put in those messages.

What Dunning Actually Means (and Why It Matters)

Dunning is the process of communicating with customers about failed or overdue payments. The term sounds antiquated but the problem is very modern. When a subscription payment fails, businesses face a choice: retry silently and hope the card works next time, or proactively reach out to the customer and give them a reason and a path to fix it.

Silent retries alone recover some revenue, but they leave a significant portion on the table. Customers are often completely unaware their card declined. A well-timed, friendly email — sent within hours of the failure rather than days — dramatically improves the odds the customer updates their billing information before the subscription cancels.

There are two failure types to handle differently:

• Hard declines — the card is permanently invalid, blocked by the issuer, or reported stolen. These will not succeed on retry and need immediate attention.
• Soft declines — temporary issues like insufficient funds, a daily limit hit, or a card not set up for international charges. These often self-resolve or respond to a simple customer action.

Your dunning sequence should account for both.

Where Stripe's Built-In Tools Fall Short

Stripe does include a native dunning feature called Smart Retries, and it does a reasonable job of spacing out payment retry attempts. Stripe also has basic email notifications you can enable from the dashboard.

The limitations show up quickly once you want anything more tailored:

• You cannot easily customize the retry email copy to match your brand voice or tone.
• There is no native support for a multi-step sequence — for example, sending a softer "heads up" on day one, a more direct "action required" on day three, and a final "your access is about to cancel" on day seven.
• You cannot segment messages based on customer type, subscription tier, or account history.
• Integrating the failure event into other tools — your CRM, a Slack alert for your team, a support ticket — requires custom code or a middleware tool.

This is precisely the gap that Make (formerly Integromat) fills without requiring a developer.

The Make Stripe Email Workflow: Architecture Overview

The core scenario in Make follows this logic:

1. Stripe fires a webhook event when a payment fails.
2. Make receives the webhook and parses the relevant data (customer email, amount, subscription ID, failure reason).
3. Make sends an immediate first email through your email provider of choice (Gmail, SendGrid, Mailgun, Postmark, etc.).
4. Make schedules or triggers follow-up steps on a delayed basis to send subsequent emails in the sequence.

For a complete sequence, you will build either one scenario with delays built in, or a series of linked scenarios that hand off to each other using Make's scheduling or data store features.

Step 1: Set Up the Stripe Webhook

In your Stripe dashboard, navigate to Developers → Webhooks and add a new endpoint. The endpoint URL will be the webhook URL that Make provides when you create a new webhook trigger module.

The events you need to listen for:

• invoice.payment_failed — fires every time a payment attempt on a subscription invoice fails. This is your primary trigger.
• customer.subscription.deleted — fires when a subscription is fully cancelled after exhausting retries. Useful for a final recovery or offboarding email.
• invoice.payment_succeeded — fires when payment eventually succeeds, which lets you stop the dunning sequence and send a confirmation.

Start with invoice.payment_failed for the initial build.

Step 2: Create the Make Scenario

In Make, create a new scenario and add a Webhooks → Custom webhook trigger module. Copy the webhook URL it generates and paste it into your Stripe webhook endpoint configuration. Send a test event from Stripe to confirm the connection.

Once Make receives the test payload, it will map all the fields automatically. The data you will use most often from the invoice.payment_failed event:

• customer_email — where the email goes
• customer_name — for personalization
• amount_due — the amount that failed, in cents (divide by 100 for display)
• lines.data[0].description — the subscription plan name
• next_payment_attempt — when Stripe will retry automatically, if at all
• last_payment_error.message — a human-readable failure reason you may or may not surface to the customer

Step 3: Send the First Email

Add your email module — SendGrid, Postmark, Gmail, or whatever you use — and map the parsed fields into the email template. A few principles for the first email in the sequence:

Keep the tone informational, not accusatory. The customer almost certainly did not realize the payment failed. Assume good intent.

Include the specific amount and subscription name. Vague emails ("there was a problem with your account") perform worse than specific ones ("your payment of $49 for the Professional plan didn't go through").

Give a single clear action. Link directly to your billing portal or the customer's payment update page. Stripe provides a hosted billing portal you can link to, or you can send a Stripe Customer Portal link generated via the API.

Tell them what happens next. If Stripe will retry in 3 days, say so. If the subscription will cancel if not resolved by a specific date, say that too. Customers respond better when they understand the stakes without feeling threatened.

Step 4: Build the Follow-Up Sequence

For a multi-step sequence, you have two practical approaches in Make:

Option A: Use Make's built-in delay module. After the first email module, add a Sleep module set to your desired interval (24 hours, 48 hours, etc.), then add a second email module. This works but ties up your Make scenario's execution slot for the full duration, which can affect your operation count.

Option B: Use a data store plus a scheduled scenario. When the webhook fires, write the customer's data and a timestamp to a Make data store. Run a separate scenario on a schedule (every few hours) that reads the data store, checks which customers are due for which email in the sequence, sends the appropriate email, and updates their status in the store. This approach is more efficient for higher volumes and gives you better visibility into where each customer is in the funnel.

For most SMBs starting out, Option A is fine. For businesses processing hundreds of failed payments per month, Option B scales more gracefully.

Step 5: Close the Loop on Recovery

Add a second scenario triggered by invoice.payment_succeeded that checks whether a customer currently has a pending dunning sequence (via your data store or a tag in your CRM) and cancels it. Nothing undermines customer trust like continuing to send "please update your payment" emails after the customer already fixed it.

A recovery confirmation email — "You're all set! Your payment went through and your subscription is active." — is a small touch that leaves customers feeling good rather than confused.

What to Put in Each Email

A practical three-email sequence for soft declines:

Email 1 (same day as failure): Friendly heads-up. Specific amount and plan name. Direct link to update payment method. Note that Stripe will retry on a specific date. Tone: helpful, not alarming.

Email 2 (day 3, before the next retry): Slightly more direct. Remind them that a retry is coming and updating the card beforehand will ensure no interruption. Include the same update link. Optionally include a brief FAQ — "Why did this happen? Common reasons include..." — to reduce friction for confused customers.

Email 3 (day 5 or 6, final notice before cancellation): Clear, specific, honest. "Your subscription will cancel on [date] if payment is not resolved." Provide the update link. Optionally offer a way to contact support if there's a billing dispute or a different issue. Keep the tone firm but not hostile — you still want this person to be a customer.

Segment by Subscription Tier When Possible

If your product has multiple tiers, consider routing high-value accounts through a slightly different path. For example, a hypothetical SaaS might handle enterprise accounts by also triggering a Slack notification to the account manager in addition to the automated emails, ensuring a human touches base if the automated sequence doesn't resolve the issue. Make's router module makes this easy to implement without duplicating your entire scenario.

Common Mistakes to Avoid

Not filtering by subscription status. If you have one-time payment customers and subscription customers in Stripe, make sure your scenario only fires the dunning sequence for subscription invoices. Use a filter module after the webhook trigger to check the invoice type.

Forgetting time zones. If you are sending follow-up emails at specific times of day, factor in the customer's time zone where you have it, or default to a reasonable sending window rather than accidentally emailing at 3 AM local time.

Sending too many emails too fast. Two emails in 48 hours is reasonable. Five emails in a week feels like harassment and may prompt the customer to cancel on purpose even after the payment issue is resolved.

Not testing the full sequence end to end. Use Stripe's test mode and a personal email address to run the entire sequence before going live. Check every link, confirm the merge fields populate correctly, and make sure the cancellation logic fires on payment success.

Maintaining the Workflow Over Time

A Make scenario is not a set-it-and-forget-it system, but it is close. Plan to revisit it when:

• Stripe changes its webhook payload structure (rare but it happens).
• You change your subscription tiers or pricing.
• Your email deliverability metrics suggest a template needs refreshing.
• You add new customer segments that warrant different messaging.

Building this in Make rather than custom code means any reasonably technical team member can audit and adjust it without touching a codebase.

Conclusion

Involuntary churn — customers who leave not because they wanted to but because a payment failed silently — is one of the most recoverable forms of revenue loss in a subscription business. A well-built Make scenario that automates Stripe failed payment emails with Make is a durable, low-maintenance solution that works while you sleep. The investment to build it is a few hours. The payoff is ongoing.

If you want help designing and building this workflow for your business — or connecting it to your CRM, support platform, and analytics stack — schedule a conversation about your workflow to talk through what the right setup looks like for your specific situation.