Invoice and Payment Automation: Stripe + Notifications

If you sell subscriptions, products, or services online, the post-payment workflow is almost entirely automatable. Stripe processes the payment and fires a webhook. Your automation platform catches the webhook and handles everything downstream — sending a receipt, provisioning access, notifying you in Slack, updating your accounting records. The payment itself is already automated by Stripe. This article covers the part that happens after the money moves: the notifications, the access provisioning, the record-keeping, and the failure handling that keeps your operation running without requiring you to check a dashboard every morning.

What The Docs Say

Stripe's webhook documentation is among the best in the industry — clear, comprehensive, and honest about edge cases. Stripe fires webhook events for nearly every state change in the payment lifecycle: checkout.session.completed when a customer finishes a payment, customer.subscription.created when a new subscription starts, invoice.paid when a subscription invoice is successfully charged, invoice.payment_failed when a charge attempt fails, and customer.subscription.deleted when a subscription is canceled. Each event includes a JSON payload with the full object data — customer details, payment amount, subscription metadata, invoice line items.

Ghost's documentation describes its native Stripe integration — Ghost uses Stripe Connect to handle membership payments, and the member lifecycle events (signup, upgrade, cancellation) are managed within Ghost's own member management system. The Ghost-Stripe integration is tight enough that for basic membership payments, Ghost handles the downstream actions (member access provisioning, receipt emails) without external automation.

n8n and Zapier both document Stripe trigger nodes that listen for webhook events and pass the payload into your workflow. The documentation shows clean examples: Stripe payment event triggers a workflow that sends an email, creates a spreadsheet row, and posts a Slack notification. Three nodes, five minutes of setup, done.

What Actually Happens

The Stripe webhook system works exactly as documented. I want to be clear about that because so much of automation involves "the docs say X but reality is Y." Stripe webhooks fire reliably, the payloads are well-structured, and the event types are granular enough to handle any downstream logic you need. Stripe also handles webhook delivery failures with automatic retries — if your endpoint is temporarily down, Stripe will retry with exponential backoff for up to 72 hours. This is the most reliable trigger source I work with, and it's not close.

Ghost's native Stripe integration handles the basics well. When someone subscribes to your Ghost publication and pays through Stripe, Ghost automatically provisions their membership access, sends a welcome email, and manages the subscriber record. For publishers running Ghost memberships without additional products or services, Ghost's built-in handling may be sufficient. The automation layer becomes necessary when you need actions Ghost doesn't handle natively — Slack notifications for new payments, custom receipt formatting, spreadsheet logging, or access provisioning for non-Ghost products.

Here's the workflow I run for a Ghost publication with paid memberships. Stripe fires a webhook for every payment event. An n8n workflow receives the webhook, validates it using Stripe's webhook signature verification (skipping this step is a security risk — anyone could send fake webhook payloads to your endpoint), and then routes the event based on type. The routing is a Switch node in n8n that branches on the event type:

For checkout.session.completed (new subscription): The workflow sends a Slack notification to my payments channel with the customer email, subscription tier, and amount. It adds a row to a Google Sheet that serves as a transaction log with timestamp, customer, amount, and subscription type. Ghost handles the access provisioning and welcome email — I don't duplicate that in the automation. The Slack notification is the value here. I know within seconds when someone subscribes, without checking Ghost or Stripe dashboards.

For invoice.paid (recurring subscription payment): Same Slack notification, same spreadsheet row, but no welcome email — this is an existing subscriber's renewal. The notification confirms that recurring revenue is flowing without requiring me to check Stripe. Over time, the spreadsheet becomes a revenue log that's more useful than Stripe's dashboard for quick reference because it includes only my publication's transactions, not the noise of test charges and refunds.

For invoice.payment_failed (failed charge): This is where the automation earns its keep. Stripe's Smart Retries system handles the actual retry logic — Stripe will attempt the charge again using machine learning to optimize the retry timing [VERIFY]. My automation handles the notification: a Slack alert with the customer email, failure reason, and retry status, plus an entry in the spreadsheet marked as failed. I also trigger a separate email to the customer — not the generic Stripe dunning email, but a personal-sounding message from my publication explaining that their payment didn't go through, asking them to update their card, and providing a direct link to their billing portal. This email converts at a higher rate than Stripe's default dunning emails because it comes from the publication rather than "Stripe" and sounds like a human wrote it.

For customer.subscription.deleted (cancellation): Slack notification with the customer email and the cancellation reason if Stripe captured one. Spreadsheet entry. Ghost handles the access revocation automatically through the Stripe Connect integration. I optionally trigger a brief "sorry to see you go" email with a link to resubscribe — this is worth A/B testing because some publishers find it desperate and others find it recovers 5-10% of cancellations.

Invoice Generation

For subscription products, Stripe generates invoices automatically — each recurring charge produces a Stripe invoice with line items, tax if configured, and a PDF receipt that customers can access through their billing portal. This requires zero automation. Stripe handles it, and the invoices are professional and compliant.

Where invoice automation gets interesting is for non-subscription payments — one-time product sales, consulting fees, project-based billing. Stripe Invoicing handles this for simple cases: you create an invoice through Stripe's dashboard or API, send it to the customer, and they pay through a hosted payment page. The automation layer adds value when you want to generate invoices programmatically — for example, when a customer completes a form on your site and the form submission triggers an n8n workflow that creates a Stripe invoice, sends it, and logs the pending payment in your spreadsheet.

For custom invoice formatting or invoices that need to match a specific template (some clients require this), Stripe's built-in invoices may not be sufficient. In that case, n8n can generate a PDF using a template, attach the Stripe payment link, and send it via email — but this is significantly more work to build and maintain than using Stripe's native invoicing. I'd recommend starting with Stripe's built-in invoices and only building custom templating if a client specifically requires it.

The Accounting Sync

Pushing Stripe data to accounting software is the automation that sounds most valuable and is most likely to be over-engineered. The options range from simple to complex.

Google Sheets as accounting ledger — the simplest approach and the one I recommend starting with. Every Stripe event writes a row: date, customer, amount, type (subscription, one-time, refund), and status (paid, failed, refunded). At month-end, the sheet has every transaction in one place. You can sum columns, filter by date range, and export to your accountant. This is not "real" accounting software, but for a solopreneur or small publisher processing fewer than 100 transactions per month, it's more than adequate. The automation takes 10 minutes to build in n8n — a Stripe webhook trigger, a data mapping node, and a Google Sheets append node.

QuickBooks or Xero integration — both connect to Stripe through native integrations or through automation platforms. Zapier has pre-built Stripe-to-QuickBooks zaps that map Stripe charges to QuickBooks income entries. n8n can do the same through the QuickBooks API, though the OAuth setup for QuickBooks is one of the more unpleasant authentication flows in the API world — the token expires every hour, requiring a refresh token flow that needs to run reliably or your sync breaks [VERIFY]. If you're already using QuickBooks or Xero for your business accounting, the integration is worth setting up. If you're not already using them, adding accounting software just to receive Stripe data is over-engineering the problem.

The month-end manual approach — for publishers processing fewer than 20 transactions per month, exporting Stripe's transaction data as a CSV at month-end and handing it to your accountant is faster than building and maintaining any automation. Stripe's export is comprehensive and well-formatted. The manual process takes 5 minutes. The automation takes 2-4 hours to build and requires monthly maintenance to handle API changes and token expirations. The math only works in the automation's favor above roughly 20 transactions per month, depending on how much you value your time versus your accountant's.

Failed Payment Handling in Depth

Failed payments are where most publishers lose revenue without realizing it. A subscription charge fails — the card expired, the bank declined, the customer exceeded their credit limit — and if the recovery process is weak, the subscription churns. Stripe's Smart Retries are the first line of defense and they're effective — Stripe reports a recovery rate of about 15% through Smart Retries alone. But Smart Retries only handle the re-charge attempt. The customer communication is yours to manage.

The automation I run for failed payments is a three-step sequence. First, the immediate notification to me via Slack — I want to know when a payment fails, even if I don't act on it immediately. Second, a personal-sounding email to the customer that goes out within an hour of the failure, before Stripe's own dunning email lands. The email is simple: "Your payment for [publication name] didn't go through. This usually happens when a card expires or a bank flags an unfamiliar charge. You can update your payment info here: [billing portal link]. If you need help, just reply to this email." Third, a follow-up email three days later if the payment is still failed — "Just a quick follow-up — your subscription to [publication name] is paused because we couldn't process your payment. Here's the link to update your card: [billing portal link]. We'd love to keep you as a reader."

This two-email sequence, combined with Stripe's Smart Retries, recovers roughly 30-40% of initially failed payments in my experience. The key is timing and tone — the emails need to arrive quickly and sound helpful rather than threatening. The automation handles the timing; the copywriting handles the tone.

When To Use This

Build this automation if you process any recurring payments through Stripe. Even at low volume — 5-10 subscriptions — the Slack notifications alone are worth the 30-minute setup because they keep you aware of your revenue without checking dashboards. The failed payment handling becomes ROI-positive once you have 20+ active subscribers, because each recovered payment is real revenue that would have otherwise churned.

The full stack — Slack notifications, spreadsheet logging, custom dunning emails, accounting sync — is worth building once you're processing 20+ transactions per month. Below that threshold, the manual process works fine and the automation maintenance isn't justified. Above that threshold, the automation saves meaningful time on bookkeeping and meaningfully improves payment recovery rates.

This is also one of the more satisfying automations to build because the feedback loop is immediate and tangible. You set it up, someone subscribes, your phone buzzes with a Slack notification showing the payment amount. The dopamine of seeing revenue arrive in real-time — without checking any dashboard — is a genuinely good feeling, and it reinforces the habit of building automations that deliver concrete value.

When To Skip This

Skip the accounting sync if you process fewer than 20 transactions per month. Export Stripe's CSV at month-end. Your accountant will be fine.

Skip the custom dunning emails if you're using a platform that handles them well natively. Stripe's built-in dunning emails are adequate — not great, but adequate. The custom email automation is an optimization, not a necessity. If your subscriber volume is low enough that each churn event doesn't materially affect revenue, the default recovery flow is sufficient.

Skip the entire automation if you're not using Stripe. This sounds obvious, but some publishers use Ghost's native Stripe Connect integration and don't have direct Stripe webhook access configured. Ghost handles the basics through Stripe Connect without requiring you to receive webhooks directly. You only need the webhook automation if you want actions that Ghost doesn't provide — Slack notifications, spreadsheet logging, custom emails, accounting sync. If Ghost's built-in handling covers your needs, adding an automation layer for Stripe events is complexity without benefit.

And skip the elaborate invoice templating if nobody has asked for it. Stripe's default invoices are clean, professional, and legally sufficient for most purposes. Building a custom PDF invoice generator in n8n because you want your logo in a different position is a project that takes 4-6 hours and solves a problem that doesn't exist for most solo publishers.

This is part of CustomClanker's Automation Recipes series — workflows that actually run.