WooCommerce order stuck on "Pending payment": how to tell paid from unpaid, and fix the cause

Go to WooCommerce, then Settings, then Products, then Inventory. Two settings decide whether unpaid orders are canceled.

• Manage stock, with the checkbox "Enable stock management". With it off, the next field is hidden and nothing is canceled.
• Hold stock (minutes). Its description reads: "Hold stock (for unpaid orders) for x minutes. When this limit is reached, the pending order will be cancelled. Leave blank to disable." A new store has 60.

With WP-CLI, read both:

The first line should be yes and the second a number. An empty second line means the field is blank, and unpaid orders are never canceled.

Tick the checkbox, type a number of minutes and press "Save changes". Use the screen for this and not WP-CLI: saving here also puts the cancellation on WooCommerce's schedule. Leave customers time to finish paying. The limit counts from the last change to the order.

One row should come back, with a date no further ahead than the limit you set. Dates are in UTC.

When the time is up the order moves to "Cancelled" with the note "Unpaid order cancelled - time limit reached.", its held stock is released, and the store receives the "Cancelled order" email. Only orders that came through the checkout are canceled this way.

Run the list command from the fix above, or go to WooCommerce, then Status, then Scheduled Actions and search for woocommerce_cancel_unpaid_orders. The guide to WooCommerce's database update describes that screen. A pending row whose date has passed means the queue is not being run. No row at all means the limit is blank or stock management is off: use the fix above.

This cancels every "Pending payment" order from the checkout that is older than the limit, paid or not. Check the ones customers have asked about at the provider first.

It prints "Completed processing action" with the hook's name. Without WP-CLI, choose "Run" under the row on the Scheduled Actions screen.

Action Scheduler's queue is started by WP-Cron, and WP-Cron runs only when a page is loaded and the site can send a request to itself.

"Success: WP-Cron spawning is working as expected." rules this out. An error that names DISABLE_WP_CRON, an HTTP status or a connection failure is the cause. Each has its fix on the page about the "Missed schedule" error, which is the same fault seen on a scheduled post.

Once the test reports success, the next row should complete within a minute or two of its date, as long as pages are being loaded.

Go to WooCommerce, then Settings, then Payments, and open the gateway's settings. Most show the notification address or the state of the connection. Two examples from the extensions' own documentation: the Stripe extension listens at https://example.com/?wc-api=wc_stripe, sets its webhooks up when you connect the account, and has a "Reconfigure webhooks" button. PayPal Payments has a "Webhooks Status" section with "Resubscribe" and "Simulate" buttons.

Find the notification for a stuck order's payment. At Stripe, the "Event deliveries" tab of the webhook endpoint lists each event as Delivered, Pending or Failed, with the HTTP status code your site answered. PayPal's IPN history page does the same for IPN messages.

No notification is set up for this site in this mode. Use the gateway's own button to set it up again, or add the address at the provider as the gateway's documentation describes.

An old domain, a staging copy, http where the site uses https, or www where the site has none. Correct it to the address the site answers at now.

Test and live are separate. Stripe's documentation says each endpoint has its own signing secret, and that the secret differs between test and live even for the same address. A gateway holding the wrong one cannot check the signature and rejects the notification. Copy the secret for the live endpoint again, or reconnect the gateway.

Send an empty request to the address from the gateway's settings or the provider's log. Run it in a terminal on your own computer, so that it passes whatever stands in front of the site. The quoting is for macOS and Linux.

It prints the status code, and the address it was sent on to if there is one.

WooCommerce's own "Coming soon" mode is not in this list. It replaces pages for visitors and leaves these addresses answering.

Copy .htaccess somewhere outside the site's folder, then remove the rule that refuses the address. If nothing is printed, look in the security plugin's or the host's firewall log at the time of a failed delivery, and allow the notification address there. Stripe's documentation says its webhooks come from a published list of IP addresses.

Run the first command again. An answer of 400 or 200 means the request now reaches WooCommerce.

Your own request does not come from the provider's servers. A firewall that decides by address, by country or by the kind of client can let you through and still refuse the provider. The provider's delivery log has the last word: resend one failed notification from there and watch the order move to "Processing". If changing an address leaves the site redirecting in a circle, see ERR_TOO_MANY_REDIRECTS.

Go to WooCommerce, then Status, then Logs, and open the newest fatal-errors log. WooCommerce keeps that log without being asked. Or read it from the site's folder:

Look for an entry at the time of a failed delivery. "No such file" means WooCommerce has logged no fatal error. Then turn on logging in the gateway's own settings, if it has the option, and read its log on the same screen after the next payment.

The entry names the file that failed. The folder under wp-content/plugins/ is the plugin at fault.

Whatever that plugin does for the store stops while it is off. If the path names the gateway itself, do not switch it off: update it and send the error to its author.

Update the plugin, or leave it off until its author has fixed the error. The critical error page covers switching a plugin off without WP-CLI.

Resend it from the provider's delivery log. The answer should now be 200 and the order should move to "Processing". The resend is the provider's side.

Replace 123 with the order's number. --user=1 runs the command as the user with ID 1, usually the first administrator. WooCommerce's commands refuse to run without a user who may manage orders.

created_via says how the order was made. checkout and store-api are the checkout. admin is "Add order" in the dashboard, and rest-api is another system writing through WooCommerce's API. Only the first two are canceled by the time limit. A date_paid or a transaction_id on a pending order means it was paid once and then set back.

The "Order notes" panel on the order screen records every change of status, newest first. A change made by a person on that screen has "by" and their name under it. A note WooCommerce or a plugin wrote by itself has none. With WP-CLI:

A line such as "Order status changed from Processing to Pending payment." gives the time. Ask the person named, or look at what a plugin that manages order statuses did at that minute.

A paid order goes back to "Processing", as in the last fix. An unpaid one nobody is waiting for is canceled on the order screen, or with:

On the Orders screen, choose "Pending payment" above the list. Or:

Add the "Cancelled" orders with the time-limit note from the same days.

Do not ship on a customer's word, a screenshot or a forwarded receipt. An order counts as paid when the provider's dashboard shows a successful payment for it.

Once the cause is fixed, have the provider send the notification again. The gateway then records the payment as it would have, transaction ID included. Stripe's documentation says it retries failed deliveries for up to three days in live mode, and that an event can be resent from the Dashboard for up to 15 days. PayPal's IPN history has a "Resend selected" button.

Open the order, choose "Processing" under Status and press "Update". Or:

Stock is reduced, the store gets the "New order" email, the customer gets the "Processing order" email, and the paid date is set to now, as the notification would have done. It works the same on an order the time limit canceled. The provider's transaction ID is not recorded, so add it to the order as a private note.

Leave them to the time limit, or cancel them on the order screen.