PayPal IPN Not Received: Fix WooCommerce Orders Stuck Unpaid

Customer says the money left their PayPal account. Your WooCommerce order still says "Pending payment" or "Failed," and no confirmation email ever went out. Nine times out of ten, this is a broken PayPal IPN (Instant Payment Notification) call, not a problem with the payment itself.

What's Actually Happening

PayPal received the payment fine. What didn't happen is the follow-up call PayPal makes back to your server to say "hey, this order is paid, go ahead and update it." That callback is the IPN (or, if you're on the newer PayPal Payments plugin, a webhook). If your server never receives it, or rejects it, WooCommerce has no idea the payment succeeded. The order just sits there.

You can usually confirm this in under a minute: log into PayPal, open the transaction, and check its IPN history. If it shows a failed or pending delivery attempt, you've found your problem — it's not WooCommerce's fault, it's a delivery issue.

Where to Look First

1. Check the IPN delivery status in PayPal

In your PayPal business account, go to Activity → find the transaction → View details. Scroll to "IPN history" (older UI: Account Settings → IPN History). You'll see one of three states:

• Sent — PayPal delivered it and got a 200 OK back. If the order still shows unpaid, the bug is on your site (WooCommerce didn't process what it received).
• Failed — PayPal tried to reach your IPN URL and got blocked, timed out, or received a non-200 response.
• No IPN sent at all — usually means the IPN URL configured in your PayPal account settings is wrong or missing.

2. Check WooCommerce's own logs

Go to WooCommerce → Status → Logs and look for a file starting with paypal- or paypal-standard-ipn-. If nothing's logged at all for the time of the transaction, the request never reached WordPress — that points to a firewall, ModSecurity, or DNS problem, not a plugin bug.

The Real Causes, Ranked by How Often We See Them

Cause 1 — A security plugin or WAF is blocking PayPal's servers

Wordfence, Sucuri, and cPanel's own ModSecurity rules routinely flag PayPal's IPN POST request as suspicious, because it arrives with no session cookie, no user-agent your rules expect, and a raw POST body. Check your ModSecurity audit log via WHM or in cPanel under Security → ModSecurity Log Editor, and search for hits against /wc-api/wc_gateway_paypal or /?wc-api=WC_Gateway_Paypal around the transaction time. If you see a rule ID (commonly 981173 or 973338 for "no user agent" or generic XSS rules), you'll need to disable that specific rule for that one path rather than turning off ModSecurity site-wide.

Cause 2 — Wrong or missing IPN URL in PayPal settings

Legacy PayPal Standard needs the IPN URL registered in your PayPal account under Account Settings → Notifications → Instant Payment Notifications. If that field is blank, PayPal falls back to whatever URL WooCommerce sent at checkout time — which breaks the moment your domain, or your SSL setup, changes. Set it explicitly to:

https://yourdomain.com/?wc-api=WC_Gateway_Paypal

and make sure it's HTTPS, not HTTP — PayPal will not follow an http-to-https redirect on an IPN call, it just logs the attempt as failed.

Cause 3 — SSL chain issue or mixed redirect

If your certificate is self-signed, expired, or your host has a partial redirect loop (say, www to non-www to https, three hops deep), PayPal's IPN listener gives up faster than a browser does. Test it directly:

curl -Ik https://yourdomain.com/?wc-api=WC_Gateway_Paypal

You want a single HTTP/2 200 or HTTP/1.1 200 OK, not a chain of 301s and not a certificate warning.

Cause 4 — A caching layer is serving a cached response to the callback

LiteSpeed Cache, WP Rocket, or a page-level Cloudflare cache rule can occasionally cache the ?wc-api= endpoint if "cache everything" is turned on without proper bypass rules. The fix is to exclude query strings starting with wc-api from full-page caching. In LiteSpeed Cache, add it under Cache → Excludes → Do Not Cache URIs. In Cloudflare, add a Page Rule or Cache Rule that bypasses cache for yourdomain.com/*wc-api*.

Cause 5 — You're still on PayPal Standard, which PayPal is deprecating

If you set this gateway up years ago, you may be on the old "PayPal Standard" IPN integration, which PayPal has been quietly sunsetting in favor of REST-based webhooks through the official PayPal Payments plugin. New PayPal merchant accounts sometimes have IPN disabled by default at the account level, and no setting on your WordPress side can fix that — you have to switch gateways.

How to Fix It, Step by Step

1. Confirm the transaction shows as "Failed" or "not sent" in PayPal's IPN history (see above). If it shows "Sent" with a 200 response, the issue is on the WooCommerce side — check for a PHP fatal error in wp-content/debug.log instead.
2. Run the curl -Ik test above to rule out SSL and redirect problems.
3. Check the ModSecurity/WAF log for blocked requests to wc-api=WC_Gateway_Paypal around the failure time, and whitelist that specific path.
4. Exclude the wc-api query string from any page cache or CDN cache.
5. Use PayPal's IPN simulator to send a test IPN to your live URL and confirm you get a clean 200 back.
6. For the specific stuck order, go to WooCommerce → Orders, open it, and if payment is confirmed on PayPal's side, manually change the status to "Processing" or "Completed" and add an order note — don't leave the customer's order in limbo while you fix the pipeline.
7. If you're still on legacy PayPal Standard, migrate to the official WooPayments or PayPal Payments plugin, which uses signed webhooks instead of unauthenticated IPN POSTs — more reliable and not on PayPal's deprecation list.

Prevention

• Set a calendar reminder to check WooCommerce → Status → Logs → paypal once a month for silent failures — most store owners only find out when a customer complains.
• Never let a WAF rule blanket-block requests with no user-agent; scope the exception to the exact IPN path instead of disabling protection site-wide.
• If you accept PayPal at meaningful volume, move off PayPal Standard to the current PayPal Payments plugin before PayPal forces the migration on you with no warning.
• Add a lightweight uptime check that hits your ?wc-api=WC_Gateway_Paypal endpoint and alerts if it stops returning 200.

Getwebup hosting doesn't add extra ModSecurity rules on top of what CloudLinux ships by default, but if you're not sure whether a rule on your account is the one blocking PayPal, open a ticket with the transaction ID and time — we can pull the exact rule ID from the audit log in minutes.