Short answer: the payment was authorised at the gateway, but the message telling WooCommerce about it never arrived or was rejected. The order sits in “pending payment” while the money has genuinely moved.
Why it is worse than a visible error
Nothing looks broken — the store is online and checkout works for new visitors, only the order status is wrong. Meanwhile customers have been charged and are waiting, which turns a technical fault into a trust problem fast.
Where the callback fails
- The webhook/IPN endpoint is unreachable, redirected, or returning an error.
- A security plugin or firewall blocks the gateway’s server-to-server requests.
- The callback URL still points at a staging or old domain after a migration — a classic cause.
- A caching layer intercepts the endpoint and returns a cached response.
- The gateway’s signing secret changed and validation now fails.
Check the gateway dashboard’s webhook/IPN delivery log — it usually shows the failed deliveries and the HTTP status your site returned.
Reconcile carefully
- Export the affected orders with timestamps and totals.
- Match them against the gateway’s transaction list to establish which were genuinely paid.
- Update only the confirmed orders, adding an order note recording why.
- Check stock, since manual status changes may not have adjusted inventory.
Never bulk-complete pending orders without matching them to real transactions — you will either ship unpaid orders or hide genuine payment failures.
Fix the cause and verify
Reconciling existing orders is remediation; the repair is restoring the callback path. Place one controlled order and confirm the status changes automatically, the email sends and stock decreases, then re-check the gateway log for queued failed deliveries.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Pending payment can mean no payment happened, a callback never arrived or the callback was rejected. Reconciliation must precede any bulk status change.
- 1
Export affected order IDs, times, totals, currencies and gateway references.
- 2
Match them to the gateway transaction and webhook delivery logs.
- 3
Inspect callback URL, signing secret, firewall and cache behaviour.
- 4
Update only confirmed paid orders with an audit note and explicit stock review.
What must be verified
- Every historical order has a documented payment decision.
- A new controlled order changes status automatically.
- Webhook delivery returns a successful status and stock/email effects occur once.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If the store looks fine and checkout works for new customers, can the payment system still be broken?+
Yes. This particular issue leaves the store looking entirely normal, since payments were genuinely authorized at the gateway, but the message telling WooCommerce about it never arrived or was rejected, so only the affected orders' status is wrong while everything else functions.
Is it safe to bulk-mark all pending orders as complete to clear the backlog?+
No, never do this without matching each order to a real transaction first. Bulk-completing pending orders risks either shipping products that were never actually paid for, or masking genuine payment failures that need separate handling.
What's a common reason the payment callback stops working right after a site migration?+
The webhook or IPN callback URL registered with the gateway can still point at the staging site or the old domain after migration. Since the gateway sends its confirmation to whatever URL it has on file, this silently breaks the connection until the endpoint is updated.
After reconciling the stuck orders, is the problem actually fixed?+
Reconciling existing orders is remediation, not the repair. Confirm the callback path itself is restored by placing one controlled order and verifying the status updates automatically, the email sends, and stock decreases, then check the gateway's log for any other queued failed deliveries.