Failed Subscription Payment Recovery for WooCommerce

Recover failed subscription payments with a coordinated system: classify the failure, avoid duplicate charges, retry only when the decline is recoverable, send a clear payment-update path, preserve access for a defined grace period, and stop or downgrade predictably. Measure recovered customers and value by decline, gateway, attempt, and cohort—not merely how many retries ran.

Key takeaways

• Payment recovery is a lifecycle, not a retry button.
• Verify the gateway has not already charged before every retry.
• Retry timing belongs to ArraySubs for local Stripe and to the remote provider for PayPal/Paddle.
• Hard/customer-action failures need a new method or authentication, not blind retries.
• Count paid recoveries, not administrative dismissals, and use closed cohorts.

Current ArraySubs lifecycle

Current defaults create this baseline:

renewal reminder: 3 days before due
invoice creation: 6 hours before due
active grace: 3 days after due
on-hold period: 7 additional days
Stripe local retries: up to 3, scheduled 24 hours apart

The overdue checker runs hourly, so transitions can occur after the threshold. Defaults are product behavior, not universal recommendations. A perishable shipment, low-cost digital tool, and annual service should not share policy automatically.

Establish gateway ownership

Stripe Billing Smart Retries do not control current ArraySubs renewal orders/PaymentIntents. They apply to Stripe Billing invoice collection, a different architecture.

Route failures by required remedy

Stripe documents advice such as try_again_later, do_not_try_again, and confirm_card_data; use gateway advice rather than a one-size schedule (card declines).

Duplicate-charge protection comes first

Current ArraySubs asks the gateway whether the renewal order was already charged before retrying. If a successful remote charge exists after a missed webhook, it reconciles the order without another charge. Manual retry forces the same safety check.

Operators should compare subscription, renewal order, gateway transaction, webhook/logs, retry count, and scheduled action before touching payment state.

Communication and access

A customer failure message should show amount, subscription/order, a safe plain-language reason, one Pay Now/authenticate/update-method action, the next attempt or cutoff, access/fulfillment consequence, and support. Do not send raw processor data or blame the customer.

During current active grace, the subscription remains active. On-hold can restrict access according to store rules. Physical fulfillment may need to stop earlier than account access if inventory or carrier handoff is costly. On payment, current ArraySubs clears failure/on-hold state, restores active status, and advances from the original due-date basis.

Recovery measurement

Assume a closed illustrative cohort: 100 renewal attempts, 12 first failures, 7 later paid, $1,600 failed value, and $900 recovered:

failure rate = 12 ÷ 100 = 12%
customer recovery = 7 ÷ 12 = 58.3%
value recovery = $900 ÷ $1,600 = 56.25%

Arithmetic example, not ArraySubs, WooCommerce, or industry performance.

Segment by gateway, decline, first/later renewal, cadence, value band, tenure, attempt, customer action, product, fulfillment, and grace policy. Keep customer and value recovery separate.

Stop rules

Stop when the order is paid, gateway says do not retry, the customer cancels or revokes authorization, new credentials/authentication are required, context is missing, maximum attempts are reached, status is ineligible, amount/schedule is wrong, remote recovery owns the obligation, or fraud/risk review is needed.

Operating runbook

1. Identify subscription and renewal order.
2. Confirm local and gateway unpaid state.
3. Establish manual/local/remote ownership.
4. Inspect raw and normalized failure evidence.
5. Check retry, grace, and scheduled actions.
6. Verify customer action and message delivery.
7. Review access, shipment, switch, and cancellation impact.
8. Choose retry, customer action, manual payment, reconciliation, or stop.
9. After payment, verify order, status, next date, jobs, and cleared metadata.
10. Record resolution source; “Mark Resolved” in the Pro failures screen is an administrative dismissal, not payment.

For the customer-facing sequence, read What Happens When a Subscription Payment Fails?.

Final recommendation

Optimize recovery only after duplicate-charge safety, ownership, customer action, access, and stop rules are correct. Measure closed cohorts and guardrails alongside recovered money. Compare ArraySubs plans.

Frequently asked questions

How many times does ArraySubs retry a failed renewal?

Current local Stripe behavior supports up to three retries at 24-hour intervals. Manual payments require action; PayPal and Paddle own remote recovery. No one count applies to every gateway.

Does one failed payment immediately cancel access?

Not under current defaults. The subscription stays active for three grace days, then on-hold for seven more before cancellation. Actual access follows store rules.

Should every decline be retried?

No. Some transient failures may recover. Expired/invalid credentials and authentication-required failures need customer action; gateway stop advice must be honored.

What does Mark Resolved do?

It dismisses an audit item and records an administrative note. It does not make the renewal order paid and must not count as recovered revenue.

Can ArraySubs prevent a duplicate retry charge?

Current retry processing checks the gateway for an existing successful charge before charging again. Verify the integration supports the check and reconcile the actual transaction.

Disclosure, verification, and update log

• July 2026: Verified against current ArraySubs recovery lifecycle, Pro gateway paths, and official WooCommerce/Stripe/PayPal/Paddle sources. No recovery benchmark is claimed.