LifterLMS Recurring Payments Not Processing? How to Fix Renewals

When LifterLMS recurring payments stop processing, revenue quietly stops and students start losing access. The good news is that LifterLMS leaves a trail. Every skipped or failed renewal adds a note to the order, and most problems come down to five causes: the staging lock, cron not running, a gateway problem, a declined card, or missing data.

This guide is for course owners and developers running subscriptions or payment plans. It explains how a renewal actually happens, how to read the order notes, and how to fix each cause, including the tools in LifterLMS > Status that reschedule renewals safely.

How LifterLMS recurring payments renew

Recurring billing in LifterLMS works like this:

1. When a recurring order becomes active, LifterLMS schedules a llms_charge_recurring_payment action for the next payment date in the Action Scheduler, the background job system bundled with LifterLMS.
2. When that time comes, and the scheduler runs, LifterLMS checks that the order and the student still exist, that the order's payment gateway is active and supports recurring payments, that Automatic Recurring Payments is enabled for the site, and that the purchased product still exists.
3. If all checks pass, the gateway add-on, such as LifterLMS Stripe, charges the saved payment method.
4. On success, a transaction is recorded and the next payment is scheduled. On failure, the retry rules take over.

Each step can stop a renewal, and each leaves different evidence. If you are still setting up plans, our guide to payment plans and free trials covers the configuration side.

Start with the order notes

Open the order under Orders and read the notes panel. These messages come straight from LifterLMS:

Order note	Meaning
"Recurring charge skipped because recurring payments are disabled in staging mode."	The staging lock is on
"Recurring charge was not processed due to an error encountered while loading the payment gateway"	The gateway add-on is inactive or misconfigured
"Recurring charge skipped because recurring payments are disabled for the payment gateway."	The gateway no longer supports recurring charges
"Recurring charge skipped. The user (#...) no longer exists."	The student's account was deleted
"Recurring charge aborted because the purchased product does not exist anymore."	The course or membership was deleted; the order is cancelled
"Automatic retry attempt scheduled for ..."	A charge failed and a retry is queued
"Maximum retry attempts reached."	All retries failed; the order is now Failed
No note at all on the due date	The scheduled action never ran: check cron

For more detail, the recurring-payments log under LifterLMS > Status > Logs records the same failures with order IDs.

Cause 1: The staging lock is on

LifterLMS stores a copy of your site URL. If the current URL no longer matches, it assumes the site is a staging copy and disables automatic recurring payments, so a clone never charges your real customers twice. That is exactly what you want on staging, and exactly what you do not want after moving the live site to a new domain, switching to HTTPS, or restoring a backup.

Signs and fixes:

• A Staging badge appears next to the Orders menu, and an admin notice asks whether to keep automatic payments disabled.
• LifterLMS > Settings > General shows Automatic Recurring Payments as disabled in the Features section.
• On the live site, choose Enable Automatic Payments in the notice. If the notice is gone, run Reset Automatic Payments Status under LifterLMS > Status > Tools & Utilities to bring it back.

Re-enabling payments after a period in staging mode can cause renewals that were skipped to be handled late, so read the official staging documentation and our guide to staging sites and recurring payments before you switch it on. Version 10.3.0 tightened how LifterLMS blocks charges when the URL changes, so keep core up to date.

Cause 2: Cron and scheduled actions are not running

If there is no note at all on the due date, the scheduled charge never ran. The Action Scheduler depends on WP-Cron and on loopback requests from your server to itself, and both are commonly broken by:

• DISABLE_WP_CRON in wp-config.php without a real server cron job.
• Low traffic, since WP-Cron only runs when someone visits the site.
• HTTP basic authentication, a firewall or a security plugin blocking loopback requests.
• PHP errors or timeouts that kill the queue runner part way through.

To check and fix:

1. Open LifterLMS > Status > Scheduled Actions and search for llms_charge_recurring_payment. Pending actions with a date in the past mean the queue is not running. Failed actions show the error that stopped them.
2. Check Tools > Site Health for loopback and scheduled event warnings.
3. Ask your host for a server cron job that runs WP-Cron every few minutes. With WP-CLI available, wp cron event run --due-now does the job.
4. To process overdue renewals now, run wp action-scheduler run --hooks=llms_charge_recurring_payment, or use the run link on each action in the Scheduled Actions screen.
5. If active orders have no scheduled action at all, run Reschedule Recurring Payments under Tools & Utilities. It checks active recurring orders and reschedules any payment that is due but missing.

A broken cron also delays emails, so if students report missing reminders too, see fixing LifterLMS emails that do not arrive.

Cause 3: A gateway problem

The renewal is handed to the order's gateway add-on, so anything that breaks the add-on breaks renewals:

• The add-on was deactivated, or its gateway disabled, under LifterLMS > Settings > Checkout. Orders keep their original gateway; they do not move to another one.
• API keys changed, or the live site is pointed at test mode or a different gateway account.
• Webhooks failing. Where a gateway reports payment results back to your site through webhooks, check the gateway's dashboard for failed deliveries to your site and fix the endpoint URL or signing secret.
• Outdated add-on. Keep gateway add-ons current with core.

For Stripe-specific setup, see our LifterLMS Stripe guide.

The Manual gateway is a special case: it cannot charge anyone. When a renewal falls due on a manual order, LifterLMS puts the order on hold until you record the payment, which is expected behaviour, not a fault.

Cause 4: Declined cards, retries and on-hold orders

When a charge is declined, Retry Failed Payments under LifterLMS > Settings > Checkout decides what happens next. It is on by default and works with gateways that support retries, which the retry documentation lists as Stripe, Authorize.Net and PayPal with reference transactions.

The default schedule retries after 12 hours, then after 1, 2 and 3 more days, with the student notified from the second attempt. During retries the order is On Hold. After the last failure the order becomes Failed. Developers can change the schedule with the llms_order_automatic_retry_rules filter.

Two consequences catch site owners out:

• Access is suspended during retries. When an order goes on hold, the student's enrollment is set to Cancelled until a payment succeeds and the order is active again.
• Older versions never retried in one case. Version 10.2.0 fixed automatic retries never running when a failed payment put an active order on hold. If retries are not happening, update first.

Students fix a declined card themselves from the order on their Student Dashboard, using Update Payment Method, where they can save a new card and pay the amount due.

Log every skipped renewal

LifterLMS fires an action for each reason a renewal can stop. A developer can collect them into one log to spot patterns across many orders:

<?php
$llmsx_renewal_hooks = array(
	'llms_order_recurring_charge_skipped'                 => 'staging mode',
	'llms_order_recurring_charge_gateway_error'           => 'gateway unavailable',
	'llms_order_recurring_charge_gateway_payments_disabled' => 'gateway does not support recurring',
	'llms_order_recurring_charge_user_error'              => 'user missing',
	'llms_order_recurring_charge_aborted_product_deleted' => 'product deleted',
);

foreach ( $llmsx_renewal_hooks as $llmsx_hook => $llmsx_reason ) {
	add_action(
		$llmsx_hook,
		function ( $order_id ) use ( $llmsx_reason ) {
			llms_log( sprintf( 'Renewal stopped for order #%d: %s', $order_id, $llmsx_reason ), 'renewal-audit' );
		},
		10,
		1
	);
}

Pair it with a weekly look at Scheduled Actions and you will catch problems before customers notice.

Frequently asked questions

Why did a student lose access when their card was declined?

A failed renewal puts the order on hold while LifterLMS retries, and an on-hold order cancels the enrollment until payment succeeds. Access returns automatically when the order becomes active again.

Can I charge an overdue renewal manually?

Run the pending llms_charge_recurring_payment action from Scheduled Actions or with WP-CLI once the underlying cause is fixed. Check the order notes afterwards.

Why are renewals disabled after I moved my site?

The site URL changed, so LifterLMS's staging protection switched automatic payments off. Re-enable them from the staging notice on the live site.

Do payment plans renew the same way as subscriptions?

Yes. A payment plan is a recurring order with a fixed number of payments, so the same scheduling, checks and retries apply.

What to do next

Open one affected order, read its notes, and match them to the causes above. Then check Scheduled Actions for overdue renewals before you fix anything else, so you know how many orders are affected.

If renewals are failing at scale, after a migration or across gateways, our LifterLMS support team can audit orders and scheduled actions and recover missed payments safely. Contact us with an example order number.