A failed payment on a WordPress membership site can be retried by one of three engines: Stripe Billing's retries (Smart Retries or a custom schedule), your plugin's own retry system (WooCommerce Subscriptions has one, off by default), or PayPal's rules. Some failures are never retried and need the member to supply a new payment method. Find out which engine runs on your site first. Then check that hard declines get a way to update the payment method, that Stripe's webhooks reach your site, and that your scheduled renewals actually run.
We maintain WordPress membership sites for a living, and the billing handoffs between the processor, the membership plugin and the CRM are where things drift. The Stripe, WooCommerce Subscriptions, PayPal and WordPress details below come from their own documentation, linked as we go. The MemberPress details come from MemberPress's docs and one MemberPress blog post, and we say which is which. Where we haven't verified something, we say how to check it on your own site instead of guessing. If you would rather have someone read your settings than read about them, a technical audit of your billing setup is what that looks like: it includes reconciling Stripe against MemberPress for sites that run it, and it starts from $1,000.
Which retry engine is running on your site?
Three systems can retry a failed membership payment, and each has different defaults: Stripe, WooCommerce Subscriptions and PayPal. The fourth row is MemberPress. The docs we checked don't state a retry engine of its own for it, so read that row as a notification setting and check which of the other three applies to your setup. The table shows what each vendor documents as of October 2026.
| Engine | Who retries | Default | Timing | Customer email |
|---|---|---|---|---|
| Stripe Billing subscriptions | Stripe Billing, through Smart Retries or a custom schedule | Stripe's recommended default is 8 tries within 2 weeks. You set it under Billing > Revenue recovery > Retries | Window of 1 week, 2 weeks, 3 weeks, 1 month or 2 months. A custom schedule allows up to three retries | A Stripe setting, “Send emails when card payments fail” |
| WooCommerce Subscriptions | Its own Failed Recurring Payment Retry System | Off by default. Turn it on under WooCommerce > Settings > Subscriptions > Payment recovery | Five default retry rules over 7 days when switched on | Check the plugin's email settings |
| PayPal subscriptions | PayPal | Per PayPal's developer documentation | Every 5 days, up to twice per billing cycle. PayPal's rules depend on the product and plan | Check your PayPal plan settings |
| MemberPress | Not stated in the docs we checked | The “Send Failed Transaction Notice” email is a setting under MemberPress > Settings > Emails | MemberPress's blog says: “If you use the Stripe payment gateway, you can set up a custom retry schedule.” | The failed transaction notice, once enabled |
Sources: Stripe Smart Retries, Stripe customer emails, WooCommerce Subscriptions failed payment retry, PayPal payment failure retry, and MemberPress on failed payments (a MemberPress blog post). The sources for the later sections are linked where they appear.
Two cautions. WooCommerce Subscriptions retries only eligible subscriptions: ones on automatic recurring payments, through a gateway that doesn't control the billing schedule (its documentation says PayPal Standard, which does control it, doesn't allow automatic retries). Its documentation also says the retry system doesn't trigger for SEPA payments, and that the setting applies from the moment you switch it on and does not affect payments that have already failed. And PayPal's rules depend on the PayPal product and the plan, so read your own plan before trusting any number you find in a blog post, ours included.
How to find out which one is live
Stripe's documentation describes Smart Retries as a feature of Stripe Billing, for subscription and invoice payments. So the question is what objects your plugin creates in Stripe. We have not verified that for every plugin, and you don't need to. You can check in about ten minutes:
- In the Stripe Dashboard, open Billing > Subscriptions. If your members' recurring charges are listed there as subscriptions, Stripe Billing is involved, and step 2 shows whether its retries are on. If you only see standalone payments, our reading of Stripe's page is that Stripe is not running a subscription retry schedule for them, and something else has to.
- Open Billing > Revenue recovery > Retries. Read the schedule, and read what happens when the last retry fails: Stripe lets you cancel the subscription, mark it unpaid, leave it past due or pause it.
- If you run WooCommerce Subscriptions, open WooCommerce > Settings > Subscriptions and look at Payment recovery. If it was never switched on, WooCommerce Subscriptions' own retry system isn't running.
- If you run MemberPress, open Settings > Emails and confirm the failed transaction notice is on.
- Pick one real failed renewal from last month. Follow it from the charge failing to the member's access. Write down what retried, what the member was emailed, and what happened to their access. That last answer is the one nobody can document for your exact setup, so this is how you learn it.
Which failed payments are never retried?
Hard declines are not retried. Stripe's documentation says it doesn't retry payments when no payment method is available or when the issuer returned a hard decline code. The hard decline codes include incorrect_number, lost_card, pickup_card, stolen_card, revocation_of_authorization, authentication_required and transaction_not_allowed. For those, retries only run after Stripe detects a new payment method.
So no schedule will fix them. The member has to supply a new payment method, which means the email and the update page matter more than the retry count. If your members are logged out when the email lands, they need a way to update that doesn't depend on a login. If your renewals are automatically charged Stripe Billing subscriptions, Stripe's failed-payment emails can include a link to a Stripe-hosted page, which Stripe describes as a secure, private URL. Otherwise, use your membership plugin's own payment-update flow, or have a developer build a page on your site. Either way, make sure the update reaches the payment method that is actually charged.
Two Stripe details are easy to miss:
- Update the right field. Stripe's documentation says that if a subscription has its own default payment method and you only update the customer's default, Stripe keeps retrying the subscription's one. A card update that never reaches the object being charged can look fixed to the member while the old method keeps getting charged.
- Turn on the failed-payment email. It is a Stripe setting, and when it is on Stripe emails the customer after each failed payment with a way to update their payment method. Stripe's documentation also describes an email sent one month before a card expires, and says it keeps logs of emails sent in the last 60 days.
Stripe's card documentation says Stripe works with card networks and automatically attempts to update saved card details when a customer receives a new card. Its documentation adds that it isn't possible to identify which cards support automatic updates, so don't build your recovery process on it.
The silent failures: where payments fail without anyone seeing
The hardest failures to catch show no error message, and nothing looks wrong until someone checks. These are general places to check.
Stripe says paid, your site says nothing
When the payment succeeded in Stripe but the membership didn't update, look at the webhook first. MemberPress's Stripe documentation says it directly: if the transaction isn't completed in MemberPress but is marked as such in Stripe, this is related to the webhook URL.
Stripe shows you the evidence. In Workbench (see Stripe's webhooks documentation), select your webhook endpoint and open the Event deliveries tab: each event is Delivered, Pending or Failed. Stripe retries undelivered live events for up to three days with exponential backoff, and you can resend a specific event from the Dashboard for up to 15 days. If you see failed deliveries, start with our guide to troubleshooting common MemberPress and Stripe problems.
Renewals that never get attempted
A retry engine can't retry a charge that never started. WordPress runs scheduled tasks through WP-Cron, and the WordPress developer handbook says it only fires on page load: it does not run constantly the way a system cron does. WooCommerce Subscriptions runs renewals, retries, trial ends and expirations as scheduled events. Its store manager guide has a “Processing reliability” section with an option to run those events in a dedicated batch, “reducing delays caused by other scheduled actions on your site.” Check what it is set to on your site.
If your renewals depend on scheduled tasks, check whether those tasks ran. This part is our suggestion, not a vendor procedure. The Action Scheduler documentation says its admin screen is at WooCommerce > Status > Scheduled Actions and lets you view actions by status and sort them by scheduled date. If you use WooCommerce Subscriptions, open that screen, sort by scheduled date, and look for subscription actions whose date is already in the past but that have not run. Looking changes nothing. Leave the Run buttons alone until you know what an action will do.
Settings that were never turned on
The WooCommerce retry system is off by default. The Stripe retry schedule is a setting you choose. The failed-payment email is a setting. Each one is a decision someone made, or never made, when the site went live.
A recovered payment that doesn't restore access
A successful retry doesn't finish the job. After a recovery, confirm that membership access comes back and that the CRM follows: failure-state tags, lists and automations in your CRM should move to whatever state you intend after a recovery. Billing, access and CRM state can drift apart.
What we see on real sites
On the membership sites we work on, plugin, CRM, email, payments and accounting often drift apart, and staff cover the gap by hand. A failed payment crosses most of those systems. Unless someone is assigned to watch the handoffs, the first sign can be a member writing in.
Our rule: the processor is the source of truth for money. The membership transaction is the source of truth for access and expiry. The CRM is for outreach, and it follows the other two. Once you've decided which system wins, you know where to look first when a payment fails.
We don't publish a recovery rate. We don't have one we would stand behind. That's why the calculator below uses your numbers.
How much recurring revenue is at risk each month?
Revenue at risk before recovery is the renewal revenue you attempt to collect times the share that fails on the first try. Unrecovered revenue is that amount times the share you don't get back. Enter your own three numbers below, using dollars rather than counts if your prices vary. Nothing is prefilled, and nothing you type leaves this page.
Renewal revenue at risk from failed payments
Type your own numbers. Nothing is prefilled, and nothing you type leaves this page.
Enter your numbers to see the result.
| Per month | Scenario: same every month for a year |
|---|
This is simple arithmetic on your inputs. The yearly column repeats the monthly figure twelve times, so it is a scenario, not a forecast. It ignores payments that recover slowly over several weeks, refunds, and any cancellations that follow a failed payment. It is not an industry benchmark.
To show the arithmetic, here is an example with made-up round numbers, not a benchmark. Say you attempt 50,000 of renewal revenue in a month, 6% of those dollars fail on the first try, and you recover 40% of the failed dollars. Revenue at risk before recovery is 3,000 a month. Recovered is 1,200. Unrecovered revenue is 1,800 a month, or 21,600 if every month looked the same. Each 10 points of recovery share is worth 300 a month on that base. Your numbers will differ, and all three inputs can be read from Stripe or your plugin.
An 8-point check you can run this week
Run these in order, and put a weekly failed-payment review on someone's calendar.
- Open Event deliveries for your Stripe webhook endpoint and confirm recent events show Delivered.
- Confirm which retry engine is live (Stripe Billing's retries, WooCommerce Subscriptions' retry system, or PayPal's rules) and that it is switched on.
- Confirm the failed-payment email is on in Stripe, in your plugin, or both.
- Read Stripe's customer email settings, including the expiring-card email, and confirm they are what you intend.
- Test a card update and check that it landed on the object being charged, not only on the customer record.
- Check that scheduled tasks ran on time, including renewals whose date has already passed.
- Take one recovered payment and confirm access came back and the CRM tags or lists followed.
- Once a week, list last week's failed payments and assign each one an owner. Hard declines need a person to follow up with a link to update the payment method.
Frequently asked questions
How many times does Stripe retry a failed payment?
Stripe's recommended default is 8 tries within 2 weeks, and you can choose a window from 1 week to 2 months, or a custom schedule of up to three retries. Stripe does not retry when no payment method is available or the issuer returned a hard decline code. Those retries only run once Stripe detects a new payment method.
Does WooCommerce Subscriptions retry failed payments automatically?
Only if you turn it on. WooCommerce's documentation says the retry system is off by default, and when enabled it applies five default retry rules over 7 days to eligible subscriptions on automatic payments.
Why does Stripe show a payment as paid when my membership site didn't update?
MemberPress's documentation says that is related to the webhook URL. Check the Event deliveries tab for your endpoint in Stripe to see whether events are Delivered, Pending or Failed. Fix the endpoint first. Stripe says endpoints can receive the same event more than once, so before you resend failed events, make sure your handler ignores events it has already processed.
How do I get a member who is logged out to update their card?
If your renewals are automatically charged Stripe Billing subscriptions, Stripe's failed-payment emails can include a private link to a Stripe-hosted page where the member updates their payment method. Otherwise, use your membership plugin's own payment-update flow, or have a developer build one on your site that updates the payment method actually being charged.
Will Stripe update expired cards on its own?
Sometimes. Stripe works with card networks and attempts to update saved card details when a customer receives a new card, but its documentation says you can't identify which cards support it. If you turn on its expiring-card email, Stripe also emails customers one month before a card expires.
Next step
Our free membership site audit is an outside-in look, so it can't see your billing settings, webhooks, logins or access flows. If you want someone to go through those against your live setup, a technical audit of your billing setup is the paid, deeper version, and it starts from $1,000. If you would rather have one team that handles development, support, hosting, troubleshooting and planning, that is what Managed TechOps for WordPress membership sites is for. Either way, you can Book a chat and we'll tell you what we'd check first.
Reviewed by Vic Dorfman, founder of MemberFix. We maintain WordPress membership and billing setups for a living. Last reviewed: October 2026.
