A failed payment is a silent revenue leak, not a support ticket. Here's how to send failed payment alerts to Slack, which Stripe event to use, and what to do when one fires.
Sending failed payment alerts to Slack is the difference between catching a dropped card in real time and finding out weeks later that a paying customer quietly churned. The fastest way to do it is a purpose-built Stripe-to-Slack tool: connect Stripe with read-only OAuth, connect Slack, and every failed charge posts to the channel you choose — in plain English, with the amount, the customer, and the decline reason. This guide covers why failed payments matter more than most founders think, the exact Stripe event behind them, how to set alerts up, and what to actually do when one fires.
Why this matters
Involuntary churn — customers who lose a subscription because a payment failed, not because they chose to leave — accounts for 20–40% of all subscription churn, and more than half of subscriber losses in many B2C categories. The customer never decided to go. If you catch it fast, most of it is recoverable.
When a card fails, nothing dramatic happens on the surface. There's no angry email, no cancellation click, no exit survey. The charge just... doesn't go through. Stripe starts its retry clock, and if every retry fails, the subscription cancels itself. The customer wanted to keep paying you — they simply never knew there was a problem, and neither did you.
That's what makes it a silent revenue leak. A typical subscription business loses roughly 6–12% of ARR every year to involuntary churn. Fixing it can lift revenue around 9% in the first year, which makes failed-payment recovery one of the highest-leverage retention investments a small team can make. And because these customers didn't intend to leave, 60–80% of failed payments are theoretically recoverable.
The catch: businesses relying only on automated tools typically recover ~35–40% of failed payments (real-world B2C numbers can be as low as 25–35%). The gap between what's recoverable and what actually gets recovered is money that leaves quietly, one card at a time. Speed is the whole game — which is why an alert that lands in Slack the moment a payment fails beats a weekly report every time.
20–40%
of subscription churn is involuntary
6–12%
of ARR lost yearly to failed payments
60–80%
of failed payments are recoverable
When a charge fails, Stripe fires the payment_intent.payment_failed event. Its payload carries the PaymentIntent, including last_payment_error (the decline code and human-readable message), the amount, currency, customer, and payment method. This is the low-level event that tells you a specific attempt just didn't clear — and it's the event ChargeBell listens to for its failed-payment alert.
There's an important nuance worth getting right. For subscription dunning specifically, Stripe's own guidance is to key on invoice.payment_failed, the invoice-level event that carries the subscription, dunning, and retry context (like when the next attempt is scheduled). Both events can fire on a single subscription charge: payment_intent.payment_failed tells you the attempt failed; invoice.payment_failed tells you what it means for the subscription. Think of the payment intent event as the alarm and the invoice event as the dunning workflow behind it.
You don't have to choose
For a real-time Slack alert, payment_intent.payment_failed is what surfaces the failure instantly. If you're building a full dunning system yourself, you'll also want invoice.payment_failed for the retry schedule. A dedicated alert tool handles the event plumbing so you don't wire webhooks by hand — see how to get Stripe payment notifications in Slack for the broader picture.
Curious why the card failed? The most common cause by far is insufficient funds — around 40% of failures in one analysis of five million failed subscriptions. Next come expired or replaced cards, do_not_honor declines, and technical or processor errors. Knowing the decline code shapes your response: insufficient funds usually resolves itself on retry, while a replaced card needs the customer to update their details.
You have two broad paths: build it yourself with webhooks, or use a tool built for exactly this. The DIY route means standing up an endpoint, verifying signatures, parsing payment_intent.payment_failed, formatting a Slack message, and maintaining all of it forever. ChargeBell does that job as a product. Here's the setup, start to finish.
Create your ChargeBell account
Sign up at app.chargebell.com/signup. The free plan covers 100 alerts a month with no card required — plenty to prove out failed-payment alerts.
Connect Stripe (read-only)
One-click Stripe Connect OAuth, read-only. ChargeBell can see payment events but can never move money, issue refunds, or change anything in your account.
Connect Slack and pick a channel
Add the app via Slack OAuth and choose where alerts land. Route failed payments to a channel your team actually watches — #founders or #billing, not a firehose nobody reads.
Turn on the payment failed alert
The payment failed alert (⚠️) is on by default. Confirm it's enabled and, if you like, send failures to a dedicated channel while wins go elsewhere.
Send a test alert
Fire a test to confirm the wiring before a real card drops. You'll get your first alert before your coffee cools.
If you'd rather validate the underlying event locally first, you can test it with the Stripe CLI: run stripe listen --events payment_intent.payment_failed --forward-to localhost:PORT/webhook, then stripe trigger payment_intent.payment_failed to fire a synthetic failure. That's useful when you're building custom handlers; with ChargeBell, the built-in test alert covers the same confidence check without any code.
A good alert answers the questions you'd otherwise open the Stripe dashboard to check: how much, who, why, and what happens next. ChargeBell writes that message for you — no raw webhook JSON, no customer IDs you have to look up.
⚠️ @channel A payment didn't go through — $96.00
Kai at Driftbase · card declined (insufficient_funds)
Stripe will retry automatically — worth keeping an eye on
View in Stripe
For a repeat failure on a high-value account, the stakes are higher, and the alert should make that obvious:
⚠️ @channel Failed payment — $249.00 · Acme Corp (annual plan)
Card declined: do_not_honor · this is their 2nd failed attempt
If retries fail again the subscription cancels — worth a personal email now
View customer in Stripe
The message quality is the point. Instead of decoding a decline code from a webhook payload, your team reads a plain-English line that already includes the numbers that matter: the amount, the customer name Stripe provided, the decline reason, and a nudge on what to do. That's the difference between an alert that gets acted on and one that gets ignored.
Most alerts can wait until morning. A failed payment can't — every hour inside Stripe's retry window is an hour you could have spent reaching out. So ChargeBell marks the payment failed alert (and disputes) as CRITICAL, and critical alerts behave differently from routine ones in two specific ways.
@channel so the whole team sees it, not just whoever happens to be scrolling. You saw that in the mockups above.The rest of ChargeBell's controls still keep the noise down. A minimum payment threshold means tiny charges don't clutter the channel, per-alert routing sends failures to the people who handle them, and supersession means you get one alert per event, not a pile-up. If you want to tune this further, how to avoid noisy Stripe notifications walks through the settings.
An alert is a prompt, not the whole answer. The right response depends on the account and the decline reason. Here's a simple playbook.
✅ Recovered — $96.00 from Kai at Driftbase
Second retry went through · no action needed
Originally failed Tuesday
Stack your interventions
Retries alone leave money on the table. The highest recovery rates (~70%) come from stacking three things: smart retry logic, dunning email sequences, and a card-updater service. The Slack alert is your trigger for the human half of that stack — the personal outreach that automated retries can't do.
One more reason speed pays off: subscriptions that were about to churn for involuntary reasons but get recovered continue for roughly 7 more months on average. Catching a failed payment fast doesn't just save one charge — it saves the whole customer relationship. If you want to formalize the team response, see how to build a payment incident workflow in Slack.
| Criterion | ChargeBell | Custom webhook code |
|---|---|---|
| Listens to payment_intent.payment_failed | ||
| Works out of the box | ||
| Plain-English message (amount, customer, decline reason) | ||
| Critical alerts bypass quiet hours | ||
| @channel on critical alerts | ||
| Payment recovered alert when a retry clears | ||
| You maintain webhooks and signature checks | ||
| Setup time | ~2 minutes | Days, then upkeep |
| Cost | Flat $24/mo | Engineering time |
Using ChargeBell for failed payment alerts
Strengths
Trade-offs
ChargeBell surfaces the failure and tells you who to contact; Stripe Smart Retries handles automated retry timing; your email tool sends the recovery message. Each does its own job — Stripe stays the source of truth, and ChargeBell keeps you looking at Slack instead of the dashboard. See how to monitor Stripe without checking the dashboard.
Key takeaways
Connect Stripe and Slack, keep the payment failed alert on, and send a test. Free plan, no card required.
Stripe sends payment_intent.payment_failed when a charge attempt fails. The payload includes last_payment_error (the decline code and message), the amount, currency, customer, and payment method. For subscription dunning specifically, Stripe recommends also handling invoice.payment_failed, which carries the retry and subscription context. ChargeBell listens to payment_intent.payment_failed to send its failed payment alert.
In real time. As soon as Stripe reports the failed charge, ChargeBell posts to your chosen Slack channel. Because failed payments are marked CRITICAL, the alert bypasses any quiet hours you've set — so a dropped card at 2am still reaches you immediately, giving you the whole retry window to respond.
Yes — they do different jobs. Smart Retries handles automated retry timing (8 attempts over 2 weeks by default) and is enabled by default in your Stripe Dashboard. Alerts tell a human that a payment failed so you can reach out personally on the accounts retries won't save. Retries alone recover only ~25–40%; stacking retries, dunning emails, and personal outreach can reach ~70%.
No. ChargeBell connects to Stripe read-only, so it can see the failed payment and alert you but can never move money, retry a charge, or edit anything. Stripe Smart Retries handles automated retries, and your email tool (or Stripe's dunning emails) contacts the customer. ChargeBell's job is to make sure you never miss the failure.
Insufficient funds is the leading cause — roughly 40% of failures in one large analysis. Other common reasons are expired or replaced cards, do_not_honor declines, and technical or processor errors. ChargeBell includes the decline reason in the alert so you know whether to wait for a retry (insufficient funds often clears on its own) or ask the customer to update their card.
ChargeBell's free plan covers 100 alerts a month with 7-day history and no card required — enough to run failed-payment alerts for most small teams. Pro is a flat $24/month (or $240/year) for unlimited alerts, daily and weekly digests, and full history. There's no per-event billing, so a bad month for failed cards never costs you more.
There are three free ways to pipe Stripe payments into Slack, and each stops at a bare 'you got paid' message. Here's how each works — and the fast path to alerts that actually show net, customer, and MRR.
July 6, 2026
A Stripe alert in Slack is useless without a response process. Here's a copy-pasteable, lightweight incident workflow — detect, triage, assign, resolve — that lives in one channel.
July 6, 2026
You don't need another dashboard. You need the handful of Stripe events that actually move the business pushed into Slack — new subs to celebrate, failed payments to save. Here's the setup.
July 6, 2026