Job woo-orders-stuck-pending-after-payment · revised 11 October 2026
Fix WooCommerce orders that stay unpaid after the customer has paid
On a store copy, a successful test payment moves the order to the status you expect, the gateway reports the delivery as received, and a repeat delivery changes nothing twice.
You might be seeing
- Payments show as successful at the payment provider but the order is still Pending payment
- Orders sit On hold and never become Processing
- Customers get no order confirmation email
- Unpaid orders are cancelled automatically while payment was taken
No passwords, keys, card details or admin invites needed to start.
What usually happened
For many payment methods the gateway tells the store about the result with a separate message, a webhook, after the customer has left the checkout page. If that message cannot reach the store, because a redirect, a security rule, a changed address or a deleted endpoint blocks it, the payment is real but WooCommerce never hears about it, so the order never changes status.
Who it’s for: Owner of a WooCommerce store whose customers are charged but whose orders stay on Pending payment or On hold.
Usually starts when: Customers email to say they paid, the payment shows in your payment account, and the order in WooCommerce never moves on.
The result: On a copy of your store with the gateway in test mode, a successful test payment moves the order to the agreed status with the right note and stock change, the provider shows the delivery as received, and a repeat delivery causes no second change.
Check whether this job fits
Five questions, about two minutes. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Match payments to orders
List the payments for one day from your provider dashboard, order numbers and amounts only, and the WooCommerce order statuses for the same day.
Look for: Payments that succeeded where the order is still Pending payment or On hold.
Read the delivery log
In your provider dashboard, open the webhook or event delivery list and look at the most recent entries.
Look for: Entries marked failed or pending, and the status code shown beside them, such as a redirect or an access error.
What you get
- A note naming where the confirmation was lost, with redacted delivery-log evidence
- The corrected store-side settings and the dashboard or host change you or your host must make
- A test table: payment outcome, event delivered, resulting order status, stock change
- A checklist you can use to match paid payments to orders that are still pending
- Steps to apply the changes to the live store and to undo them
Included
- One payment gateway connected to WooCommerce, with its webhook or callback address and delivery log
- Finding why confirmations do not reach the store or are not applied: address, redirect, security rule, caching, missing endpoint or mismatched mode
- Correcting the store-side settings and giving you the exact change needed on your gateway dashboard or host
- Test payments with success, failure and a repeated delivery
Not included
- Changing or repairing historic orders on the live store
- Refunds, disputes or any reconciliation of money with your payment provider
- Adding a new payment gateway
- Any live card charge
- Payment provider account problems, or fixing a gateway plugin that has a bug of its own
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On staging in test mode, a successful test payment moves the order from Pending payment to the agreed status and reduces stock once
Evidence: Order notes, order status and the stock figure before and after
The provider delivery log shows the confirmation event as delivered with a success status
Evidence: A redacted screenshot of the delivery entry
A declined test payment leaves no paid order, and a second delivery of the same successful event changes nothing
Evidence: Order list screenshot and the order notes after the repeat
The matching checklist, run on staging test data, lists every paid test payment whose order is not in the agreed paid status
Evidence: The checklist output for the staging test data
Sign-off. You review the test table and the delivery evidence and sign off before payment. Live changes and the handling of historic orders are separate steps you take.
If it fails. If the checks do not pass, you do not pay, and we hand over what we found so anyone can continue.
When it fits, and when we stop
It fits when
- The gateway has a test or sandbox mode and a delivery log you can read
- A staging copy reachable over HTTPS from the internet exists, or your host can make one
- You or an authorised person can read and change the webhook settings in your gateway dashboard
- Orders are going missing from Processing on payment, not failing at checkout
We stop and tell you if
- The fault only appears with live payments and cannot be reproduced in test mode
- Your host controls a firewall rule and will not change it, so the fix is outside the store
- There are signs of a compromise, such as unknown admin users or altered payment forms
- The delivery log shows the store answered correctly and the fault is in the provider account
What could go wrong
Store-side changes are listed with their previous values so they can be reversed, and any dashboard change is described with how to remove it. We do not change the live store.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A secret or live key ends up in a screenshot or note | We ask only for redacted screenshots, never handle live keys or signing secrets, and discard files after sign-off. |
| A staging copy receives live deliveries and changes real orders | Staging uses its own test-mode endpoint and the live endpoint stays untouched. |
| Allowing the provider through a firewall opens more than intended | Any rule is the narrowest that lets the confirmation through, and your host approves it. |
| Unpaid orders are cancelled by the stock-hold setting before the fix is live | The handover tells you how to find paid orders that were cancelled and which you must handle yourself. |
A second reviewer checks any change that touches payment handling, that no key or signing secret appears in our notes, and that your site holder can apply and reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Confirm the staging copy is reachable over HTTPS, with the gateway in test mode and customer email off
- Read the redacted delivery log and the order notes for an affected order
- Find where the confirmation stops: address, redirect, security rule, caching, missing endpoint or mode mismatch
- Make the store-side correction on staging and specify the dashboard or host change
- Run a successful, a failed and a repeated test delivery and record the order status and stock each time
- Independent review of anything touching payment handling, then hand over the evidence; your site holder applies it live
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, app and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a recurring test of the confirmation path after updates as a separate agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- If you use the WooCommerce Stripe extension, its documentation describes how to recreate the webhooks from the plugin settings. Try that on a copy first and see whether deliveries start succeeding.
- Your payment provider support can confirm from their side whether deliveries to your address are failing, which is often the quickest first step.
Questions
Do you need my payment account login or keys?
No. We work in test mode on a copy and ask for redacted screenshots only. You or your host make the dashboard change.
Will this fix orders that are already stuck?
It fixes the cause so new orders update. For existing ones you get a checklist to find paid-but-pending orders; you handle them under your own account.
What if the fault is on my host?
Then we tell you exactly what to ask the host to change, and the fixed job may not apply.
Send an enquiry
Send us
- Which payment gateway, and which payment methods stay unpaid
- Three recent affected order numbers and when the customer paid, with names removed
- What changed recently: domain, HTTPS, host, security plugin, caching or WooCommerce version
- Whether the provider dashboard shows deliveries as failed, pending or delivered
- WooCommerce and gateway plugin versions, if you know them
Later, once you agree
- A staging copy shared the way you choose, with a staging admin login rather than your live one
- Redacted screenshots of the gateway delivery log, with no keys or signing secrets in them
- You, or your host, making the dashboard or firewall change we specify
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the live store, hosting account, payment account and admin logins. We never see live keys or signing secrets, work in test mode on a copy, and you or your host make any change on the gateway dashboard or server.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “woo-orders-stuck-pending-after-payment” as the subject.