# Triage failed Stripe payments by revenue actually at risk

> When a subscription payment fails, get a Slack alert that shows the customer's real recurring revenue and tells you who deserves a phone call.

- Workflow type: agent
- Services: ChartMogul, Stripe, Slack Bot, HubSpot
- Categories: Finance, Operations
- Published: 2026-08-14

## What it does

- Reacts the moment a subscription payment fails in Stripe, instead of waiting for a daily report or a monthly churn review.
- Looks the customer up in ChartMogul to find what they are really worth, pulling their recurring revenue, current plan and how long they have been a customer.
- Assigns a severity tier from the revenue at risk plus account tenure, so a long-standing high-value account gets escalated for a personal call while a small trial-tier failure stays informational.
- Posts a clear alert to your billing channel with the failure reason and a recommended next step, and for the serious ones creates a follow-up task for the account owner and tags the customer so at-risk accounts stay easy to find later.

## What you'll need

- A Stripe account that bills customers on subscriptions
- A ChartMogul account connected to your billing data, so the workflow can read recurring revenue and account history
- A Slack workspace with a channel where billing alerts should land
- A HubSpot login, if you want follow-up tasks created for high-severity accounts

## Prompt

When Stripe tells us a subscription payment has failed, I want an agent to immediately work out how much recurring revenue is actually at risk, instead of treating every failed charge the same. A long-tenured, high-value account and a trial-tier card decline should not get the same response.

Trigger this on a Stripe webhook for the invoice.payment_failed event. Start by calling Stripe Retrieve Invoice with the invoice ID from the webhook payload to pull the amount due, the currency, the customer email address and the failure reason. Before doing anything else, compare the failed amount against a configurable minimum amount threshold. If the failed charge falls below that threshold, stop the workflow silently and post nothing, so routine small charges never create channel noise. Keep that threshold near the top of the workflow where it is easy to find and change.

For failures above the threshold, look the customer up in ChartMogul using Search Customers by Email with the email address from the Stripe invoice. From the matching customer, call List Customer Subscriptions (Metrics) to get their true recurring revenue and current plan, and call List Customer Activities to get their account history, including when they first became a customer and whether they have had prior downgrades or churn events. ChartMogul returns monetary amounts as integers in cents, so convert them into readable currency before they reach any message. If no ChartMogul customer matches the email, still post the alert, but flag clearly that the revenue context could not be found.

Have the agent assign a severity tier by weighing the MRR at risk against account tenure, rather than looking at the size of the failed charge alone. A high-MRR, long-tenured account should be high severity, with a recommendation that someone call the customer personally. A mid-value account should be flagged for a proactive email from the account owner. A low-value or recently signed trial-tier account should stay informational. Ask the agent to state its reasoning in one short line so the tier it picked is auditable.

Post the triaged alert to our billing channel using Slack Bot Send a Message. Include the customer name, the MRR at risk in readable currency, the severity tier, the amount and currency of the failed charge, the failure reason from Stripe, how long they have been a customer, and a specific recommended next step. Lead with the severity tier so it is obvious at a glance.

For high-severity accounts only, do two more things. Create a follow-up task in HubSpot using Create Task, assigned to the account owner, due the next business day, with a subject naming the customer and the MRR at risk. Then tag the customer in ChartMogul using Add Tags to a Customer with an at-risk tag such as payment-failed-at-risk, so at-risk accounts stay filterable in ChartMogul afterwards. Medium and low severity failures should produce the Slack message only.

## How to customize

- Set the minimum charge amount worth alerting on, so small payments are skipped silently and never clutter the channel.
- Move the line between high, medium and low severity to match the revenue and account tenure that actually matter to your business.
- Swap HubSpot for whichever CRM your team uses, or turn the follow-up task off entirely and keep the Slack alert on its own.

## FAQ

### Does this replace Stripe's automatic payment retries?

No. Stripe keeps retrying the card on its own schedule, and that recovers a good share of failures by itself. This workflow sits on top of that and answers a different question: which of those failures is worth a human intervening on before the retry window runs out.

### Will it fill our Slack channel with noise every time a small charge fails?

No. You set a minimum amount, and any failure below it is skipped silently with nothing posted. Only failures big enough to matter reach the channel.

### What happens if the customer cannot be found in ChartMogul?

The alert is still posted, with a note that the revenue context was missing. A payment failure never gets silently swallowed just because the records did not match.

### Do we need HubSpot for this to work?

No. The Slack alert works entirely on its own. HubSpot is only used to create a follow-up task for high-severity accounts, and you can point that step at another CRM or skip it.

### How quickly does the alert arrive?

Within moments of Stripe reporting the failed payment. This runs in real time off the payment failure itself rather than on a daily or weekly schedule.

Use this prompt in General Input: https://www.generalinput.com/prompts/triage-failed-stripe-payments-by-revenue-actually-at-risk