Triage failed Stripe payments by revenue actually at risk

By General Input

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.

Integrations

  • ChartMogul
  • Stripe
  • Slack Bot
  • HubSpot

Type

Agentic Task

Categories

  • Finance
  • Operations

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.

Related prompts

Explore more prompts
Let support send one-off Loops emails without an engineerA brand asset library your marketing team actually searchesTurn Mailjet email clicks into ranked HubSpot follow-upsClean out the Looker dashboards and Looks nobody opensLiveKit live operations console for room moderationWake up dormant Keap leads with a researched reasonCustomer lifecycle inspector for Loops, Stripe and PostHogiMessage campaign console with pre-flight checks and delivery boardLiveChat coverage board for planning next week's shiftsPhone routing control panel for LiveKit voice agents