A renewal has three parts: a scheduled task that fires, a payment method that is still valid, and a gateway that accepts a payment nobody is present to authorise. Any of them can break independently, and the visible symptom — subscriptions lapsing — is the same. Establishing which is failing is the diagnosis.
Before you buy, one quick look
Read-only.
Look at your gateway dashboard for a failed renewal. Was a payment attempted at all?
Attempted and declined — that is a payment problem, often expired cards or authentication rules.
No attempt made — the renewal never fired, which is scheduling or integration. Different problem entirely.
Note which, and roughly when it started. Both go in your order notes and save us a step.
Subscription renewal failure diagnosis
Subscription renewals are failing and customers are losing access. We find whether the failure is payment, scheduling or integration, and fix it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Renewals not attempted at all | This fix covers it |
| Renewals attempted and declined | This fix covers it |
| One-off payments also failing | Payment gateway integration errors |
| Payment taken, access not extended | PayPal / Stripe webhook repair |
| Scheduled tasks failing generally | WP-Cron not firing |
What you are seeing
- Subscriptions lapsing when they should renew
- Customers losing access despite having a valid payment method
- Renewal orders created but never paid, or not created at all
- The gateway showing failed attempts, or no attempts
- It may affect all subscriptions or only some
Common causes
- Scheduled tasks not running, so renewals never fire
- Payment tokens invalidated by a gateway or account change
- Strong authentication requirements the gateway cannot satisfy unattended
- Webhooks failing, so successful payments never extend access
- Cards genuinely expired, which needs customer action rather than a fix
What we do
- Take a full backup before touching anything
- Establish whether renewals are firing, and whether payment is attempted
- Check scheduled tasks, payment tokens and webhook delivery in turn
- Fix the failing layer and verify the whole chain end to end
- Identify subscriptions that lapsed and can be recovered
- Monitor the next renewal cycle to confirm it holds
What is included
- Renewals processing correctly, verified through a full cycle
- A note naming which layer was failing and for how long
- A list of affected subscriptions and which can be recovered
- The pre-fix backup, kept for 30 days
Not included
- Contacting customers to update expired payment details
- Recovering revenue from subscriptions that lapsed and cancelled
- Building custom subscription logic, which we quote separately
- Design changes or content work
Questions about this fix
How many customers have I lost?
The subscription records tell us, and the count is in the note. Some lapsed subscriptions reactivate cleanly once the mechanism works; ones that cancelled need the customer to return, and we are honest about which is which.
Renewals stopped after I changed payment provider.
Then tokens are the likely cause. Stored payment methods belong to the old gateway and do not transfer, so renewals have nothing to charge. That usually needs customers to re-enter details, and we will tell you if that is the position.
Some renew and some do not. Why?
Often authentication rules. Cards issued in regions requiring strong customer authentication can fail unattended renewals while others succeed. The gateway logs show it clearly and there are ways to configure around it.
Can renewals be retried automatically?
Yes, and it should be configured. Most failures are transient — a temporarily declined card that works two days later. Retry scheduling recovers a meaningful share, and we set it up as part of this.
Can I tell in advance which subscriptions are at risk of failing?
To some extent — cards close to their expiry date are the clearest warning sign, and we can pull that list as part of the diagnosis so you can reach out before renewals actually fail.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.