n8n + Stripe: Automate Failed Payment Recovery Emails

01 May 2026 — 4 min read

Failed payments are silent revenue killers. A card expires, a bank flags a transaction, a customer switches accounts — and unless something automatically follows up, that recurring revenue just disappears. Most SaaS businesses lose 5–15% of MRR to involuntary churn caused by payment failures. The fix isn't a better pricing page. It's a reliable recovery sequence that triggers the moment a payment fails.

This is exactly where n8n and Stripe work well together. Stripe already captures every payment event in real time. n8n gives you the infrastructure to act on those events without writing a payment recovery system from scratch.

How Stripe Surfaces Failed Payment Data

Stripe emits a webhook event every time a charge fails. The two most relevant events for recovery workflows are:

invoice.payment_failed — triggers when a subscription invoice can't be collected. Includes the customer ID, invoice ID, amount due, and failure reason.
charge.failed — fires on any failed charge attempt, including one-time payments.

Each event payload contains everything you need: the customer's email (via the customer object), the amount, the failure code, and the next retry timestamp. You don't need to query Stripe again — the data is already in the webhook body.

Inside n8n, you set up a Webhook node as the trigger, point the Stripe webhook at it, and parse the incoming JSON. From there, the workflow branches based on what you want to do — send an email immediately, wait 24 hours and send a second one, or escalate to a human after three failed attempts.

Building the Recovery Sequence

A functional failed payment recovery workflow has three stages: detect, delay, and act. Here's what each stage looks like in n8n:

Detect: The Webhook node receives the Stripe event. A Switch node checks the event type and routes invoice.payment_failed to the recovery branch. Other events are either ignored or sent to a separate flow.
Enrich: An HTTP Request node calls the Stripe API to fetch the full customer object if the webhook payload doesn't include the email directly. You only need the customer ID from the event — Stripe returns the rest.
Act: An Email node (SMTP, SendGrid, or Postmark) sends the first recovery email. The subject line, body, and update link are populated with data from the Stripe payload.

For a multi-touch sequence, you add a Wait node between emails. Set it to 24 or 48 hours, then chain a second email node. n8n handles the execution state — if the workflow is paused at a Wait node, it resumes automatically when the timer expires. No cron job required.

What to Include in Recovery Emails

Recovery emails have one job: get the customer to update their payment method before they churn. The copy should be short, clear, and friction-free. Here's what works:

Email 1 (immediate): "Your payment didn't go through." Include the amount, a one-sentence explanation (card declined, expired, etc.), and a direct link to the billing portal. No fluff.
Email 2 (24–48 hours later): Remind them that access will be suspended. Restate the update link. Some teams include a deadline here — "update by [date] to avoid interruption."
Email 3 (final, optional): "We're about to cancel your subscription." This one drives urgency without being aggressive. Include the exact cancellation date.

In n8n, you can personalize each email dynamically using expressions. The customer's name, the subscription plan, the amount due — all of it comes from the Stripe webhook payload and can be injected directly into the email body using double-curly-bracket syntax.

Handling Edge Cases

A production-grade recovery workflow needs to handle a few scenarios that a simple email sequence misses:

Stripe retries: Stripe automatically retries failed invoices on a schedule you define in the dashboard. Your workflow should check whether the invoice was already paid before sending the second or third recovery email — otherwise customers get dunning emails after they've already updated their card.
Duplicate webhooks: Stripe can send the same event more than once. Add a deduplication step using the event ID stored in a database or a simple Google Sheet lookup node.
Billing portal links: Generate a Stripe billing portal session via API inside the workflow and embed the session URL directly in the email. This skips the login step for the customer and removes the biggest drop-off point in the recovery funnel.

None of this requires custom code. Everything described above can be wired together visually in n8n using built-in nodes — HTTP Request, Switch, Wait, Email, and a database or spreadsheet node for deduplication.

If you'd rather start with a working implementation than build from scratch, there are ready-made n8n templates that cover the Stripe recovery flow and other business-critical automations — already structured, tested, and ready to connect to your own Stripe account.

Failed payment recovery is one of the highest-ROI automations a subscription business can implement. The events are already there in Stripe. The tools to act on them are available in n8n. The only remaining step is connecting the two — and the workflow described here gives you a working starting point to do exactly that.