Triage failed Recharge payments before subscribers churn

By General Input

When a Recharge charge fails, your retention team gets a ranked Slack alert with the reason, the subscriber's value, and what to do next.

Integrations

  • Recharge
  • Slack Bot
  • Google Sheets

Type

Agentic Task

Categories

  • Finance
  • Operations

When Recharge tells me a charge has failed, I want an agent to triage the failed payment straight away instead of letting it sit silently in the dunning queue. Build this as a webhook workflow that listens for the Recharge charge/failed topic on API version 2021-11.

Start with the failed charge itself. Use the Recharge Get Charge operation with the charge id from the webhook payload to pull the failed amount, the decline reason the processor returned, how many retry attempts have already happened, and the next scheduled retry date. Then use Get Customer for the customer on that charge to get their name and email.

Next work out how valuable this subscriber is. Use List Subscriptions filtered to that customer to see how many active subscriptions they have, what each one bills per cycle, and when the oldest one started, which tells you how long they have been subscribed. Use List Orders filtered to the same customer to count how many orders they have received and to approximate what they have spent to date.

Keep the lookups tight. Recharge rate limits on a leaky bucket of 40 requests refilling at 2 per second, so this should be a small fixed number of calls per failed charge: one charge, one customer, one page of subscriptions, one page of orders. Do not fan out unbounded per-page or per-subscription requests. Recharge money fields are decimal strings in the store currency such as "12.99", not integer cents, so treat them as decimals and never divide by 100.

Classify the failure into one of three buckets: expired or invalid card, insufficient funds, or hard decline (card reported lost or stolen, account closed, or the issuer blocked the charge outright). Fall back to a plain "other" bucket when the decline reason does not clearly map to one of those. Then rank urgency by subscriber value and tenure together: a long tenured customer with several active subscriptions and high spend to date is a high urgency save, while a first cycle customer on one low value subscription is low.

Post one alert per failed charge to our retention channel using the Slack Bot Send a Message operation. Keep it scannable rather than a wall of text: customer name, the failed amount, the decline reason in plain language, the classification, their per cycle subscription value and how long they have been subscribed, the next retry date, and the urgency ranking. Put the recommended action on its own line at the end so it is easy to spot, for example wait for the automatic retry when funds were insufficient, ask for an updated card when the card has expired, or escalate to a human for a high value hard decline.

Finally, append every failure to our recovery tracker using the Google Sheets Append Values operation, one row per failed charge, carrying the date, customer name and email, failed amount, decline reason, classification, tenure, spend to date, urgency, next retry date and the recommended action. That way the team can work the queue and measure our recovery rate over time.

Related prompts

Explore more prompts
Call overdue Xero customers with an AI collections agentLocal listing health board for every location you manageLet 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 opensStop cold emails to anyone with a live deal in PipedriveLiveKit live operations console for room moderationWake up dormant Keap leads with a researched reasoniMessage campaign console with pre-flight checks and delivery board