How to Send Stripe Refund Alerts to Slack
A refund is one signal three teams read differently. Here's how to send Stripe refund alerts to Slack — which event to hook, who should see them, and how to set it up in minutes.
A refund is one signal three teams read differently. Here's how to send Stripe refund alerts to Slack — which event to hook, who should see them, and how to set it up in minutes.
To send Stripe refund alerts to Slack, hook Stripe's charge.refunded event, format a message that says who was refunded, how much, and why, then post it to a channel your support and finance teams actually watch. You can wire this up with a webhook script or Zapier, or connect ChargeBell to get a pre-formatted refund alert routed to the right channel in about five minutes — no code required.
Short answer
Listen to charge.refunded for the trigger (it fires on full and partial refunds). If you want richer refund detail — reason, status — read the refund.created event too. Then route refunds to a dedicated #finance or #support channel, separate from your noisier payment alerts. ChargeBell does exactly this with its refund_sent (↩️) alert, so you skip the build.
A refund looks like a single line item in the Stripe Dashboard, but three different teams read it three different ways — and none of them are watching the Dashboard all day. That gap is exactly why refunds get missed until someone stumbles on them at month-end.
The fraud angle matters more than it looks. Return and refund fraud has become a well-documented, multi-billion-dollar problem for retailers, and SaaS and digital businesses feel it differently: because digital products deliver instantly, there's no fulfillment window to catch a stolen card before value changes hands. A refund is often your earliest visible signal that something's off — which is why it's worth watching in real time rather than at month-end.
A refund is usually a cheaper, faster outcome than a dispute. Disputes carry fees and hard response deadlines. If support sees the refund in Slack the moment it happens, they can proactively resolve the issue before the customer escalates to their bank. See how to send Stripe dispute alerts to Slack for the other half of this workflow.
The event you almost always want as your trigger is charge.refunded. It fires whenever a charge is refunded — including partial refunds — and its payload carries the updated Charge object (data.object type = charge). If you only want to know *that* a refund happened and post an alert, this is the one to hook.
There's a subtlety Stripe itself calls out: for details about the refund — the amount refunded, the reason, the status — Stripe recommends listening to the refund.created event (data.object type = refund), not charge.refunded. The related refund events are:
In practice: use charge.refunded as the trigger, and pull the reason and amount detail you want to display. Stripe refunds carry a reason field with three predefined values — requested_by_customer, duplicate, and fraudulent — plus an "Other" free-text option from the Dashboard. That reason is the single most useful thing to surface in Slack, because fraudulent should make someone look up from their desk.
Partial refunds are easy to get wrong
Refunds can be full or partial, and you can issue multiple partial refunds against one charge until the total equals the original. If your alert shows the charge's original amount instead of amount_refunded, a $312 partial refund on a $900 charge will read as $900 — wildly misleading. Always show the refunded portion.
A refund alert is only useful if it answers three questions at a glance: who was refunded, how much, and why. Add a one-click link back to Stripe so whoever's on point can dig in without hunting. Here's the shape ChargeBell sends:
↩️ Refund sent — $49.00 to Lena at Fernworks
Reason: requested by customer
View in Stripe →
Partial refunds show the refunded portion, not the original charge, so the number is honest:
↩️ Refund sent — $312.00 (partial) to ops@acmecorp.com
Reason: duplicate
View in Stripe →
And when the reason is fraudulent, that's the alert you want your risk-minded people to catch before it turns into a dispute:
↩️ Refund sent — $1,200.00 to Priya Menon
Reason: fraudulent · worth a look before it becomes a dispute
View in Stripe →
Compare that to what a raw webhook or a basic Zap posts by default: a gross amount, a customer ID, and a wall of JSON fields you have to decode. Getting to a clean, plain-English line usually means extra steps, extra field mapping, and extra maintenance. For more on what separates a useful alert from noise, see what a payment alert should include.
The most common mistake is dumping refunds into the same channel as every successful payment. Wins and refunds serve different readers. Successful-payment noise trains people to mute the channel — and then they miss the refund spike that actually mattered.
Instead, route refunds to a dedicated channel that finance and support both sit in — #finance, #refunds, or #billing-ops. A single channel that both teams watch gives you real-time awareness across the two groups who need to act, and it makes an unusual refund spike visible instead of buried. When refunds land in a channel people already read, problems get caught in hours instead of surfacing at the next reconciliation.
ChargeBell keys everything on your organization and lets each alert type route to its own Slack channel. So refund_sent can go to #finance while payment_received goes to #wins and payment_failed goes to #alerts — independently, per rule. If you're mapping out who gets what, which Stripe alerts go to finance, support, and founders walks through a full routing plan.
There are three common ways to get refunds into Slack. Raw webhook-to-Slack scripting works but means you own the endpoint, the parsing, and the formatting forever. Zapier's Stripe trigger fires on charge.refunded (partials included) but you build and maintain the Zap, and paid multi-step Zaps start around $20/month. Relay.app offers a "New refund added" trigger with a Slack "Send to channel" action. All three leave you writing the message yourself.
ChargeBell is the no-build path: the refund message, the reason humanization, the partial-refund math, and the "View in Stripe" link are the product. Here's the full setup.
Connect Stripe
One-click, read-only OAuth via Stripe Connect. ChargeBell can see refund and payment events; it can never issue, cancel, or edit a refund — Stripe stays the source of truth.
Connect Slack
Add the app through Slack OAuth and pick your channels. ChargeBell only posts to channels you choose.
Enable the refund alert
The refund_sent (↩️) alert is on by default. Confirm it's enabled — no webhook endpoint or event subscription to configure.
Route it to #finance or #support
Set refund_sent's destination channel independently of your other alerts, so refunds land where finance and support will see them.
Send a test alert
Fire a test to confirm the channel and formatting look right before the next real refund lands.
That's it. If you're deciding between building this yourself and using a purpose-built tool, ChargeBell vs Zapier for Stripe Slack alerts and ChargeBell vs custom Stripe webhook code both compare the trade-offs directly. And if you're just getting started with Stripe-in-Slack, how to get Stripe payment notifications in Slack is the broader primer.
| Criterion | ChargeBell | Zapier | Webhook script |
|---|---|---|---|
| Fires on charge.refunded (incl. partials) | |||
| Refund message pre-formatted for you | |||
| Shows refunded amount, not original charge | |||
| Humanized reason + View in Stripe link | |||
| Per-channel routing for refunds | |||
| Nothing to host or maintain | |||
| Pricing model | Flat $24/mo | Per task, ~$20/mo+ | Your infra cost |
Using ChargeBell for refund alerts
Strengths
Trade-offs
Refunds are lower-volume than successful payments, so they rarely become spam on their own — but a few controls keep them useful:
fraudulent refund deserves more attention than a requested_by_customer one — showing the reason lets people triage at a glance.Key takeaways
Connect Stripe and Slack, enable the refund alert, route it to your finance channel, and send a test. Free plan, no card needed.
Use charge.refunded as your trigger — it fires whenever a charge is refunded, including partial refunds, and carries the updated Charge object. If you want richer detail about the refund itself (amount, reason, status), Stripe recommends also listening to refund.created, whose payload is the refund object.
Yes. charge.refunded fires on partial refunds too, and you can issue multiple partial refunds against one charge. Just make sure your alert shows the refunded amount (amount_refunded), not the charge's original amount, or partial refunds will look larger than they are. ChargeBell shows the refunded portion automatically.
A dedicated channel that both finance and support watch — like #finance, #refunds, or #billing-ops — rather than the same channel as successful payments. That keeps refunds visible instead of buried under wins, and makes a refund spike easy to spot. ChargeBell lets you route the refund alert to its own channel per rule.
No. ChargeBell connects to Stripe through read-only OAuth. It can see refund events to send you an alert, but it can never issue, cancel, or modify a refund — or move money at all. Stripe stays the source of truth for every action.
When you refund a Stripe charge, Stripe does not return its original processing fee. So every refund is a net loss beyond the transaction amount, which finance has to reconcile. Real-time refund alerts let finance see the money leaving as it happens instead of discovering it at month-end.
A refund is usually the cheaper, faster outcome. Disputes carry fees and hard response deadlines, so if support can see a refund in Slack and follow up quickly, they can often resolve the issue before the customer escalates to their bank. Watching refunds and disputes together gives you the full risk picture.
Disputes are the rare Stripe event where doing nothing loses you money. Here's how to route charge.dispute.created to Slack so your team responds before the deadline.
July 6, 2026
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.
July 6, 2026
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