Order status pending payment -> cancelled -> processing. Why?

Hi @cyrix2000,

I’d be happy to help you understand why WooCommerce is setting orders to “cancelled” after failed payment attempts.

The behavior you’re describing is typically controlled by WooCommerce’s Hold Stock setting. When a payment fails, WooCommerce doesn’t immediately cancel the order. Instead, it holds the stock for a specified time period to allow for retry attempts. However, once that time limit expires without successful payment, the order status automatically changes to “cancelled.”

Here’s what’s likely happening:

1. Under WooCommerce → Settings → Products → Inventory, there’s a “Hold stock (minutes)” setting that determines how long WooCommerce waits before cancelling unpaid orders
2. If this is set to something like 60 minutes (the default), any order that remains unpaid after that time gets automatically cancelled
3. When the second payment attempt succeeds after cancellation, WooCommerce updates the status to “processing”

To prevent this issue with your inventory management system, you could:

• Increase the hold stock time limit to give more time for payment retries
• Set the hold stock field to blank to disable automatic cancellation entirely
• Check if your payment gateway has specific retry settings that might conflict with this timing

That said, what payment gateway are you using, and what’s your current hold stock setting configured to?

Looking forward to your response.

Hi @cyrix2000

I understand how disruptive it is when an order flips to cancelled within a minute, then back to processing on a successful retry, especially with an inventory system that locks cancelled orders. Let’s pinpoint who is changing the status so you can stop the premature cancellation.

Here is the quickest way to isolate it.

1. Check the order notes Open one of the affected orders and review the time-stamped order notes. You will see which component changed the status and why. Core auto cancellation via Hold stock appears as a scheduled task note, while payment gateways usually add a note like “Status set to cancelled by {gateway} due to failed payment” or a webhook event.
2. Enable and review Revolut logs Go to WooCommerce, Status, Logs, choose the Revolut log for the time of the test, and look for entries around the moment it was set to cancelled and then to processing. If logging is off, enable it in WooCommerce, Settings, Payments, Revolut, save, reproduce a test, then share the log.
3. Confirm gateway settings that can cancel on failure In WooCommerce, Settings, Payments, Revolut, open Settings and Advanced sections and check for options that cancel orders on first failure or user cancellation at checkout. Some gateways map an immediate failure or abandoned redirect to cancelled rather than failed, which bypasses the Hold stock window.
4. Verify scheduled actions Go to WooCommerce, Status, Scheduled Actions and search for “woocommerce_cancel_unpaid_orders.” If the Hold stock window is 60 minutes, the core canceller would not run at 1 minute. If you see a custom action from a gateway or plugin running near 15:04, that is your culprit.
5. Webhook sanity check In your Revolut dashboard, review recent webhook events for the order. Duplicate or out-of-sequence events can set cancelled first, then a subsequent success flips it to processing.

Mitigations you can apply right now.
• Increase Hold stock, or leave it blank to disable auto cancellation if your integration must never see cancelled before final outcome
• Adjust Revolut settings if it provides a toggle to treat first failure as failed rather than cancelled
• Update your inventory app mapping so that a cancelled immediately followed by processing within a short window does not lock the order

To help us confirm, please share:
• A redacted screenshot of the order notes for one affected order showing the three status changes with timestamps via https://snipboard.io
• Your System Status Report via https://pastebin.com
• The Revolut gateway log covering the same timeframe via https://pastebin.com

Once we see which component posts the cancelled event, we can suggest the precise setting to change or the safest workaround for your flow. Feel free to let us know how it goes.

Hi there!

Thank you for sharing the system status report. Currently, everything appears to be fine. I can see that you’re using 91 plugins on your site, and I suspect that one of them may be causing the issue.

To assist you further, could you please install this plugin: https://d.pr/f/vb8o9m?
This plugin will generate logs that show exactly what is changing the order status. Please share those logs with us if you’re unable to interpret them yourself.

Hi @cyrix2000,

Thanks for sharing both the order notes screenshot and the log — that’s very helpful.

From the information you’ve provided, we can clearly see that the behavior differs depending on the payment gateway:

• Orders processed through PayPal correctly move from Pending payment → Failed → Processing when retried successfully.
• Orders processed through Revolut, however, briefly switch from Pending payment → Cancelled → Processing — causing the conflict with your inventory system.

This confirms that WooCommerce’s Hold stock setting isn’t the cause, since its scheduled cancellation wouldn’t run within a minute. Instead, the early Cancelled status appears to come directly from Revolut’s payment gateway response — likely due to how Revolut’s API maps declined or abandoned transactions.

To narrow this down further, I recommend:

1. Reproduce the issue using a small test order via Revolut with logging enabled. Then, review the Revolut log entries around the timestamps where the order moves to Cancelled and then Processing. This will confirm if the gateway is initiating that change.
2. Check your Revolut gateway settings under WooCommerce → Payments → Revolut → Settings. Look for any option related to “Order cancellation on failure” or “void on decline.” If such an option exists, toggle it so failed payments are marked as Failed instead of Cancelled.
3. Confirm webhook behavior directly from your Revolut dashboard — sometimes duplicate or delayed webhook responses can cause status conflicts.

At this point, everything suggests that Revolut is sending a “cancelled” webhook for failed attempts rather than a “failed” one, which PayPal handles correctly. Once you test again with Revolut logging enabled, we can confirm this fully and advise whether the next step would be to raise this behavior with Revolut’s support team for correction.

Let me know once you’ve reproduced the issue and reviewed the logs — that will help pinpoint the exact cause.