WooCommerce "There Was an Error Processing Your Order"? Causes & Fix
If checkout shows There was an error processing your order but the order is sitting in your admin anyway — often paid — this is not a declined payment. Something crashed after the order was created. Here's how to find it before it costs you another duplicate charge.
Last updated: 16 Jul 2026 · ~7 min read
The usual cause is a non-payment fatal error that fires after the order is already created — most often the transactional email send, via an invalid "From" address or a broken SMTP plugin. The order and the payment go through; the checkout response doesn't, so WooCommerce falls back to this generic message. Check your error log for a fatal stamped at the checkout time, then fix the mailer.
What this error actually means
This message is WooCommerce's fallback. The checkout form posts over AJAX and expects a small JSON response saying "success, redirect here". If anything else comes back — a PHP fatal, a stray warning printed before the JSON, a 500, a 403 — the script can't read the response and shows this generic line instead. It never means "the payment was declined"; a real decline gives you the gateway's own wording.
That's why the two views disagree so badly. The customer sees a failure and assumes nothing happened. You see an order in the admin, frequently already paid. Note that the error text itself tells the customer to check for charges before ordering again — most don't. They press Place order a second time, and you get duplicate orders and a double payment to refund.
The most common causes (most likely first)
- The order email send throws a fatal after the order is createdThe order exists and payment cleared, but no order emails went out. Your PHP error log has a fatal stamped at the exact checkout time, inside a mailer or SMTP plugin file. Usually an invalid
Fromaddress underWooCommerce → Settings → Emails, or an SMTP plugin that can't authenticate. - Another plugin fatals on a post-order-creation hookSame shape as cause 1 — order created, response broken — but the fatal names a CRM, ERP, accounting, points, or invoicing plugin rather than a mailer. These hang off
woocommerce_checkout_order_processedand run inside the checkout request. - A PHP notice or warning is printed into the JSON responseNo fatal, and the order is fine — but in the browser's Network tab the checkout request returns HTML or warning text before the opening
{. The JSON is technically valid, just no longer parseable because of what's in front of it. Turning off display of errors on the live site makes it disappear. - The checkout request 500s, times out, or hits the memory limitThe server log shows a 500 or
Allowed memory size exhausted, not an application fatal. Often intermittent, and often worse on large carts. The order may or may not have been written before the crash. - A firewall or security plugin blocks the checkout requestThe Network tab shows 403 rather than 200 on the checkout POST, and no order appears in the admin. A WAF or ModSecurity rule is matching the posted address or notes field. Different from causes 1–4: here nothing was created at all.
- The payment genuinely failedRule this out first, but it's rarely this. A real decline shows the gateway's own message, the gateway dashboard shows a declined or errored attempt, and the order is Failed rather than paid.
Where to look first
- Find the order in your admin first. Does it exist? If yes, this was never a payment failure — go to step 2. If there's no order at all, jump to the firewall and gateway checks.
- Check the gateway dashboard for a charge on that order. Order exists and the money landed? Then the crash happened after payment — causes 1 to 4. Mark it paid manually rather than asking the customer to try again.
- Open your PHP error log and look at the checkout timestamp. A fatal there names the guilty file outright. If it points at a mailer or SMTP plugin, that's cause 1.
- Did the order emails go out? No email for an order that otherwise completed is the strongest single signal for cause 1. Send a test from your SMTP plugin and check the
Fromaddress is a real mailbox on your own domain. - Watch the checkout POST in the browser's Network tab. 403 means a firewall (cause 5). 500 means a crash (cause 4). A 200 with text before the JSON means stray output (cause 3).
Worried this has already caused duplicate charges?
The expensive part isn't the fix — it's the orders that quietly doubled while you were reading the error log, and the refunds you'll issue for them. DiagnosticIQ's free dashboard is built for exactly this gap: it watches the money path, flags orders that were paid but never emailed, and surfaces near-identical repeat orders from the same customer minutes apart — the fingerprint of a customer who saw this error and paid twice. The AI names the crash — down to "order email fatal: invalid From address" — instead of leaving you with the generic wording.
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
Place a test order — it should land on the Order received page with no error, the order emails should arrive, and your PHP error log should stay silent at that timestamp.
Frequently asked
Was the customer charged?
Very often yes. Check the gateway dashboard before doing anything else — with this error the payment usually cleared and only the response broke.
Should I refund the customer?
Not for the first order. Fix the crash and mark that order paid. Only refund the second, duplicate order if they paid twice.
Will they be charged twice?
That is the real risk. The error tells them to try again, so many re-pay. Look for two near-identical orders minutes apart from the same email.
Why doesn't the message say what went wrong?
Because WooCommerce couldn't read the response at all. It has no error to report, so it shows a fixed fallback line. The real error is in your PHP log.