Stripe alert

Stripe failed payment alert in Slack

The payment_intent.payment_failed event is involuntary churn in progress. Here's how to turn it into a real-time, CRITICAL Slack alert and what to do next.

Updated July 6, 20266 min read

A Stripe failed payment alert in Slack is a message posted the moment a customer's payment attempt is declined. ChargeBell listens for Stripe's payment_intent.payment_failed event and turns it into a plain-English alert — the amount, the customer, and the decline reason — in the channel your team already watches. Because a failed payment is money actively leaving, ChargeBell marks it CRITICAL: it bypasses quiet hours and can @channel.

What payment_intent.payment_failed means

Stripe describes payment_intent.payment_failed as firing when "a PaymentIntent has failed the attempt to create a payment method or a payment." The event's data.object is the PaymentIntent. Crucially, a failed attempt is not a dead charge: per Stripe's lifecycle docs, when an attempt fails (for example, a card decline) the PaymentIntent's status returns to requires_payment_method so the payment can be retried. Treat the alert as a recoverable failure that needs action, not a permanently lost sale.

For subscription and recurring billing, the parallel event is invoice.payment_failed, which Stripe fires "whenever an invoice payment attempt fails, due to either a declined payment, including soft decline, or to the lack of a stored payment method." Subscription businesses usually want both — see invoice.payment_failed alerts for the recurring-billing side.

Failed payments are involuntary churn

A failed payment isn't a support ticket — it's revenue silently leaking. Involuntary churn (customers lost to failed or declined payments rather than an active decision to cancel) is estimated at 20–40% of all churn for subscription businesses. Much of it is recoverable, which is exactly why speed matters.

20–40%

of all subscription churn is involuntary (est.)

2–3%

of subscribers have a card expire each month (est.)

41% vs 27%

reminder open rate within 24h vs after 30 days

Speed of follow-up measurably improves recovery. Reminders sent within 24 hours see roughly a 41% open rate versus about 27% after 30 days, and front-loaded, multi-channel outreach in the first 72 hours can cut involuntary churn by up to 34% versus email alone. A daily report is too slow for that window — you need the signal in real time.

Why the payment_failed alert is CRITICAL

Most alerts should respect quiet hours — you don't need a 3 a.m. ping about a routine sale. A failed payment is different. ChargeBell classifies the payment failed alert as CRITICAL, which means it bypasses quiet hours and can add an @channel prefix so someone sees it. This is a ChargeBell design choice for money-leaving events, not a Stripe feature: the same treatment applies to disputes.

Not every failure is auto-recoverable

Stripe Smart Retries only auto-retries soft declines. Hard declines like expired_card, lost_card, or stolen_card can't be retried until the customer adds a new payment method — so a human needs to reach out. The alert is how they find out in time.

What a good failed payment alert includes

Raw webhook JSON is useless in Slack. A good alert answers "who failed, how much, why, and do I need to act?" at a glance. ChargeBell surfaces the decline reason and whether Smart Retries can handle it, so the channel knows whether to wait or reach out.

#billing

⚠️

ChargeBellApp

⚠️ Payment failed — $149.00 from acme@example.com

Reason: card_declined (insufficient_funds — soft decline)

Stripe Smart Retries will retry automatically · no action needed yet

#billing

⚠️

ChargeBellApp

⚠️ @channel Payment failed — action needed — $499.00/mo (Pro)

Reason: expired_card (hard decline — Smart Retries can't recover this)

Involuntary churn in progress · reach out to update the card

Fields ChargeBell can include

Amount and currency of the failed attempt
Customer name or email, when Stripe provides it
Decline reason and whether it's a soft or hard decline
A link to open the customer or payment in the Stripe dashboard

How to set up a Stripe failed payment alert in Slack

1
Connect Stripe
One-click, read-only OAuth. ChargeBell can see payment events and can never move money or change anything.
2
Connect Slack and pick a channel
Add the app and choose where failed payments should post — a channel like #billing or #founders works well.
3
Enable the payment failed alert
It's on by default and classified CRITICAL, so it bypasses quiet hours. Turn on the @channel prefix if you want it to page the room.
4
Send a test alert
Confirm the message looks right before your next real decline. You'll get your first alert before your coffee cools.

What to do when a payment fails

Stripe already does a lot of the recovery work for you — treat ChargeBell as the real-time signal layer on top of it, not a replacement.

Let Smart Retries handle soft declines. Stripe's default policy retries up to 8 times within 2 weeks (windows are configurable from 1 week to 2 months). For an insufficient_funds or generic decline, wait — the alert says "no action needed yet."
Contact the customer on hard declines. For expired_card, lost_card, stolen_card, and similar codes, retries can't succeed until a new card is added. Reach out fast — front-loaded, multi-channel follow-up in the first 72 hours is where recovery is won.
Consider an account updater. Card-updater services capture roughly 60–70% of card changes and can cut card-related failure churn by about 25–35% — a complementary lever to real-time alerts.

Why the alert still matters

Stripe's built-in recovery (Smart Retries plus emails) recovers only an estimated 25–35% of involuntary failures automatically. The other two-thirds — especially hard declines — is exactly where a real-time Slack alert plus human follow-up wins.

Want the full playbook? See how to send failed payment alerts to Slack and how to build a payment incident workflow in Slack.

invoice.payment_failed alerts — the subscription-side sibling of this event
Successful payment alerts — the win side of the same signal

Key takeaways

payment_intent.payment_failed fires on a failed attempt; the PaymentIntent returns to requires_payment_method and can be retried.
Failed payments are involuntary churn — an estimated 20–40% of all subscription churn, and largely recoverable.
ChargeBell marks the alert CRITICAL: it bypasses quiet hours and can @channel.
Let Smart Retries handle soft declines; contact the customer fast on hard declines.

Catch failed payments before they become churn

Connect Stripe and Slack, enable the CRITICAL payment failed alert, and send a test. Free plan, no card needed.

Start freeFree plan · no card needed

Frequently asked questions

Which Stripe event fires on a failed payment?

payment_intent.payment_failed. It fires when a PaymentIntent fails its attempt to create a payment method or process a payment — for example, a card decline. The PaymentIntent then returns to requires_payment_method so the payment can be retried. For subscriptions, the parallel event is invoice.payment_failed.

Does the alert bypass quiet hours?

Yes. ChargeBell classifies the payment failed alert as CRITICAL, so it bypasses quiet hours and can add an @channel prefix. Unlike a routine sale, a failed payment is money actively leaving, and speed of response measurably improves recovery.

Do I need to act on every failed payment?

No. Stripe Smart Retries automatically retries soft declines (its default policy is up to 8 tries over 2 weeks), so you can wait on those. Hard declines like expired_card can't be recovered until the customer adds a new card, so those need a human to reach out.

Isn't Stripe's own recovery enough?

Stripe's built-in Smart Retries and emails recover only an estimated 25–35% of involuntary failures automatically. A real-time Slack alert plus human follow-up captures the rest — especially hard declines. ChargeBell is the signal layer on top of Stripe's automation, not a replacement.

Does ChargeBell need write access to Stripe?

No. ChargeBell connects with official read-only OAuth. It can see payment events to build alerts, but it can never retry a payment, move money, or change anything in your Stripe account. Stripe stays the source of truth.