If Paystack confirms a successful charge but WooCommerce still shows “Pending payment”, do not ask the customer to pay again. The money and the order status are two separate records. First verify the transaction against the correct order, then find out why the confirmation did not change WooCommerce’s state.
The most common starting point is the Paystack webhook or the return/callback flow. But a delivered webhook is not proof that the store processed it correctly. A plugin conflict, blocked endpoint, wrong environment, mismatched reference or failed order update can leave a paid order looking unpaid.
This guide is for store owners dealing with real orders, not just developers testing a new checkout. It covers immediate containment, a repeatable diagnosis, safe recovery and what a paid repair engagement should deliver.
First: protect the customer and the order
Before changing a setting, record the WooCommerce order ID, Paystack transaction reference, transaction amount, currency, payment timestamp and current order status. Use an administrator account; never paste API secret keys or customers’ payment details into public support tickets.
Compare the Paystack dashboard with WooCommerce Orders → the affected order → Order notes. If Paystack does not show a successful transaction, do not mark the order paid based on a screenshot or browser success page. If it does, confirm that the reference, amount, currency and merchant account match the specific order. Paystack’s Verify Transaction API is the server-side authority for checking a transaction reference; its API-request success flag is not the same thing as the transaction’s data.status.
Temporarily flag affected orders for manual review so staff do not cancel, re-charge, ship twice or send a misleading payment reminder. If a large number of orders are affected, assign one person to own reconciliation while the developer investigates. Preserve the original evidence.
What “Pending payment” actually means
WooCommerce defines Pending payment as an order received without confirmed payment. Processing normally means payment has been received and the order awaits fulfilment; Completed means fulfilment is finished. A paid physical order should not be forced straight to Completed just to hide a webhook problem.
| What you observe | What it suggests | Next check |
|---|---|---|
| Paystack says success; WooCommerce says Pending payment | Confirmation did not reach or update the order | Reference, webhook history and order notes |
| Paystack webhook shows Failed or Pending | Endpoint may be blocked, timing out or returning an error | Delivery response, firewall, server logs |
| Webhook shows Delivered (2xx), order still pending | Server accepted the HTTP request, but business logic may not have updated the order | Gateway logs, matching reference, plugin errors |
| Only some orders are affected | Intermittent callback, timeout, cache or state/race condition | Compare affected and healthy transactions |
| Multiple orders or fulfilments appear for one charge | Retry handling or order association may be unsafe | Idempotency, order IDs and fulfilment history |
A customer’s browser can lose connectivity after paying. The official Paystack WooCommerce extension guidance recommends configuring its webhook URL precisely because the return journey can fail. That is a strong reason to inspect webhooks first, not a reason to assume every pending order has the same cause.
Trace one affected payment from Paystack to WooCommerce
1. Check the actual gateway configuration
In WooCommerce, open Settings → Payments → Paystack and inspect the configured mode, keys and the webhook URL displayed by the installed extension. Compare that exact URL with the one saved in the matching Paystack account and environment. Do not copy a webhook URL from a random tutorial: plugin versions and domain structures differ.
If the website was recently migrated, check whether the webhook still points to an old domain, staging URL, wrong path or a route that redirects unexpectedly. Confirm the public endpoint is reachable and that security plugins, Cloudflare rules and caching are not interfering with incoming POST requests.
2. Read the delivery history, not just the success page
Paystack’s September 16, 2026 dashboard guidance explains how to inspect webhook event type, delivery status, HTTP response and server response body in the new Paystack Dashboard → Developers → Webhooks. Failed events can be retried after the underlying fault is fixed.
A 403 may indicate a firewall or security rule; a 404 can mean the wrong endpoint; a 500 points toward a server-side failure. A 200 response only proves that an HTTP response was accepted, not that the correct WooCommerce order changed state.
3. Inspect the WooCommerce side
Open WooCommerce → Status → Logs and review the relevant payment-gateway and fatal-error logs around the transaction time. WooCommerce’s logging documentation explains where these records live. Also inspect the affected order’s notes and any recent plugin, PHP, theme, caching or checkout changes.
Do not change five settings simultaneously. Reproduce with one controlled test transaction after documenting the current setup, so the cause can be identified rather than guessed.
4. Verify the payment-to-order association
The developer should confirm that the incoming verified payment reference maps to one WooCommerce order, for the expected amount and currency. Investigate duplicate references, a changed order ID, stale session data, a failed callback and whether an extension is trying to update an order that no longer exists in the expected state.
If the webhook is accepted but no order changes, inspect the handler and logs rather than repeatedly resending the same event. Paystack’s webhook documentation requires origin verification and explains retries; handlers must be safe when an event arrives more than once.
How to recover orders that were already paid
Repair the confirmation path first. Then reconcile affected orders one by one or with a carefully reviewed batch process: verify each Paystack reference server-side, match it to its WooCommerce order, confirm it has not already been fulfilled, record the evidence, and apply the appropriate paid state through the supported WooCommerce workflow.
A manual status correction may be appropriate after verified reconciliation, but it does not repair the underlying integration. Never bulk-mark every pending order as paid. Some pending orders genuinely were not charged.
Before replaying failed webhooks, check whether the original attempt already created an invoice, stock deduction, email, entitlement or fulfilment action. Paystack’s webhook retry guidance warns that repeated events must not credit or fulfil the same transaction twice.
If your store also uses a custom app, membership entitlement or external fulfilment system, treat this as a payment-state reconciliation problem, not just a WordPress status-label problem. The same principle applies to duplicate payment webhooks in AI-built apps.
When a developer is worth hiring
A single incorrect URL may be fixable by an experienced store administrator. Professional help becomes more valuable when paid orders keep getting stuck, customers are being asked to pay twice, stock or fulfilment is wrong, or there are conflicting plugins and custom integrations.
For planning, my illustrative repair allowances are $250–$800 for a contained configuration or gateway fault, $1,000–$3,500 for recurring checkout-state failures with reconciliation and regression testing, and $3,500–$8,000+ where custom fulfilment, subscriptions, multiple payment providers or historical order recovery are involved. These are scope-based professional allowances, not surveyed market averages or fixed quotations.
Do not pay for a complete ecommerce rebuild before the developer can show why the existing payment flow cannot be repaired. If the site has broader reliability problems, compare that scope with the cost of website repair and the cost of payment gateway integration.
A useful repair quotation should name the affected environment, the suspected failure, the evidence required, the historical-order recovery plan, the tests, the rollback strategy and who will own monitoring after handoff.
Acceptance tests before calling the checkout fixed
Ask the developer to demonstrate these outcomes on a safe test environment, then confirm an authorized low-value live test if appropriate:
- A successful Paystack charge maps to exactly one WooCommerce order and moves to the appropriate paid state.
- A failed, abandoned or unverified transaction does not mark an order paid.
- A customer closing the browser before returning does not prevent eventual payment confirmation.
- The same signed webhook delivered twice does not duplicate stock reduction, fulfilment, email or access.
- A delayed webhook after a timeout or retry produces the correct final state.
- A blocked or failed webhook is visible in monitoring, with a documented recovery procedure.
- Historic paid-but-pending orders have a verified reconciliation record and no duplicate fulfilment.
- The business retains its WordPress, hosting, domain, Paystack and monitoring account access.
That final ownership test matters. A store is not repaired if the next failure requires finding the same unavailable freelancer again. For a broader store setup reference, see my WooCommerce in Nigeria guide.
The next responsible step
If you have one affected order, start by verifying its reference and checking the webhook history. If you have repeated paid-but-pending orders, stop treating each one as an isolated admin task: the business needs a checkout reliability investigation, reconciliation and regression tests.
I help businesses repair and harden payment-dependent websites and MVPs. If the failure is recurring, describe the issue and the affected workflow, or review my web design and repair services. Share the symptoms and your stack—not secret keys or customer payment data—so we can scope the smallest safe fix.
