How to build a payment incident workflow in Slack

A payment incident workflow in Slack is a short process your team follows when money is at risk. It has four steps: detect, triage, assign, and resolve. You need one channel, three severity levels, two roles, and a runbook for each common incident. You don't need a separate incident tool. This guide gives you all four parts.

What counts as a payment incident?

A payment incident is any event where money is at risk and a deadline is running. Most Stripe businesses see three kinds:

• A failed payment spike. Declines jump well above normal. The cause is often a batch of expired cards or a card network problem. It can also be card testing, where fraudsters run many small charges to check stolen cards. Stripe names a cluster of small charges as the usual sign.
• A dispute. The customer's bank takes a payment back. In the US, Stripe charges a $15 dispute fee that you don't get back, and since June 2025 a second $15 fee if you challenge it, refunded only if you win. You have about 7 to 21 days to submit evidence, depending on the card network, or you lose by default.
• A payout or platform problem. A failed payout means your bank rejected the transfer, and Stripe pauses later payouts until you fix it. Stripe itself can also have an outage. Check status.stripe.com when many payments fail at once.

Each one costs money and has a deadline. That is why an owner, a severity level, and a runbook are worth setting up.

Why run payment incidents in Slack

Payment incidents lose time while people gather context and work out who owns the problem. When the alert, the owner, the severity, and the next update all sit in one Slack thread, everyone reads the same record. Track how long your team takes to acknowledge and resolve incidents to see whether it helps.

If Stripe alerts already go to Slack, you have the first step. If not, start with how to get Stripe payment notifications in Slack. To decide which channel gets which alert, read which Stripe alerts go to finance, support, and founders.

The payment incident workflow in Slack, step by step

Every payment incident goes through the same four steps. Most need one person and one runbook.

1. 1

   Detect

   An alert posts in Slack for a failed payment, a dispute, or a failed payout. ChargeBell listens for Stripe events such as charge.dispute.created, and its dashboard shows a banner when failed payments spike, so nobody has to scan logs.

2. 2

   Triage

   The first person to respond sets the severity, from SEV-1 to SEV-3. Then they make the main decision. For a dispute, fight or accept. For a spike, act now or wait. For a payout, fix it or escalate.

3. 3

   Assign

   One person becomes the owner and makes the calls. For anything bigger than one failed payment, the owner brings in a responder to investigate. Post both names in the thread.

4. 4

   Resolve

   Follow the runbook. Diagnose, act, then check the fix worked, for example that the failure rate is back to normal, the evidence is submitted, or the payout is resent. Post the outcome in the thread and close the incident.

Severity levels

Severity levels keep you from waking the whole team for one expired card, and from ignoring an outage. Here is a three-level version for payments:

Two roles

Large incident processes have many roles. For payments, two are enough:

• The owner. Coordinates, decides whether to fight, accept, or escalate, and keeps the thread updated. The owner makes decisions and leaves the investigation to the responder.
• The responder. Investigates. Checks Stripe payments for clusters of small declines, reviews Radar, checks bank details, or resends a payout. For a single dispute, the owner and responder are often the same person.

What ChargeBell does in the workflow

The process only works if the alert reliably starts it. ChargeBell handles detection and gets the alert to the right people in Slack.

• Critical alerts. Failed payment, dispute, and failed payout alerts are marked critical. Turn on critical mentions and they start with @channel.
• A failed payment spike banner. The ChargeBell dashboard shows a banner when today's failed payments since 8 a.m. reach three times the daily average of the past seven days, with a minimum of three. It links to the list of failed payments. Use it to detect a spike.
• Dispute deadlines. Dispute alerts show a respond-by date when Stripe provides one, and a button to view the evidence in Stripe.
• Channels and quiet hours. Each alert type can go to its own channel. Quiet hours hold routine alerts until morning, but critical alerts post right away.

What a payment incident looks like in Slack

ChargeBell shows a failed payment spike as a banner on its dashboard. Once someone confirms the pattern in Stripe, they post a message like this one in Slack. It is a template your team writes, not a ChargeBell alert:

For a dispute, the ChargeBell alert shows the amount, the reason when Stripe gives one, and the respond-by date. The owner replies in the thread with the decision:

A finance owner might reply Owner: @finance-oncall · Decision: fight or accept. That reply comes from your team, not from ChargeBell.

A sample runbook

A runbook has three parts. Diagnose the cause, take the exact actions, and check the fix. Write one for each common incident and paste it into the thread when the alert posts. Here is one for a failed payment spike:

1. Diagnose. Open Payments in Stripe and compare failure counts, amounts, card fingerprints, IP addresses, and decline codes with a normal day. Many small attempts can mean card testing. A batch of insufficient_funds declines does not mean the cards expired. Read Stripe's card testing guide and check status.stripe.com for a Stripe incident.
2. Act. If the evidence points to card testing, review your Radar settings with whoever owns payments. For real customers whose renewals failed, check your Billing retry settings and contact customers who need a new card. If Stripe reports an outage, share the status page and check whether your checkout is affected.
3. Check. Confirm the failure rate is back to normal in ChargeBell or Stripe. Post the cause and the fix in the thread, then close the incident.

The payout runbook is shorter. Check your bank details in Stripe's payout settings, resend the payout, and confirm the next one is scheduled. For disputes, the runbook is a decision and a deadline. See the Stripe dispute alert for that process and the Stripe failed payment alert for the alert that starts a spike investigation.

Keep it small

The workflow answers one question. When an alert posts, who does what, in what order, and by when? A severity level, a named owner, and a three-step runbook answer it. Don't add steps, forms, or an incident tool until your volume needs them. Keep the alert channel quiet too, because noise hides incidents. How to avoid noisy Stripe notifications shows how.