n8n Stripe Automation: Beyond Payment Notifications

Most Stripe Integrations Listen for One Event

The typical Stripe-and-n8n tutorial wires up payment_succeeded, posts a celebratory Slack message, and stops. That covers the happy path and ignores every event that actually costs you money: the failed charge that quietly churns a customer, the subscription cancellation nobody followed up on, the dispute that needed a response within days.

n8n Stripe automation done properly listens to the whole event surface. A single verified webhook receives every Stripe event, a Switch routes each type to its own handler, and failed payments, churn, and disputes each trigger a real response instead of falling through.

And before any of that: verify the signature. An unverified webhook endpoint is a hole anyone can post forged payment events into.

What You Can Automate

• Failed-payment dunning: catch invoice.payment_failed, email the customer, retry, escalate
• Churn response: a customer.subscription.deleted event triggers a winback sequence and a CRM flag
• Dispute alerts: a charge.dispute.created event pings the team fast, while there's still time to respond
• New-customer onboarding: checkout.session.completed kicks off provisioning and a welcome flow
• CRM sync: every relevant event updates the customer record in HubSpot or your database
• Signature verification: every inbound webhook checked against the endpoint secret before processing

The Stripe Event Pipeline

One endpoint in, many handlers out:

Webhook (Stripe events, raw body)
  → Code (verify Stripe-Signature HMAC, stop if invalid)
  → Switch (route on event.type)
      → invoice.payment_failed       → dunning branch
      → customer.subscription.deleted → churn branch
      → charge.dispute.created        → dispute alert
      → checkout.session.completed    → onboarding branch
  → HubSpot / Postgres (update customer record)

Verify first, route second, act third. The verification node is non-negotiable, and it has to come before anything reads the payload as trusted.

1. Receive

A single Webhook node receives all Stripe events. Configure one Stripe endpoint pointing at it and subscribe to the events you handle. One endpoint is easier to secure and reason about than five, and the Switch sorts them out downstream.

2. Verify the signature

This is the step that separates a real integration from a liability. Stripe signs each payload; the Stripe-Signature header carries a timestamp and an HMAC-SHA256 of the raw body using your endpoint secret. A Code node recomputes it and compares:

const crypto = require('crypto');
const sig = $('Webhook').first().json.headers['stripe-signature'];
const raw = $('Webhook').first().json.body;   // raw string body
const secret = $env.STRIPE_WEBHOOK_SECRET;
const parts = Object.fromEntries(sig.split(',').map(p => p.split('=')));
const expected = crypto
  .createHmac('sha256', secret)
  .update(`${parts.t}.${raw}`)
  .digest('hex');
if (expected !== parts.v1) {
  throw new Error('Invalid Stripe signature');
}
return $input.all();

The Webhook node has to pass the raw body for this to work, because re-serialized JSON won't hash to the same value. That mismatch is the single most common reason verification "randomly" fails.

3. Route by event type

A Switch node keyed on event.type sends each event to its handler. Keeping payment_failed, subscription.deleted, and dispute.created in separate branches means each gets logic suited to it, and the execution log shows exactly which path a given event took.

4. Act per event

The dunning branch emails the customer and schedules a retry. The churn branch starts a winback and flags the CRM. The dispute branch alerts the team immediately, because Stripe gives you a limited window to submit evidence and a missed dispute is lost revenue plus a fee.

5. Sync the record

Whatever the event, update the customer's record so support and sales see current billing state. A failed payment that isn't visible in the CRM means a rep upsells a customer whose card just declined.

Implementation Patterns

Pattern 1 — Verify before you trust, always. The unverified webhook is the most common Stripe-in-n8n security mistake. Anyone who learns the URL can POST a fake payment_succeeded and trip whatever it triggers. The HMAC check is ten lines and belongs before the Switch, every time, no exceptions. The execution log won't warn you it's missing; the forged event just sails through.

Pattern 2 — Dunning is a sequence, not a single email. A failed payment isn't a one-shot notification. It's retry the card, email the customer, wait, retry, escalate, then suspend. Self-hosted n8n runs that multi-day sequence for free, where a per-task tool would meter every step of every dunning cycle across your whole customer base.

Pattern 3 — Idempotent handlers. Stripe will occasionally deliver the same event twice; that's expected behavior, not a bug. Store processed event IDs and skip duplicates, or your dunning branch emails the customer twice for one failure. Dedupe on Stripe's event.id, which is stable across redeliveries.

n8n Nodes You'll Use Most

Getting Started

1. Add a Webhook node and configure it to expose the raw request body.
2. Create a Stripe webhook endpoint in the dashboard pointing at the n8n URL.
3. Store the endpoint secret as an environment variable and build the verification Code node.
4. Send a Stripe test event and confirm verification passes for real ones and rejects a tampered one.
5. Add the Switch and one branch at a time, starting with invoice.payment_failed.
6. Wire the CRM sync and the Slack dispute alert.
7. Add event-ID dedupe before going live so redeliveries don't double-fire.

For the subscription side specifically, the Smart Subscription Manager ships the verified-webhook intake with the failed-payment and cancellation branches already wired, so you connect Stripe and your CRM instead of building the event router from scratch.

Failed payments are also a churn signal, so pair this with n8n subscription churn prevention for the winback side of the dunning branch. The mechanics of receiving and securing inbound events generalize beyond Stripe; the n8n webhook automation guide covers the verification pattern for any provider. The Smart Subscription Manager ties the billing events to the retention playbook in one workflow.