How to troubleshoot WooCommerce checkout errors

When a customer reports a checkout failure, ask: (a) device + browser (iPhone Safari, Android Chrome, desktop Firefox), (b) payment method attempted (card, Apple Pay, PayPal), (c) exact error message visible (screenshot if possible), (d) approximate time + timezone of the attempt, (e) the cart contents.

In WooCommerce → Orders → search by customer email. Sometimes the order WAS created but stuck in "Pending payment." That tells you the failure is post-payment-success — likely webhook or plugin.

In WooCommerce → Status → Logs → filter for "fatal-errors" log file. PHP fatal errors during checkout produce log entries here with stack traces.

In your payment processor: Stripe → Payments → failed payments (or Disputes if it got that far). PayPal → Activity → Transactions filtered by Failed. The processor side often shows the actual decline reason.

Reproduce the failure yourself. Use the same browser, the same product, the same payment method. If you cannot reproduce, the issue may be intermittent — see Step 5.

In Stripe Dashboard → Payments → Failed. Find the failed attempt. The "Decline reason" column shows codes like: card_declined, insufficient_funds, fraud_suspected, do_not_honor, expired_card.

For card_declined / do_not_honor: this is the issuing bank — not Woo, not Stripe. Customer needs to contact their bank or use a different card. Tell them so.

For fraud_suspected: Stripe Radar flagged the order. Review the Radar rule in Stripe → Radar → Rules. Adjust thresholds if you are over-blocking legitimate orders.

For 3D Secure failures (authentication_required, authentication_failed): the customer abandoned the 3DS challenge or their bank rejected it. Common on EU cards. Verify the Stripe plugin is configured to handle 3DS automatically — the modern Stripe Payment Element does this natively.

For PayPal: PayPal Dashboard → Reports → Transaction logs. Failed transactions show reason codes. Common: "BUYER_RESTRICTED" (PayPal buyer account flagged), "INSTRUMENT_DECLINED" (linked bank account declined).

If payment side shows "Succeeded" but Woo shows "Failed" — the issue is in WooCommerce, not the processor. Move to Step 3.

In Stripe Dashboard → Developers → Webhooks → your endpoint. Look at "Recent attempts." Failed webhook deliveries show HTTP error codes (403, 404, 500, timeout).

403 Forbidden: a security plugin (Wordfence, iThemes) is blocking the POST. Whitelist /wc-api/ and Stripe IP ranges (https://stripe.com/docs/ips).

404 Not Found: the webhook URL is pointing at the wrong site (often happens after a domain migration). Re-create the webhook in Stripe to use the correct URL: https://yourdomain.com/wc-api/wc_stripe/

500 Internal Server Error: PHP error during webhook processing. Check WooCommerce → Status → Logs → stripe.log for stack traces.

Timeout: server too slow to respond. Stripe expects under 5s; if your TTFB is high (over 3s), webhook processing may not complete in time. Speed up the site (see Speed Optimization tutorial).

For PayPal: PayPal Developer Dashboard → My Apps & Credentials → your live app → Webhooks → Recent deliveries. Same diagnosis pattern.

After fixing, in Stripe → click "Resend" on a failed webhook event to confirm it now succeeds. Or trigger a new test event from Stripe → Webhooks → Send test webhook.

In a staging environment (Cloudways/Kinsta have one-click staging) — NEVER live — deactivate all plugins EXCEPT WooCommerce and your active payment gateway (Stripe, PayPal Payments).

Test checkout. If it works: a deactivated plugin is the culprit.

Re-activate plugins in groups of 5. Test after each group. The group that breaks checkout contains the offender.

Within that group, bisect: activate half, test. Activate the other half, test. Narrow to the single offender.

Common offenders: (1) security plugins blocking POST requests. (2) cache plugins caching cart/checkout pages (see #1 in Common Mistakes). (3) old payment plugins still active alongside new ones. (4) shipping plugins making slow external API calls that time out checkout.

Replace or remove the offender. If the plugin is essential, contact the plugin author — they may have a known fix.

In your theme folder: /wp-content/themes/your-theme/woocommerce/ — any files here override WooCommerce defaults.

Compare the override files to current Woo defaults at /wp-content/plugins/woocommerce/templates/. If your theme override is on an outdated template version, it breaks features added in newer Woo releases.

Update the override to match the new Woo template (preserving your custom edits). Theme authors should do this in their next theme update — if they have not for 6+ months, the theme is abandoned.

Temporary diagnosis: switch to the Storefront theme (the WooCommerce-by-Automattic free theme). Test checkout. If it works on Storefront, your theme is the problem.

For Blocks Checkout: theme overrides do not apply the same way (Blocks is React-rendered). But page builders (Elementor, Divi) may inject their own checkout layout that breaks. See Step 6.

WordPress Admin → Pages → Checkout. Open the editor.

Blocks Checkout: the page contains a "Checkout" block (with sub-blocks for Contact, Shipping, Payment).

Classic Checkout: the page contains the [woocommerce_checkout] shortcode.

If the page has BOTH (a Block AND a shortcode), it will render twice or break entirely. Pick one.

For new stores: use Blocks Checkout. Faster, better UX, future-proof.

For stores with old plugins that demand Classic: stay on Classic until you can upgrade or replace those plugins.

Critical: if you migrated from Classic to Blocks recently and checkout broke, the most common cause is a legacy plugin that injected JS into the Classic checkout and now does nothing. Audit and remove.

In wp-config.php, find: define( "WP_DEBUG", false ); Change to true. Also add: define( "WP_DEBUG_LOG", true ); define( "WP_DEBUG_DISPLAY", false );

This writes errors to /wp-content/debug.log without showing them on the live site.

Have a friend (or you, with a fresh browser) attempt the failing checkout flow.

Open /wp-content/debug.log. Filter for entries during the checkout time window. Look for PHP errors related to WooCommerce, your payment plugin, or any third-party plugin.

Common findings: "Fatal error: Cannot redeclare function" (plugin conflict), "Allowed memory size exhausted" (PHP memory too low — increase to 512M in wp-config.php), "Uncaught exception: Stripe\Exception" (Stripe API issue, check the message).

CRITICAL: turn WP_DEBUG back to false when done. Live with debug logging on can leak sensitive data and slow the site.