Refunds and disputes touch both finance and support, wins belong to founders, and failed payments are a churn signal. Here's a clean map of which Stripe alert goes to which Slack channel — and who owns it.
Once more than one person cares about Stripe, dumping every event into a single #stripe channel stops working. Disputes get buried, wins get ignored, and nobody feels accountable. The fix is to route Stripe alerts to the right team: finance owns payouts, refunds reconciliation, and disputes; support owns failed payments and customer-facing refund decisions; founders watch wins, MRR, and cancellations. This playbook gives you the exact event-to-channel-to-owner map and how to set it up.
Short answer
Send disputes and payouts to #finance, failed payments and refund requests to #support, new subscriptions, MRR, and cancellations to #founders, and big wins to #wins. Give every alert one named owner so it triggers action, not a shrug. When everyone sees everything, no one acts.
Here's the core of the playbook — a map from Stripe event to Slack channel to the person accountable. The trick is that refunds and disputes touch two teams, so each row names one owner (who has to act) and who's simply kept in the loop. Copy this, rename the channels to match your team, and you have a working routing plan.
| Stripe event | Channel | Owner |
|---|---|---|
| payout.paid / payout.failed | #finance | Finance |
| charge.dispute.created | #finance | Finance (support CC'd) |
| charge.dispute.funds_withdrawn | #finance | Finance |
| refund.created / refund.failed | #support | Support (finance CC'd) |
| invoice.payment_failed | #support | Support (founders CC'd) |
| charge.failed / payment_intent.payment_failed | #support | Support |
| customer.subscription.created | #wins | Founders |
| customer.subscription.deleted | #founders | Founders |
| Large payment (≥ your threshold) | #wins | Founders / sales |
A chargeback is not a support ticket you get to solve on your own timeline. Stripe charges a flat $15 dispute fee per chargeback regardless of the transaction amount, and you only get it back if you win. Worse, the clock starts immediately: depending on the card network you typically have just 7 to 21 days to submit evidence, you get one submission, and you can't edit or add files after. Miss the deadline and you automatically lose the dispute and the funds.
That combination — real money, a hard deadline, one shot — is why charge.dispute.created cannot sit unread in a noisy channel. It needs a named owner in finance who reconstructs the case, gathers evidence, and responds inside Stripe. Support is usually CC'd because they hold the customer context (the order, the conversation, the delivery proof), but the accountability lives with finance. If you're wiring this up, our guide on how to send Stripe dispute alerts to Slack covers the alert itself.
🚨 Dispute opened — $420.00 chargeback on Acme Corp
charge.dispute.created · $15 dispute fee applied
Evidence due in 7 days — respond in Stripe
Owner: @finance-lead
A refund is a merchant-controlled decision. Support reviews the order and chooses the lowest-cost path — a partial credit, a replacement, or a full refund. A chargeback removes that control: funds can be debited before your internal review even finishes. That's the reason refunds and disputes are handled differently and often by different owners. Route refund.created and refund.failed to #support so the person who talked to the customer sees the outcome, and CC finance so the loss and fees get reconciled. Stripe's 2024 API updates added refund.created, refund.updated, and refund.failed for all refund types, which gives you finer-grained routing than the old charge.refunded-only model. See how to send Stripe refund alerts to Slack for the setup.
Failed payments (invoice.payment_failed, charge.failed, payment_intent.payment_failed) are support's job in the moment — someone needs to nudge the customer to update a card before the subscription lapses. But a failed subscription payment is also a churn signal: once a subscription becomes past_due or unpaid rather than active, MRR drops by that amount. So route the alert to #support to fix the card, and CC #founders because revenue is at risk. Our walkthrough on how to send failed payment alerts to Slack has the details.
⚠️ Payment failed — $49.00 from Jane Doe (Pro plan)
invoice.payment_failed · card declined, insufficient funds
Subscription now past_due — reach out before it churns
Owner: @support-oncall
Founders don't need every refund line item — they need the levers that move MRR: new subscriptions, expansions, contractions, and churn. Two events carry the signal. customer.subscription.created is a new customer and a positive MRR change; route it to #wins so the whole team feels the momentum. customer.subscription.deleted is churn; route it to #founders because a real-time cancellation alert is a chance to reach out and save the customer before they're gone. Large payments over your threshold also belong in #wins. For a fuller list, see what Stripe events a founder should monitor.
🎉 New Pro subscription — TechStart Inc.
customer.subscription.created · +$299/mo MRR
Total MRR now $18,540
You don't need many channels — four covers most teams. Each one has a single, distinct purpose so people can mute what isn't theirs without missing what is:
Start tight, then widen
Scope each alert to the smallest set of people who need it, then loosen if needed. Shrinking an over-broad rule after it spams three teams is far harder than widening a precise one. Match the channel to the alert's business impact — a $15 dispute fee with a 7-day clock is not the same priority as a celebratory new-signup ping.
This is where a purpose-built tool saves you from hand-building plumbing. In ChargeBell, routing is per-alert: each alert type can target its own Slack channel, or fall back to a default home channel. So the map above isn't nine workflows to maintain — it's picking a channel next to each alert type. Connect Stripe (read-only OAuth), connect Slack, then set the destinations:
Send disputes to #finance
Point the dispute alert at #finance. Disputes are critical, so they bypass quiet hours and can add an @channel prefix — the owner sees it even at 2am, when the evidence clock is already running.
Send failed payments and refunds to #support
Route the payment-failed and refund-sent alerts to #support. Failed payments are critical too, so they'll cut through quiet hours; the payment-recovered alert lands in the same channel to close the loop.
Send cancellations to #founders
Route the subscription-canceled alert to #founders. It carries the negative MRR impact already computed, so it reads as a save opportunity, not a raw webhook.
Send new subscribers and large payments to #wins
Point the new-subscriber alert (with its MRR change) and the large-payment alert at #wins. Set your large-payment threshold so only genuine wins land there.
Add owners and quiet hours
Name an owner per channel in your team's convention (@finance-lead, @support-oncall). Turn on quiet hours so celebratory pings don't fire overnight — held alerts arrive in one 'while you were away' recap, and critical alerts (failed payments, disputes) still cut through.
Because ChargeBell writes each message in plain English — net after Stripe fees, the customer name, the MRR delta, all pre-computed — the person who owns the channel can act without opening the dashboard. If you're comparing approaches, the native Stripe Slack app and general automation platforms can also route by channel, but you build and maintain each event-to-channel rule yourself. See ChargeBell vs Zapier for Stripe Slack alerts and how to get Stripe payment notifications in Slack for the trade-offs.
The whole point of routing is accountability. A single firehose channel feels efficient — everything's in one place — but it's the opposite. When ten people can see a dispute, each assumes someone else has it. The alert scrolls past, the 7-day evidence window closes, and you eat the loss plus the $15 fee. Focused routing fixes this by making each alert land in front of exactly the person who owns it.
The other half is noise control. Even a well-routed channel dies if it's flooded. Use quiet hours to hold non-critical alerts, digests to batch the low-priority stuff, and minimum-amount thresholds so #wins celebrates real wins. Our guide on how to avoid noisy Stripe notifications goes deep on tuning, and if you run multiple clients, Stripe alerts for agencies shows how per-client routing works.
One firehose = no owner
If a dispute, a churn event, and a $9 refund all land in the same channel, the highest-stakes item (the dispute with a deadline) competes for attention with the lowest. Route by team so the important alert reaches someone who has to act on it.
Key takeaways
Connect Stripe and Slack, then point each alert type at its channel — finance, support, founders, wins. Free plan, no card needed.
Finance owns the chargeback. Stripe charges a flat $15 dispute fee per chargeback and you typically have only 7 to 21 days to submit evidence, with a single submission and no edits after. That deadline and cost make finance the accountable owner. Support is usually CC'd because they hold the customer context needed to build the evidence.
A refund is a merchant-controlled decision — support reviews the order and chooses the lowest-cost path — so refund alerts go to support with finance CC'd. A dispute (chargeback) removes that control: funds can be debited before your review finishes, and there's a hard deadline. Disputes go to finance because reconciliation and evidence are on the line.
The four levers that move MRR: new subscriptions (customer.subscription.created), cancellations (customer.subscription.deleted), plan changes, and delinquency. Route wins to #wins for morale, and cancellations to #founders so you can try to save the customer in real time. Note Stripe uses customer.subscription.deleted for cancellations — there's no customer.subscription.canceled event.
Yes. Routing is per-alert: each alert type can target its own Slack channel, or fall back to a default home channel. That means the finance/support/founders/wins map is just choosing a channel next to each alert type — not a separate workflow to build and maintain for every event.
Because accountability breaks down. When everyone sees everything, each person assumes someone else owns it, and high-stakes alerts like disputes scroll past unactioned until the deadline closes. Separate channels with distinct purposes and one named owner per alert keep the right person looking at the right thing.
No. ChargeBell connects through official read-only OAuth. It can see payment events to send and route alerts, but it can never move money, issue refunds, respond to disputes, or change anything in your Stripe account. Stripe stays the source of truth.
Stripe emits hundreds of event types. Only about a dozen deserve a founder's attention — and only three should ever interrupt your day. Here's the shortlist, ranked.
July 6, 2026
A payments channel that pings for every $9 charge gets muted — and then nobody sees the $312 dispute. Here's a five-lever framework to keep Stripe alerts signal, not noise.
July 6, 2026
Agencies live and die by payment timing. Here's how to alert on invoice paid, catch failed retainer payments, and give your team cash-flow visibility in Slack — without a dashboard to babysit.
July 6, 2026