Retrying a failed Stripe subscription charge on a three-day cadence

Stripe

Open the failed charge and read the decline code.

Decline codes drive the retry strategy. `insufficient_funds` and `do_not_honor` retry well on the cadence below. `expired_card` and `lost_card` never retry; they go straight to the personalised dunning email asking the cardholder to update payment method. `fraudulent` always escalates to the senior RevOps manager.

Expected: The decline code is captured and the right path is identified.

Stripe

Suppress the Stripe automated dunning email for this customer for the next ten days.

If the manual retry sends an automated dunning the customer gets two emails and pushes back. Toggle off Smart Retries and Dunning automation in the customer settings panel for ten days, which is the longest manual retry window.

Expected: Stripe Smart Retries and dunning automation are suppressed for the customer for ten days.

Stripe

If the failure occurred on a Friday, schedule the retry to resume on Monday rather than Saturday.

Friday retries fail at roughly double the rate of mid-week retries because cardholders top up over the weekend and the declined card sits stranded. Always pause across the weekend and resume on Monday morning. The same logic applies before bank holidays in the cardholder's country.

Expected: The first manual retry is scheduled for the next working day, never Saturday or Sunday.

Stripe

Trigger the first manual retry three working days after the original failure.

Three working days catches the typical accounts payable top-up cycle without exhausting the retry budget. One day is too soon and the card is still declined for the same reason. Five days lands too close to the personalised dunning trigger which is week one.

Expected: The first manual retry executes and either succeeds or fails with a fresh decline code.

Stripe

On retry success, post the payment to the relevant invoice and clear the dunning flag in the customer record.

Confirm the payment is matched to the open invoice, not deposited as a credit balance. A credit balance leaves the original invoice open and recognition keeps treating the customer as in arrears. Clear the dunning flag manually because the auto-clear runs on the next billing cycle, not immediately.

Expected: The invoice is marked as paid and the dunning flag is cleared on the customer record.

Stripe

On retry failure, classify the customer by monthly recurring revenue tier from NetSuite.

MRR above $5,000 routes to the personalised dunning email pattern. MRR at or below $5,000 routes to a second manual retry three working days later. After three failed manual retries the recognition pause pattern fires regardless of MRR tier so revenue does not keep recognising on a customer who is not paying.

Expected: The customer is routed to the personalised dunning email path or the next retry slot.

Stripe

Log the retry outcome with the cadence position in the dunning notes for traceability.

The dunning notes track which retry attempt this was (1 of 3, 2 of 3 etc.) and the expected next action. This lets a different RevOps operator pick up the case if the originator is out without re-deriving the cadence from scratch.

Expected: The retry outcome and cadence position are recorded on the customer's dunning notes.