Patching the WooCommerce PayPal Payments Plugin

A client came to me this week with their WooCommerce store throwing fatal errors on the checkout page – that’s no good. After digging through the site’s PHP error logs, the culprit was the official WooCommerce PayPal Payments plugin – specifically a fatal error in SubscriptionHelper.php. This plugin raises issues on my network frequently, and lots of clients hold-back this plugin from auto-updates to prevent issues.

The crash

The error looked like this:

PHP Fatal error: Call to a member function get_type() on false

The plugin calls wc_get_product() to look up a product from a cart item. But that function returns false if the product doesn’t exist or has been deleted. The plugin’s only guard against this is an assert() call — which is compiled out entirely in production PHP (zend.assertions = -1). So when a cart contained a non-standard item (in this case, a raffle entry), the plugin called get_type() on false and the page-load failed.

The fix is straightforward: real runtime checks. An isset() on product_id, followed by an instanceof WC_Product check with a continue to skip the item if it doesn’t resolve. The vendor’s assert() approach is the kind of thing that passes code review and then silently does nothing in production.

Checking for other oddities…

This plugin pops up frequently with issues, so I figured I’d rinse it through Claude Code to see if there were any unauthorised data leaks or telemetry in there. We definitely found something worth flagging: a module called ppcp-store-sync, internally branded “Agentic Commerce”.

When active, this module:

• Registers your store with d.joinhoney.com (PayPal’s Honey infrastructure), sending your store name, URL, merchant ID, currency, country, and the store’s REST API base URL (the cart/checkout endpoints PayPal’s agents call into).
• Runs a recurring background job that continuously uploads your product catalogue to PayPal/Honey
• Opens public REST endpoints (create_cart, get_cart, replace_cart, checkout) for AI shopping agents

The module is on by default. It’s currently gated to US merchants, but the source code contains a comment:

// todo: shipping country must be US

UK stores are dormant today, but they’re armed. The next time PayPal updates the plugin and widens that gate, the sync starts without any admin action. This means your WooCommerce shop data are exported to US-based servers without your consent.

New data-sharing features being on by default for existing installs, rather than opt-in, is exactly the kind of thing that needs to be called out – it’s way too common, but is bad practice.

The fix disables the module at the vendor’s own gate, so it takes its existing early-exit and deregister path. Payment processing, subscriptions, and all core gateway functionality are left untouched.

The patch

I’ve published the patch to a new GitHub repository, and I’ll keep this up-to-date as new versions of the upstream plugin are released.

woocommerce-paypal-payments-fixes

Patches are listed per plugin version. At the time of writing, the current patch targets v4.0.4 and v4.1.0. To apply the patch manually from the terminal:

# Change into the plugins directory
cd /web/wp-content/plugins/

# Apply the patch (change the path to the correct file)
patch -p1 \
  --directory=woocommerce-paypal-payments \
  < /path/to/woocommerce-paypal-payments-4.0.4.patch

If you’re using WPatcher, the patch carries the standard marker block and can be deployed and reverted across a fleet in the usual way.

After applying, you should see a PATCHED badge on the plugin’s entry in wp-admin/plugins.php. To verify the privacy patch is working, check that no ppcp_agentic_sync_batch action is scheduled and that your server logs show no outbound requests to d.joinhoney.com.

Two patches, the same idea

This is the second WooCommerce-related patch I now maintain. The first is woocommerce-debloat, which removes telemetry and unnecessary features from WooCommerce core. Both exist for the same reason: large, fast-moving plugins that ship things you didn’t ask for, enabled by default, to existing installs.

The patches are conservative and commented. If something here disables a feature you actually want, don’t apply that hunk. 😎