Guides

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.

The ChargeBell TeamUpdated July 6, 20268 min read

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.

Why teams want Stripe refund visibility

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.

  • Support sees an unhappy-customer moment. A refund often means someone was frustrated enough to ask for their money back. A quick follow-up ("we saw the refund — anything we can fix?") can save the relationship, and it's far cheaper than letting them stew and open a dispute with their bank.
  • Finance sees real dollars leaving. Every refund reduces revenue, and Stripe does not return its original processing fee when you refund — so each one is a net loss beyond the transaction amount. Finance needs to reconcile these, and a spike is a signal worth chasing.
  • Founders and risk see an early warning. Refund abuse and serial "re-refunding" only surface if someone is actually watching refund activity in real time. Catching a fraudulent-refund pattern early is the difference between a small write-off and a costly dispute.

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.

Which Stripe event fires on a refund?

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:

  • refund.created — a refund was created; carries the full refund object (amount, currency, reason, status).
  • refund.updated — a refund's status changed; use this one for all payment methods.
  • refund.failed — a refund couldn't be completed.
  • charge.refund.updated — same idea as refund.updated, but only fires for selected payment methods, so prefer refund.updated.

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.

What a good refund alert looks like in Slack

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:

#finance
↩️
ChargeBellApp

↩️ 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:

#finance
↩️
ChargeBellApp

↩️ 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:

#finance
↩️
ChargeBellApp

↩️ 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.

Routing refunds to the right channel

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.

How to send Stripe refund alerts to Slack: setup

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.

  1. 1

    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.

  2. 2

    Connect Slack

    Add the app through Slack OAuth and pick your channels. ChargeBell only posts to channels you choose.

  3. 3

    Enable the refund alert

    The refund_sent (↩️) alert is on by default. Confirm it's enabled — no webhook endpoint or event subscription to configure.

  4. 4

    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.

  5. 5

    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.

Webhook script vs Zapier vs ChargeBell

CriterionChargeBellZapierWebhook 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 modelFlat $24/moPer task, ~$20/mo+Your infra cost
Zapier and a webhook script can both do the job — you build and maintain the formatting yourself.

Using ChargeBell for refund alerts

Strengths

  • Refund alert works out of the box — no event subscription or endpoint to build
  • Plain-English message with humanized reason and refunded amount
  • Route refunds to a dedicated finance/support channel per rule
  • Read-only OAuth — never touches your money or your refunds
  • Flat $24/mo, or a free plan with 100 alerts/month

Trade-offs

  • Stripe → Slack (and webhooks) only — not a general automation platform
  • Not an accounting or system-of-record tool; Stripe stays authoritative

Tuning refund alerts so they stay signal

Refunds are lower-volume than successful payments, so they rarely become spam on their own — but a few controls keep them useful:

  • Separate channel. Keep refunds out of the wins channel so they don't get muted along with routine payment noise.
  • Reason front-and-center. A fraudulent refund deserves more attention than a requested_by_customer one — showing the reason lets people triage at a glance.
  • Pair with disputes. Refunds and disputes are two points on the same escalation path. Watching both in the same channel gives you the full risk picture. If you want a broader anti-noise strategy, how to avoid noisy Stripe notifications covers it.

Key takeaways

  • Hook charge.refunded as the trigger (it fires on full and partial refunds); read refund.created if you want richer refund detail.
  • A refund is one signal three teams read differently — support, finance, and risk each need to see it.
  • Always show the refunded amount (amount_refunded), not the original charge, or partial refunds will mislead.
  • Route refunds to a dedicated #finance or #support channel, separate from noisy payment alerts.
  • ChargeBell's refund_sent (↩️) alert delivers a pre-formatted message with reason and a View in Stripe link — no Zap or webhook to build.

Get refunds in Slack, formatted, in about five minutes

Connect Stripe and Slack, enable the refund alert, route it to your finance channel, and send a test. Free plan, no card needed.

Start freeFree plan · no card needed

Frequently asked questions

Which Stripe event should I use for refund alerts?

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.

Do Stripe refund alerts cover partial refunds?

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.

Which channel should Stripe refunds go to?

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.

Can ChargeBell issue or reverse a refund from Slack?

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.

Why do finance teams care about refund fees?

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.

Is a refund better or worse than a dispute?

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.