Skip to main content

Engineering Journal

10 Common WooCommerce Problems That Are Easy to Miss

Ten issues that quietly cost stores sales and slow them down — the kind that don't show up until a customer complains, or a sale doesn't happen and nobody knows why.

Every WooCommerce store accumulates small, invisible failures over time — not crashes, just quiet leaks. A coupon that silently stops applying. An email that never sends. A page that’s half a second slower than it used to be. None of these throw an error. They just cost you sales, one unnoticed failure at a time.

Here are ten of the ones we see most often doing engineering audits — the kind that survive for months because nothing actually breaks, it just quietly underperforms.

1. Stacked checkout-field plugins silently dropping custom fields

When two plugins both try to add or modify checkout fields — a shipping-details plugin and a custom-fields plugin, say — one often overwrites the other’s woocommerce_checkout_fields filter instead of merging with it. The field renders fine on the page. It just never reaches the order. Support only finds out when a customer says “I filled that in” and the order shows blank.

What it costs: manual follow-ups on every affected order, and customers who don’t bother reaching out at all.

2. Coupon logic breaking when two plugins hook the same totals filter

Loyalty-points plugins, bundle-discount plugins, and custom pricing logic all tend to hook woocommerce_calculate_totals or woocommerce_cart_calculate_fees. When two do it without checking for each other, one plugin’s discount can get calculated, then silently overwritten by the next one that runs. The coupon field shows “applied” — the total just doesn’t reflect it right.

What it costs: either lost discount (angry customer) or an unintended stacked discount (lost margin) — both invisible until someone audits an order manually.

3. Abandoned-cart emails that quietly stopped firing

Abandoned cart tools depend on WP-Cron, which only runs when the site gets traffic. A caching plugin, a “disable WP-Cron for performance” setting, or a server-level cron misconfiguration can silently stop these emails without any error — the plugin’s dashboard still says “active.” Weeks can pass before anyone checks whether the emails are actually landing.

What it costs: a recovery channel that store owners are budgeting for and not getting, with no alert telling them it stopped.

4. Duplicate orders from payment gateway retries under load

When a payment gateway’s response is slow — a spike in traffic, a flaky connection — some checkout flows let the customer hit “Place Order” twice, or the gateway itself retries a webhook that wasn’t acknowledged fast enough. Without idempotency handling on the order-creation hook, that becomes two orders, two inventory deductions, sometimes two charges.

What it costs: manual refunds, inventory that’s wrong until someone reconciles it by hand, and a support ticket that takes far longer to untangle than it should.

5. Stale cached stock counts after a sale spike

Object caching and page caching both exist to make WooCommerce faster — but if stock-count transients aren’t invalidated correctly on order completion, a page can keep serving “In Stock” for a product that just sold out, or “Out of Stock” for one that’s actually available again after a restock. This is exactly the kind of drift Kodenzo Commerce Health catches on a scan — stale-transient and cache-consistency checks are part of its configuration diagnostics.

What it costs: oversold inventory (refunds, apologies, damaged trust) or lost sales on products that look unavailable when they aren’t.

6. Shipping zones that fail silently for certain postal code formats

Shipping-zone rules matched against postal codes are often written as simple string ranges or regex patterns that don’t account for real-world formatting — a leading zero, a space, a lowercase letter in a Canadian or UK postal code. The zone just doesn’t match, WooCommerce falls back to “no shipping methods available,” and the customer sees an empty checkout with no explanation.

What it costs: checkout abandonment for a real, shippable customer, with nothing in the logs pointing at why.

7. Database bloat from orphaned transients and session rows

WooCommerce and its plugins write session data and transients to wp_options and wp_woocommerce_sessions constantly. Without cleanup, these tables grow for years — we’ve seen wp_options alone pass a million rows on stores that never once ran a cleanup. Every query against a bloated options table gets slower, and it compounds: checkout, cart updates, even the admin dashboard all drag.

What it costs: a slow, gradual site-wide slowdown that nobody notices day-to-day, but that shows up clearly in page-speed reports and, eventually, in conversion rate.

8. Guest checkout quietly disabled by a security plugin’s defaults

Security and anti-fraud plugins often ship with “require account for checkout” toggled on by default, or add friction (mandatory phone verification, CAPTCHA on every field) as part of a “protection” preset — sometimes without the store owner realizing it happened during a routine plugin update. The checkout still works. It’s just one extra required step the owner never asked for and never tested against.

What it costs: cart abandonment from customers who don’t want to create an account, silently, for however long it takes someone to test checkout end-to-end again.

9. Webhook failures to CRM/ERP integrations with no retry or alerting

Custom integrations that push new orders to a CRM, ERP, or fulfillment system often fire a webhook once, on the woocommerce_new_order hook, with no retry logic and no failure alerting. If the receiving endpoint is down for five minutes — a deploy, a timeout, anything — those orders just never sync, and nothing tells anyone it happened.

What it costs: orders that exist in WooCommerce but not in the system fulfillment actually runs from — usually discovered by a customer asking where their order is.

10. Mixed-content warnings on checkout from one hardcoded asset URL

A single hardcoded http:// URL — in a theme option, a plugin setting, an old customization — is enough to trigger a mixed-content warning specifically on the checkout page, even on a fully HTTPS site. Most browsers show this as a broken or “not secure” padlock right where trust matters most.

What it costs: customers who bail at the exact moment they’re about to pay, because the page suddenly looks untrustworthy.


Want to check your store?

Most of these don’t show up until someone goes looking for them — which is the whole reason we built a tool that goes looking automatically.

Try Kodenzo Commerce Health — free on WordPress.org.

Keep Learning. Keep Building.

More engineering articles, guides and product updates live in the Knowledge Hub.

Try Commerce Health Free