PaidRadar › Recovering paid-but-stuck orders
When a payment confirmation never reaches WooCommerce, the order sits on pending while the money is already in your gateway account. There are four realistic ways to deal with that, and they differ a lot in effort, risk and whether they scale. Here they are side by side — including the case where you don't need any tool at all.
Open the gateway dashboard, confirm the charge, mark the order complete by hand. No tool needed, and honestly the right call for a shop with a couple of stuck orders a month. Just verify the transaction ID against the order total before you change anything.
If stuck orders show up every week, the problem is webhook delivery, and manual checking will quietly cost you more than it saves. That's where automated reconciliation earns its place — something that re-queries the gateway on a schedule and repairs what it can prove.
| Manual dashboard check | Resend the webhook | Bulk status edit | Automated reconciliation (what PaidRadar does) |
|
|---|---|---|---|---|
| Verifies against the gateway | Yes — by eye | Yes | No | Yes — via API |
| Scales past ~10 orders | No | Partly | Yes | Yes |
| Fires stock & emails correctly | Depends how you change it | Yes | Often not | Yes — via payment_complete() |
| Risk of completing an unpaid order | Low, if you look properly | None | High | None — refuses on ambiguity |
| Works for events older than the retry window | Yes | No | Yes | Yes |
| Leaves an audit trail | No | In gateway logs | No | Yes — per order |
| Ongoing effort | High | Medium | Low | None after setup |
| Cost | Your time | Free | Free / plugin | Free core |
Comparison is based on how each approach works mechanically, not on popularity or install counts. Gateway retry windows and dashboard features are as publicly documented by the respective providers and can change.
Open Stripe or PayPal, search the customer or amount, confirm the payment succeeded, then set the order to processing or completed in WooCommerce.
Good: free, immediate, and you see exactly what happened. Bad: it does not scale, and changing the status through the order screen does not always fire the same hooks a real payment would — stock and receipt emails can silently stay behind.
Both Stripe and PayPal let you replay a delivery from their dashboard, which makes your site process the event as if it had arrived normally.
Good: the cleanest possible fix — your own gateway plugin does the work, exactly as designed. Bad: only works while the event is still in the retry/history window, and it fails again if the reason it never arrived (firewall, timeout) is still in place.
Select the stuck orders in the admin list and change their status in one go.
Good: fast. Bad: this is the dangerous one. Nothing verifies that those payments actually succeeded, and the bulk action does not run the payment-completion flow. You can end up shipping goods against payments that never cleared — the exact failure this whole category exists to prevent.
A scheduled job re-queries the gateway API for every stuck order and completes only those the gateway confirms as captured.
Good: scales, verifies before acting, uses WooCommerce's own completion path so stock and emails behave, and leaves a record of every decision. Bad: it is another moving part, and it needs read access to your gateway API.
If stuck orders are rare for you, don't install anything — check them by hand and spend the time fixing webhook delivery instead. If the events are still inside the gateway's retry window, resending them is strictly better than any reconciliation tool, because your gateway plugin handles the payment exactly as it was designed to. And if your problem is that payment settings keep changing after plugin updates rather than orders getting stuck, that is a different tool entirely — PayDrift covers that. PaidRadar only earns its place when confirmations go missing often enough that checking by hand stops being realistic.
Yes — and you should. But webhook delivery is structurally lossy: firewalls, timeouts, cache layers returning 204, and live/test key mix-ups will leak some events no matter how well you configure things. Reconciliation is the safety net underneath a properly configured webhook, not a replacement for it.
Because nothing in that action checks whether the money actually arrived. Stuck orders are a mix of genuinely paid, genuinely unpaid and abandoned. Bulk-completing them ships goods against payments that never cleared, and the bulk action usually skips the payment-completion flow, so stock and emails go out of sync too.
Webhook resends are limited to what the gateway still holds in its event history. API-based reconciliation is limited only by the look-back window you configure and by how long the gateway keeps the transaction queryable — in practice much further back.
It should not. PaidRadar's gateway calls are read-only: it reads the payment status and then changes the order inside WooCommerce. Nothing captures, refunds or moves money. Treat write access to a payment API as a red flag for this category of tool.
They should be skipped and logged, not guessed at. A tool that completes an order when the gateway's answer is ambiguous is worse than no tool — you lose the one guarantee that makes automation acceptable here.
Related: why Stripe webhooks never reach WooCommerce · order paid but not completed — pending vs on-hold vs failed · repairing many orders after a webhook outage.
PaidRadar