Skip to content
Rescue 404
Rescue

WooCommerce Errors

WooCommerce Payment Gateway Not Working

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WooCommerce payment gateways usually fail because the gateway is stuck in test mode, its API keys or webhook URL are wrong for the current domain, a plugin/SSL conflict is blocking the payment script, or the gateway service itself is rejecting the connection. Read the gateway logs first, confirm test vs. live mode and webhook delivery, then conflict-test before touching live API keys.

A broken payment gateway looks like checkout is dead even when cart, products, and shipping all work fine — customers see “payment method unavailable,” a spinning button, or a decline that never explains why. This guide separates gateway configuration problems (mode, keys, webhooks) from front-end and server problems (scripts, SSL, caching) so you fix the layer that is actually broken. Work from logs outward; do not start swapping API keys on a live store without knowing which side failed.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WooCommerce payment gateways are plugin classes that extend WC_Payment_Gateway and register through the woocommerce_payment_gateways filter. (WooCommerce Payment Gateway API)
  • Direct card gateways that collect payment on checkout require SSL and may require PCI-related server controls; form and iframe gateways post payment data offsite. (WooCommerce Payment Gateway API)
  • WooCommerce automatically disables a webhook after more than five consecutive delivery failures (non-2xx/301/302 responses). (WooCommerce webhooks)

What the error means

“Payment gateway not working” covers everything between WooCommerce handing an order total to the gateway plugin and that gateway confirming or declining the charge. WooCommerce ships a Payment Gateway API that lets each gateway plugin register its own settings, render its own fields at checkout, and process the order via its own `process_payment()` method — Stripe, PayPal, WooPayments, and card processors are all separate plugins bolted onto that same interface. When something breaks, it can be WooCommerce not loading the gateway at all, the gateway loading but failing its API handshake, or the gateway processing the charge while the webhook that confirms it back to WordPress never arrives. Each of those looks similar to a shopper but requires a different fix.

Common symptoms

  • Selected payment method is grayed out, missing, or shows “payment method unavailable” at checkout
  • Place order submits but returns a generic decline with no reason from the gateway
  • Gateway dashboard (Stripe, PayPal, WooPayments) shows a successful charge but the WooCommerce order stays Pending or Failed
  • Checkout works in the gateway’s test/sandbox mode but fails as soon as live mode is enabled (or the reverse)
  • Payment fields (card number, redirect button) never render or throw a JavaScript error in the console
  • Webhook or IPN deliveries show as failed or disabled in the gateway’s settings screen
  • Only one payment method fails while others (or manual methods like bank transfer) work normally

Most likely causes

  1. 01 Gateway left in test/sandbox mode, or live and test API keys swapped after a migration
  2. 02 Webhook or callback URL still points at a staging domain, old URL structure, or has been disabled after repeated failed deliveries
  3. 03 SSL certificate problem or mixed content blocking the gateway’s hosted card fields or redirect
  4. 04 Security plugin, firewall, or Cloudflare rule blocking the gateway’s webhook IP range or REST endpoint
  5. 05 Plugin or theme JavaScript conflict preventing the gateway’s checkout script from loading or initializing
  6. 06 Gateway plugin outdated relative to WooCommerce core after an update, breaking the registered payment method
  7. 07 Currency, country, or minimum-order restriction on the gateway account rejecting otherwise valid orders

What changed before the problem started

  • Payment gateway plugin (Stripe, PayPal, WooPayments, or similar) was updated or reconnected
  • WooCommerce or WordPress core update changed how registered gateways or REST routes load
  • Domain, SSL certificate, or www vs. non-www configuration changed since webhooks were last verified
  • Security plugin, host firewall, or Cloudflare WAF rules were tightened
  • Site was migrated or cloned from staging, carrying over stale API keys or webhook URLs

Troubleshooting steps

  1. 01

    Confirm exactly which payment method fails and for whom

    Note whether the method is missing entirely, present but erroring, or accepting test cards while declining live ones. Reproduce once as a guest in a private browser window. If other methods (or manual payments) still work, the fault is isolated to that one gateway, not checkout as a whole.

  2. 02

    Check test mode vs. live mode in the gateway settings

    Open WooCommerce → Settings → Payments → the affected gateway and confirm whether test/sandbox mode is on. A gateway left in test mode after launch (or switched to live without updating keys) is one of the most common “payment not working” causes and needs no code changes to fix.

  3. 03

    Read WooCommerce → Status → Logs for the gateway

    Filter logs by the gateway name (stripe, paypal, woocommerce-payments) around the failure time. Gateway logs usually name the exact rejection reason — bad API key, currency not supported, webhook signature mismatch — far faster than guessing from the checkout screen.

  4. 04

    Verify the webhook or callback URL and its delivery status

    In the gateway’s own dashboard (Stripe, PayPal, etc.) and in WooCommerce → Settings → Advanced → Webhooks, confirm the endpoint points at your current live https domain and shows recent successful deliveries. Most gateways auto-disable a webhook after repeated delivery failures, which silently stops orders from confirming even though the charge succeeded.

  5. 05

    Inspect the browser console and Network tab during checkout

    Open DevTools, reload checkout, and click Place order. Look for blocked scripts, mixed-content warnings, or failed requests to the gateway’s hosted fields or REST endpoint. This distinguishes a front-end script conflict from a server-side gateway rejection before you touch any settings.

  6. 06

    Conflict-test with a default theme and minimal plugins

    Prefer staging. On production, only in a low-traffic window with a full backup taken first. Switch to a default theme and leave only WooCommerce plus the payment gateway plugin active; re-enable other plugins in small batches until the failure returns.

When to stop troubleshooting

Stop making live changes if customers are being charged without matching orders, you cannot tell whether a fix worked without processing more live charges, the gateway account itself shows a compliance or verification hold, or diagnosis requires live API credentials you do not fully control. A payment gateway outage during active sales is a strong case for professional rescue rather than repeated live experimentation.

Information to collect before requesting help

  • 01 Exact payment method affected and whether it is missing, erroring, or declining
  • 02 Screenshot of the checkout failure plus the browser console output
  • 03 Gateway plugin name and version, and WooCommerce core version
  • 04 Whether test mode succeeds while live mode fails (or the opposite)
  • 05 WooCommerce Status log excerpts and the gateway’s own dashboard error messages
  • 06 Webhook/callback URL and its recent delivery status in the gateway dashboard
  • 07 Any charges visible in the gateway with no matching WooCommerce order
  • 08 Recent domain, SSL, plugin, or security rule changes

How a professional repairs the problem

A pro isolates whether the failure is gateway configuration (mode, keys, webhooks), a front-end script conflict, or a firewall/REST access block; verifies and rebuilds webhook delivery against the live domain; rotates credentials safely through the gateway’s own dashboard; reconciles any orphaned charges against WooCommerce orders; and confirms a clean end-to-end test transaction before returning the store to full live traffic with monitoring on the payment path.

Frequently asked questions

Why does the gateway work in test mode but fail in live mode? +
Test and live modes usually use entirely separate API keys, webhook endpoints, and sometimes separate merchant verification. A gateway that only fails live is almost always a live-key, live-webhook, or account-verification issue rather than a code problem.
A customer was charged but no order appeared — what now? +
Do not ask them to retry. Find the charge in the gateway dashboard, match it against webhook delivery logs, and create or correct the WooCommerce order manually. Fix the webhook or firewall issue before taking more live payments.
Will disabling the gateway plugin lose my order history? +
No. Deactivating a payment gateway plugin does not delete existing WooCommerce orders or their data — it only stops that gateway from being offered until reactivated.
Can a security plugin really block payments? +
Yes. Firewalls and security plugins sometimes block the gateway’s webhook IP addresses or the WordPress REST API routes some gateways rely on to confirm payment, which silently prevents orders from completing even though the charge succeeded.
Should I switch payment gateways entirely to fix this? +
Only after confirming the current gateway is genuinely broken rather than misconfigured. Switching gateways mid-diagnosis often reintroduces the same root cause (webhook, SSL, or firewall issue) under a different provider.
Is a declined test card the same problem as a live decline? +
Not usually. Test card declines are expected behavior for specific test numbers designed to simulate failure. A live decline with no reason shown points at account status, currency support, or a webhook/API configuration issue instead.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.