WooCommerce fixes / PayPal IPN not working

PayPal IPN Not Working in WooCommerce? Causes & Fix

You've already worked out that PayPal's IPN is the problem — now you need to know why delivery is failing and how to make it stick. This page is about the notification wire itself: reading the IPN history, understanding what PayPal needs back from your store, and fixing each way it breaks.

Last updated: 16 Jul 2026 · ~8 min read

Quick answer

The usual cause is that IPN is switched off in your PayPal account, or a firewall or security plugin is blocking the notify URL so the message never arrives. Open Account Settings → Notifications → Instant payment notifications in PayPal and look at the IPN history. Disabled, or messages stuck on retry, tells you which of the two you have.

How IPN actually works — and the one thing PayPal needs back

IPN is a one-way POST from PayPal to a URL on your store, sent after a payment event. Your store is expected to answer with a plain HTTP 200 and post the message back to PayPal for verification. If PayPal doesn't get that 200 it treats the message as undelivered and retries on a decaying schedule for several days before giving up. So "IPN not working" nearly always means one of three things: PayPal isn't sending, PayPal is sending but can't reach you, or it reaches you and your store answers with something that isn't a clean 200.

One thing to settle before you debug anything: IPN is the legacy mechanism. It belongs to the old PayPal Standard gateway. The current WooCommerce PayPal Payments plugin uses REST webhooks instead, and on that plugin an empty IPN history is completely normal — you'd be debugging a wire your store doesn't use. Check which PayPal gateway you're actually running before you spend an hour in the IPN history. If your real symptom is a specific order that took the money but failed, that page is the faster route to recovering it.

The most common causes (most likely first)

  1. IPN is disabled in your PayPal account, or the notify URL is blocked in transitTwo shapes, same outcome. Disabled: PayPal's IPN settings screen shows the feature off, and the history has no entries at all for recent payments. Blocked: the history does have entries, but they sit on Retrying or Failed and never reach Sent — a WAF, Cloudflare rule or security plugin is refusing PayPal's POST before WooCommerce ever sees it.
  2. Your store doesn't use IPN at all — it's on webhooksThe gateway in WooCommerce → Settings → Payments is PayPal Payments, not the legacy PayPal Standard, and the IPN history is empty even though payments are completing normally. Nothing is broken here. Debug the plugin's webhook status instead — the IPN history will never fill in.
  3. Your store answers with something other than a clean 200The history shows delivery attempts marked failed even though the URL is publicly reachable in your own browser. The usual culprits: a redirect (http to https, or www to non-www) returning a 301 rather than a 200, a maintenance-mode or coming-soon plugin, a login wall, or a caching layer answering for the endpoint. PayPal follows none of that — it wants a 200 and an empty body.
  4. The notify URL points at the wrong hostThe URL shown against the failing messages in the IPN history isn't your current live checkout domain — it's the old domain, a staging host, or an http:// version of your site. Classic after a migration, an SSL move, or a site URL change, because the URL was baked in at the time the payment was made.
  5. IPN arrives and returns 200, but WooCommerce discards itThe most confusing shape: PayPal's history says the message was delivered fine, yet the order never moves and gains no order note about the payment. WooCommerce received it and rejected it as not-for-this-store — a receiver email that doesn't match the funded account, or a sandbox message hitting a live gateway. Turn on the gateway's debug logging and read WooCommerce → Status → Logs to see the rejection.

Where to look first

Want to know the next time IPN goes quiet?

The cruel thing about IPN is the delay. PayPal retries for days, so a broken wire looks fine for a while and then you find a week of paid orders sitting unfulfilled. Nobody checks the IPN history on a normal Tuesday. DiagnosticIQ's free dashboard watches the money path continuously and raises a flag when orders are being paid but not transitioning — the pattern a dead IPN makes before you'd ever think to look. The AI names it concretely, down to "PayPal IPN retrying — notify URL returning a redirect", rather than leaving you to read retry logs.

Get the free plugin

Made by Prima Digital — the team behind this guide. Free forever; no card to install.

How to know you fixed it

Verify

Resend a failed message from PayPal's IPN history — it should land as Sent, and a fresh test payment should show a delivered IPN plus an order note recording the payment, with the order moving to Processing on its own.

Frequently asked

Does PayPal give up on failed IPNs?

Eventually, yes. It retries on a decaying schedule over several days, then stops. Fix the wire and resend from the IPN history before those attempts run out.

My IPN history is completely empty. Is that bad?

Not necessarily. If you're on the current PayPal Payments plugin it uses webhooks, not IPN, and an empty history is expected. Check your gateway before you panic.

Do I need IPN if I have PDT enabled?

Yes. PDT only fires when the customer actually returns to your site after paying. IPN is what covers the ones who close the tab, which is most of the problem.

Will resending an IPN charge the customer again?

No. An IPN is only a notification message. Resending it updates the WooCommerce order and never touches the payment.

>_
John O'Keane — Founder, Prima Digital · LinkedIn
Contributions by David Zhang · LinkedIn
I build DiagnosticIQ, the WooCommerce diagnostic plugin, and I've spent more evenings than I care to admit in PayPal's IPN history working out why a notify URL wouldn't answer with a plain 200.