# Payment failed emails for SaaS: what to send, and how to trigger them

> A payment failed email tells a customer their charge was declined and how to fix it. What to say, when to send three emails, and how to trigger them.

Source: https://behavly.io/guides/payment-failed-emails · Updated October 31, 2026

A payment failed email tells a customer that their latest subscription charge didn’t go through, and gives them the one step that fixes it, usually updating their card. For a SaaS business it is how you keep customers who never decided to leave: their card expired, was replaced or hit its limit, and nobody told them. A good one reads like a heads-up from someone on your team, says plainly what happens next, and stops the moment the payment goes through.

Failed payments are the clearest case of [behavioral email](https://behavly.io/guides/behavioral-email): one event starts the emails and another one ends them. They also sit on one side of the split between [involuntary vs voluntary churn](https://behavly.io/guides/churn-prevention-emails). A customer whose card failed made no decision, while a customer whose usage has been falling for a month may be making one, and the two need different emails. Involuntary churn is the smaller share, but not a small one: Recurly’s [churn benchmarks](https://recurly.com/research/recurly-research-metrics-report-churn), updated with July 2026 data from its network, list an average involuntary churn rate of 1.25% beside 2.34% for voluntary churn.

#### Why do SaaS payments fail?

The reason decides what the email should ask for. If your payment provider tells you why a charge was declined, pass that along with the event.

| Why it failed | What the customer needs to do | What the email should say |
| --- | --- | --- |
| The card expired | Add the new expiry date or a new card | Which card failed (brand and last four digits) and a direct link to update it |
| Not enough funds, or the card’s limit was reached | Wait for the retry, or use another card | When the next retry happens, so they can switch cards before it |
| The card was replaced after a loss or fraud | Add the new card | That nothing is wrong with their account; only the card on file changed |
| The bank flagged the charge as unusual | Approve it with their bank, then retry | The amount, and the name the charge appears under on their statement |
| The bank needs extra confirmation (3D Secure) | Confirm the payment | A link to the confirmation page; a new card won’t help |
| The card belongs to someone else, like a finance team | Forward the request | Something they can forward, with the amount and an invoice option |

Many billing systems also retry a failed charge on their own; Stripe’s [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries) choose the retry times for you, and Stripe’s recommended default is 8 tries within 2 weeks. Fit the emails inside that window, so the last one arrives before the final attempt rather than after the subscription has already lapsed. Some failures clear on a retry and others never will, so the emails run alongside the retries rather than replacing them, and stop as soon as one succeeds.

#### What should a payment failed email say?

- **What failed, in numbers.** The plan, the amount, the date. “Your €49 payment for Studio didn’t go through” leaves nothing to ask.
- **One link, straight to the payment details.** Not the dashboard, and not a login page if you can avoid it. Every extra step is a place to stop.
- **What happens next, with dates.** When you will retry, and what changes if every retry fails. Say it once, plainly.
- **What they would lose, in their own work.** A customer who used your product this week has projects, reports or clients at stake. Naming them persuades better than any warning, and it is the part of the email that depends on what they did.
- **A person to reply to.** Some customers need an invoice, a different currency or a word with their finance team. A reply-able address catches those.
- **No blame, no threats.** “Your bank declined the charge” is accurate and accuses nobody. “Your account will be suspended” in the first email reads as hostile to someone who simply has a new card.

#### When should each failed payment email go out?

Three emails cover most cases, spaced around your retry schedule and cancelled the moment the payment goes through.

| Email | When | What it does |
| --- | --- | --- |
| 1. The heads-up | Soon after the payment fails, in their working hours | What failed, when the retry is, one link to update the card |
| 2. The reminder | About 3 days later, if it still hasn’t gone through | What’s at stake in their own account, and an offer to help |
| 3. The last notice | A day or two before the final retry, or before access changes | The date, what changes, what stays saved, and the link once more |

If they pay at any point, the path ends. If they reply, a person answers. If their payment fails again next month, that is a new case with its own three emails. And if every retry fails and the subscription ends, they are a former customer now: the emails that [win back cancelled users](https://behavly.io/guides/win-back-inactive-users) take over from there.

#### Payment failed email templates

These are for Larkspur, a made-up project-tracking tool for small agencies, on its €49-a-month Studio plan. Marco’s card is declined on a Monday, and Larkspur retries on Thursday.

Email 1: the day the payment fails

> Subject: Your Larkspur payment didn’t go through
>
> Hi Marco,
> 
> We tried to charge €49 for your Studio plan this morning, and your bank declined it. Nothing has changed in your workspace, and we’ll try the card again on Thursday.
> 
> If the card has expired or been replaced, updating it takes a minute, and we’ll retry as soon as you save it.
> 
> Update your card: [link]
> 
> Aisha

Email 2: after the retry, written from what the team did

> Subject: Your Studio payment and your four client projects
>
> Hi Marco,
> 
> Thursday’s retry for your Studio payment didn’t go through either. I’m flagging it now because your team logged 46 hours across four client projects this week, and those projects need Studio to stay active.
> 
> If someone else looks after billing at Northgate, you can forward this email to them; the link works without a Larkspur login.
> 
> Update the payment details: [link]
> 
> Aisha

Email 3: before the last retry

> Subject: Last retry for your Studio plan on the 14th
>
> Hi Marco,
> 
> Your Studio payment is still open, and our last retry is on Monday the 14th. If it doesn’t go through, your workspace moves to Solo: every project and time log stays, but only three projects remain active until the card is updated.
> 
> If an invoice would be easier for your accountant, reply and I’ll set one up.
> 
> Update your card: [link]
> 
> Aisha

#### How do you trigger a payment failed email from Stripe?

Behavly doesn’t connect to Stripe. The event comes from your own server: Stripe calls your webhook, and your handler sends Behavly the event. Stripe’s [subscription webhooks](https://docs.stripe.com/billing/subscriptions/webhooks) include `invoice.payment_failed`, sent when a payment for an invoice fails, and `invoice.paid`, sent when an invoice is paid. Relay the first as `payment_failed` and the second as `payment_succeeded`:

```javascript
// In your Stripe webhook handler, after verifying the signature.
const behavlyEvent = {
  "invoice.payment_failed": "payment_failed",
  "invoice.paid": "payment_succeeded",
}[event.type];

if (behavlyEvent) {
  const invoice = event.data.object;
  await fetch("https://behavly.io/api/v1/send_event", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.BEHAVLY_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      event: behavlyEvent,
      email: invoice.customer_email,
      properties: {
        amount: invoice.amount_due / 100, // Stripe amounts are in the smallest unit, like cents
        currency: invoice.currency.toUpperCase(),
        attempt: invoice.attempt_count,
      },
      // Stripe can deliver an event more than once; its id makes the retry count once.
      idempotency_key: event.id,
    }),
  });
}
```

- **Duplicates are handled.** Stripe’s docs note that a [webhook endpoint can receive the same event more than once](https://docs.stripe.com/webhooks). With Stripe’s event id as the `idempotency_key`, Behavly counts each one once.
- **Every paid invoice sends `invoice.paid`,** renewals included, and each event your server sends counts toward your plan’s monthly product events. To save them, send `payment_succeeded` only for customers with an open failed payment.
- **One sender per decline.** Stripe can also [email customers after a failed card payment](https://docs.stripe.com/billing/revenue-recovery/customer-emails) itself. If you send your own, turn that setting off so nobody gets two emails about one decline.

For the request’s other fields, retries and testing, see how to [send payment_failed as an event](https://behavly.io/guides/trigger-emails-from-product-events).

#### How to run payment failed emails in Behavly

In Behavly, a Trigger Campaign does the waiting, the checking and the stopping, so your webhook handler only has to report what happened. Here is how to [start a path from payment_failed](https://behavly.io/features/triggers):

1. **Make two triggers.** In **Triggers**, click **New trigger** and name it Payment failed; the key follows (`payment_failed`). Under **Payload**, add `amount` (number), `currency` (text) and `attempt` (number). Then make a second one, Payment succeeded (`payment_succeeded`).
2. **Send them from your webhook handler** with a key that has **Send events only** access, created in **Settings → API**. That key can send events and nothing else.
3. **Start the campaign.** **Create an Agent**, on the Payment failed trigger’s page, opens a Trigger Campaign that already starts on it. Under **Describe the path**, write something like “Three emails about a failed payment: a heads-up right away, a reminder after 3 days about what their team is working on, and a last notice 4 days later”, choose **Build the path**, and check the emails and waits it lays out.
4. **Treat each failure as a new case.** Set **If it happens again** to **A new case each time**. A repeat while the problem is open is noted on the path and never starts it over, and once they have paid, the next failure starts a new path at once. A campaign set this way is **Urgent** under **Priority across campaigns**, so its emails never wait for the Agent guardrails that space out your other campaigns.
5. **Make paying the goal.** Under **Goal**, pick `payment_succeeded` and turn on **They reach the goal** under **Leave when**. Whoever pays leaves the path at once, whatever step they are on, and Behavly credits the payment to the last email they got before it.
6. **Send the billing facts exactly.** For the first and last email, use an **Email** step with one of your templates and **Send as designed**. In the template, `{{event.amount}} {{event.currency}}` reads `49 EUR`, filled in from the event that started the path. Templates sent as designed don’t use your plan’s personalized emails.
7. **Let Behavly write the middle one.** Make the second email a **Behavly Agent** step, with **Instructions for Behavly Agent** such as “Say the payment is still open and name what their team has worked on this week. No pressure, one link to update the card.” Each one is written for that customer from their own activity.
8. **Read before it sends.** **Preview** writes the step for a real customer, **Send the path to me** delivers all three emails to your inbox, and **Hold Behavly-written emails for approval** keeps the written one until you release it. Before your code is live, **Send a test event** to your own address starts the path for real.

Emails go out from your own mailbox, connected in **Settings → Email**, inside the **Sending window**: Monday to Friday, 9:00 AM to 6:00 PM in each person’s timezone, by default. A reply ends the path and lands in the **Unibox** with that customer’s activity beside it, so a person can answer the “can I pay by invoice?” questions.

_Payment failed, live in **Triggers**, with the campaign it starts and the events received in the last 14 days._

## Questions

### What should a payment failed email include?

What failed (plan, amount and date), what happens next and when, and one link straight to updating the payment details. Send it from an address a person reads, and leave out threats.

### How many failed payment emails should you send?

Usually three: one soon after the failure, a reminder a few days later, and a last notice before the final retry or before access changes. Stop the moment the payment succeeds or the customer replies.

### Does Behavly connect to Stripe?

No. Your server receives Stripe’s `invoice.payment_failed` and `invoice.paid` webhooks and sends Behavly `payment_failed` and `payment_succeeded` events. The same works with any billing system that tells your server about failed and successful charges.

### What if a customer’s payment fails again next month?

With **If it happens again** set to **A new case each time**, a repeat while the first case is open is noted on their path and never starts it over. Once they have paid, the next failure starts a new path at once.

### Is a payment failed email the same as a dunning email?

Yes. Dunning is the billing term for the emails that ask a customer to settle a failed or overdue payment; in SaaS, that mostly means the emails that follow a declined card.

## Related

- [Event-triggered emails from your product’s API](https://behavly.io/features/triggers)
- [Behavioral email for SaaS: the practical guide](https://behavly.io/guides/behavioral-email)
- [Churn prevention emails: what to send when usage drops](https://behavly.io/guides/churn-prevention-emails)
- [Win-back emails for inactive SaaS users](https://behavly.io/guides/win-back-inactive-users)