Start with the only question that matters: did money move?
A customer says they paid, but WooCommerce still shows Pending payment. That does not automatically mean the order failed. It means WooCommerce has not recorded the payment confirmation it expected.
Before changing the order status, check the payment provider itself. Search for the charge using the order number, customer email, amount, and payment time. Record whether the provider shows a successful charge, a temporary authorization, a failed attempt, or no transaction at all.
This first check protects both sides. If no charge exists, manually marking the order paid could release goods without payment. If a successful charge exists, asking the customer to pay again could create a duplicate charge.
What WooCommerce Pending payment actually means
WooCommerce uses Pending payment for an order it has received but has not confirmed as paid. The official WooCommerce order-status guide describes it as an order awaiting payment.
In a normal card-payment flow, several systems must agree:
- The customer submits checkout.
- WooCommerce creates an order.
- The payment gateway accepts or rejects the payment.
- The gateway sends the result back to the store.
- WooCommerce records the transaction and moves the order to the appropriate paid status.
A customer can complete step three while step four or five fails. That is the gap this article helps you trace.
Use this payment-confirmation evidence matrix
| What you can prove | What it suggests | Next safe action |
|---|---|---|
| No charge, authorization, or payment attempt exists at the gateway | The customer may not have completed payment, or checkout failed before reaching the gateway | Keep the order pending and inspect the checkout or gateway error from that time |
| The gateway shows a failed or cancelled payment | WooCommerce is correctly waiting for payment | Read the provider’s failure reason and give the customer a safe retry path |
| The gateway shows only an authorization or incomplete payment | Funds may be reserved but not captured | Follow the gateway’s capture or authentication state; do not label it paid yet |
| The gateway shows a successful charge with the same amount and customer | Payment likely succeeded, but confirmation may not have reached WooCommerce | Match the transaction ID, order notes, webhook delivery, and logs |
| The gateway shows two successful charges | A retry may have created a duplicate payment | Stop order changes and follow the provider’s duplicate-charge review or refund process |
Do not rely on a customer’s bank screenshot alone. Pending card authorizations can look like completed charges. The payment-provider record is the stronger source for the transaction state.
Trace one order instead of changing the whole store
Use one affected order and build a short timeline. Record the order ID, checkout time, payment method, total, gateway transaction ID, gateway status, latest WooCommerce order note, and any webhook or log entry at the same time.
Keep customer information private. You usually do not need to copy full card, address, cookie, or account data into a support ticket. An order ID, redacted email, timestamps, status, and provider transaction reference are normally enough to connect the evidence.
A single timeline is more useful than clearing caches, resaving payment settings, and disabling several plugins at once. Those changes can remove the original evidence while the paid order remains unresolved.
Match the gateway transaction to the WooCommerce order
Open the order in WooCommerce > Orders and inspect its payment method, order notes, and transaction ID. Then compare those values with the payment provider.
Watch for simple mismatches:
- the customer paid through a different gateway than the order shows;
- the charge amount or currency does not match the order;
- the gateway transaction references a different order ID;
- the payment happened in test mode while the order belongs to live mode;
- the provider completed payment after WooCommerce had already cancelled the unpaid order.
If the transaction ID appears in the gateway but not in WooCommerce, preserve that difference. It often narrows the fault to the return, webhook, or order-update path.
Read the last order note before checking email
Order notes show what WooCommerce recorded, not necessarily everything the gateway attempted. Look for a payment-complete note, a failed-payment message, an authentication step, a stock change, or no gateway note at all.
The absence of a “new order” email does not prove that email delivery is broken. WooCommerce explains in its email troubleshooting guidance that a Pending payment order does not trigger the normal new-order email. If the provider says the payment succeeded while the order remains pending, investigate payment confirmation first. Email is downstream of that status.
This boundary matters because replacing SMTP settings will not repair a missing gateway callback.
Check webhook delivery and the gateway connection
Many gateways use webhooks to notify WooCommerce about payment events that happen outside the customer’s browser. A webhook can fail because its endpoint is missing, blocked, returning an error, or connected to the wrong mode or account.
For the official WooCommerce Stripe extension, WooCommerce’s Stripe setup documentation explains the connection and webhook requirements. Other gateways use different dashboards and event names, so follow the current documentation for the extension actually attached to the order.
In the provider dashboard, find the event for the successful payment and check:
- whether it was sent to the correct live webhook URL;
- whether the delivery returned a successful HTTP response;
- whether the event was retried;
- whether the response time matches a maintenance window, firewall block, or outage;
- whether the webhook secret or account connection recently changed.
Do not paste webhook secrets into chat or public screenshots. Also avoid repeatedly replaying a live event until you understand whether the gateway and extension handle duplicates safely.
Check logs at the payment time, not only today’s errors
WooCommerce logs live under WooCommerce > Status > Logs. The official System Status guide explains where to find version, extension, template, scheduled-action, and logging information.
Select the source that matches the affected gateway and the date of the payment. Search around the exact checkout and webhook times. Useful evidence can include an invalid signature, authentication failure, REST API block, timeout, fatal error, database error, or a message that the order could not be found.
A generic error elsewhere in the log is not automatically the cause. Match the time, order reference, gateway, or request path before changing anything.
Rule out a blocked REST or callback request
Security plugins, hosting firewalls, CDN rules, maintenance mode, basic authentication, and custom code can block a gateway’s callback even while the storefront remains visible.
Compare the failed webhook time with firewall and access logs. Look for the exact callback path and response code. A homepage returning 200 does not prove the payment endpoint worked.
If a rule blocked the request, correct only the documented endpoint or condition. Do not disable the entire firewall on a live store. Retest with the gateway’s supported webhook check or a controlled low-value test order.
Check recent changes before isolating plugins
Ask what changed before the first stuck order. Relevant changes include a gateway extension update, WooCommerce update, security rule, CDN migration, domain change, SSL change, PHP update, checkout customization, subscription extension, or payment-account reconnection.
Save the current system report and logs before rolling anything back. If a plugin or theme conflict is plausible, reproduce the exact payment flow on staging. Keep WooCommerce and the affected gateway active, then change one relevant component at a time.
Do not test a live card repeatedly or disable every business plugin during active sales. A controlled test should prove order creation, payment confirmation, correct status, stock reduction, emails, refunds, and any fulfillment or accounting connection.
When is it safe to change the order status manually?
A manual status change is an administrative decision, not a repair. Consider it only after the payment provider confirms a successful transaction that matches the order’s customer, amount, currency, and reference.
Before changing the order, check what the new status will trigger. Depending on the store, it may reduce stock, send emails, start fulfillment, create invoices, grant downloads, renew a subscription, or push data to another service.
Record the original state and transaction evidence in a private order note. If duplicate capture, refund, subscription, tax, or fulfillment behavior is unclear, stop and involve the gateway or a WooCommerce specialist. Do not use a manual status change to hide an unresolved webhook failure; the next order may get stuck for the same reason.
Know who should own the next action
| Evidence | Likely owner | Stop condition |
|---|---|---|
| No successful payment exists | Customer, gateway decline guidance, or checkout configuration | Do not release the order as paid |
| Successful payment exists, but the provider could not deliver its webhook | Gateway setup, hosting, firewall, CDN, or site maintenance | Do not keep replaying live events without duplicate-event safeguards |
| Webhook delivery succeeded, but WooCommerce did not update the order | Gateway extension, order code, database, or plugin conflict | Preserve logs and reproduce on staging before changing the live stack |
| Only emails are missing after the order reached a paid status | WooCommerce email configuration or mail delivery | Keep payment diagnosis separate from SMTP diagnosis |
| Several paid orders are accumulating | Urgent store operations and technical incident response | Pause risky changes and protect fulfillment from duplicate or unpaid orders |
Retest the complete order path after the repair
A repaired webhook is not the final test. Place one controlled order using the affected gateway and confirm the complete chain: checkout success, gateway charge, webhook delivery, WooCommerce transaction ID, paid status, stock, customer email, admin email, refund path, and connected fulfillment or accounting tools.
Use the Webless WooCommerce checkout testing checklist to record the wider path. Keep the original stuck-order scenario in the test plan so the repair addresses the real failure.
Need help tracing a paid order that stayed pending?
Webless can compare the gateway transaction, WooCommerce order notes, webhook delivery, logs, security rules, and recent changes without treating a manual status change as the permanent fix.
Our WordPress maintenance service covers safe updates, monitoring, backups, and recurring WooCommerce checks. When the fault sits in a gateway extension, custom checkout, webhook integration, or order workflow, WordPress development support can repair the responsible layer and test the full order path.
For an active paid-order problem, contact Webless with the redacted order ID, payment method, transaction time, gateway status, and the latest WooCommerce order note. Do not send card numbers, passwords, API keys, or webhook secrets.
The shortest diagnosis follows the money and the message
When WooCommerce says Pending payment after the customer paid, separate the financial record from the store record. First prove the gateway transaction. Then match its transaction ID, WooCommerce order notes, webhook delivery, and logs.
That sequence shows whether the customer never completed payment, the gateway could not reach the store, or WooCommerce received the message but could not update the order. It also tells you when a careful owner action is enough and when the live store needs controlled technical help.