When a recurring donation fails: a four-state recovery workflow

When a recurring donation fails, put it in a four-state queue: new failure, retrying, donor action needed, or resolved. Give each state one owner and one permitted next action. This keeps automatic retries, donor emails, and staff follow-up from colliding.

The goal is not to chase every failed payment faster. It is to know who—or what—owns the next move.

Start with a record, not an email

A failed recurring donation should create one record your team can follow from failure to resolution. Capture only what you need to make the next decision:

• donor and recurring-gift identifiers;
• failure date and current subscription status;
• the processor or platform message;
• whether another attempt is scheduled, and when;
• whether the donor has already been notified;
• the staff owner, if staff action is required.

Do not copy payment details into this record. Do not assign staff outreach until you know whether the platform is already retrying or contacting the donor.

That check matters because platforms behave differently. GoFundMe Pro, for example, uses states such as Failing and Suspended and follows its own reprocessing rules. Stripe Billing separates recoverable failures from hard declines that require a new payment method (GoFundMe Pro recurring-gift guide, Stripe retry documentation). Use your platform's current status and retry policy. Do not borrow a schedule from another system.

State 1: New failure

Your automation or payment-exception owner handles this state. Their only job is to classify the failure. Check the current status, the failure message, the next scheduled attempt, and the notification history. Do not manually reprocess a gift from an alert email alone.

Move the record to:

• Retrying when the platform shows another automatic attempt.
• Donor action needed when a new payment method or authentication is required, or when automated attempts have ended.
• Resolved when the payment has already succeeded or the failure record was created in error.

New failure is a short-lived intake state. If records sit here, your team lacks either an owner or the information needed to route them.

State 2: Retrying

The payment system owns this state. Staff monitor the scheduled attempt. Write down its date and leave the charge alone. A manual retry while automation is active can make the history harder to understand and may create unnecessary donor communication. Waiting is the correct operational choice when the system already owns the next action.

Check whether the platform sends its own failed-payment email. If it does, do not send a second message that asks for the same action. Stripe and other billing systems can combine retry rules with automated customer emails, but the exact behavior depends on configuration (Stripe customer-email documentation).

After the scheduled attempt, move the gift to Resolved if payment succeeds. Move it to Donor action needed if the platform requires updated information or has no further attempt scheduled.

State 3: Donor action needed

Assign this state to one staff member or one approved donor-email automation. Send one secure update route. Tell the donor what happened, what they need to do, and where they can do it. Link to a secure donor or payment portal. Do not ask a donor to send card details by reply, text, or chat. The PCI Security Standards Council says that a messaging channel used to receive or send primary account numbers must meet the applicable PCI DSS protections and becomes part of the assessed environment (PCI SSC guidance).

A useful message can be this short:

Subject: Please update your payment method for your monthly gift Hi [first name], we couldn't process your [date] recurring gift to [organization]. You can securely review your payment method here: [portal link]. If you already updated it, no further action is needed. Questions? Reply to this email and we'll help with the account—not the card details.

A portal gives the donor one secure place to update a payment method or manage a subscription; the exact controls depend on the system (Stripe customer-portal documentation). CharityStack's recurring-giving tools and donor portal keep subscriptions and donor self-service in the same fundraising system.

Record when the message was sent. Do not let a separate staff member send a second version because the first outreach was not visible in their inbox.

State 4: Resolved

At this point, the operations record owns the close. Record the outcome and stop recovery work. Resolved does not always mean recovered. It means the team knows what happened and no recovery action remains. Use a resolution reason such as:

• payment recovered;
• donor updated the payment method;
• donor paused or ended the recurring gift;
• retry policy ended without recovery;
• duplicate or invalid failure record closed.

Store the resolution date and the last successful or final failed attempt. Clear any staff task or automation that should no longer run. A clean ending prevents an old failure from reappearing in next week's work.

Follow one gift through the queue

Suppose a monthly gift fails on Monday. The platform shows another attempt on Friday and confirms that it sent the donor an automatic notice. The record moves from New failure to Retrying. Staff do not retry the gift or send another email.

On Friday, the next attempt fails and the platform says a new payment method is required. The record moves to Donor action needed, and the assigned staff member sends one secure portal link. The donor updates the method, the next attempt succeeds, and the record moves to Resolved: payment recovered.

The value of the queue is visible in the steps that did not happen: no duplicate email, no premature manual charge, and no abandoned task after recovery.

Review the queue once a week

A lean team does not need a new daily meeting. Review four exceptions:

1. New failures without an owner or next-attempt status.
2. Retrying gifts whose scheduled attempt date has passed.
3. Donor-action records with no visible outreach or response.
4. Resolved records missing an outcome or closure date.

The review should end with fewer ambiguous records, not more messages. If the platform's retry state is unclear, resolve that system question before adding another donor touch.