Payment Retry Orchestration for SaaS

Stripe's built-in dunning retries failed payments on a schedule. The default: retry on day 3, day 5, and day 7, then mark the invoice as uncollectible. This recovers some failed payments. It leaves a significant portion on the table.

The gap isn't in Stripe's retry capability — it's in the intelligence applied to when, how often, and in what sequence retries happen for different failure types.

Why generic retry schedules underperform

Failed payments fail for different reasons. A card decline coded card_declined with insufficient_funds is likely to succeed at end of month when the cardholder gets paid. A decline coded do_not_honor often indicates a fraud block that won't resolve without customer action. A card_expired failure needs a card update — no retry will ever succeed.

Generic retry schedules treat all failures identically. Intelligent retry orchestration reads the decline code and applies a recovery strategy appropriate to that failure type:

• Insufficient funds → retry at end of month or start of next billing cycle; send a gentle heads-up email 24 hours before
• Do not honor / fraud block → escalate to customer action (update payment method) immediately; retries are unlikely to succeed
• Expired card → no retry; trigger card update flow with urgency-graded messaging
• Network error / processing error → retry within 24–48 hours; high probability of success on next attempt
• Lost or stolen card → suspend retries; require new payment method before service continues

The timing and sequence layer

Beyond decline-code routing, retry timing matters. Card networks process batches at different times. Retries at 9am on the first business day of the month succeed at higher rates than retries on weekend evenings. A retry orchestration layer that schedules based on historical success patterns — by card type, card issuer, and time of day — recovers meaningfully more revenue than fixed-interval retries.

For most SaaS businesses, intelligent retry sequencing recovers 20–35% more failed charges than default retry behavior. At $500K ARR with a 2% monthly failure rate, that's $2,000–$3,500 in monthly recovered revenue from a one-time system change.

The customer communication layer

Retry logic alone recovers a subset of failed payments. The rest require customer action. The communication workflow — what message goes to the customer, when, in what tone, with what call to action — determines how many of those customers update their payment details before the account is suspended.

A payment retry orchestration tool manages the communication sequence alongside the retry sequence: a payment-failed notification on failure, a reminder at day 3 if still unresolved, an urgency email at day 6 warning of service interruption, and a suspension notice at day 9 with a direct link to update the payment method. Tone escalates as the deadline approaches, but never in a way that's antagonistic — the goal is payment, not complaint.

Building on top of Stripe

This layer is implemented as a set of webhook handlers on top of Stripe's payment events. When a payment fails, Stripe fires a payment_intent.payment_failed event with the decline code. Your orchestration layer reads the decline code, applies the routing logic, schedules the appropriate retry and communication sequence, and updates your billing system with the recovery status.

Stripe's retry system can be disabled or augmented to let your orchestration layer control timing completely. Most teams run their orchestration logic in addition to Stripe's built-in dunning as a complementary layer.