Tag Archives: Checkout

Is Your WooCommerce Checkout Broken Right Now? How to Monitor It Before Customers Notice

WooCommerce Troubleshooting, , , , ,

Here’s a scenario that plays out on WooCommerce stores every day.

A plugin auto-updates overnight. The home page loads. Product pages load. Your uptime monitor shows a green tick. But the checkout throws a JavaScript error, or the payment step silently fails, or the cart empties itself on the way to checkout.

You find out two days later, when someone finally emails to say they couldn’t pay. Or you don’t find out at all, and just wonder why sales were slow that week.

Uptime is not the same as “customers can buy.” This guide explains what actually needs monitoring on a WooCommerce store, the free and paid ways to do it, and a practical setup for both single stores and agencies.

Why uptime monitoring isn’t enough

A typical uptime monitor requests your home page every few minutes and checks it returns a 200. That catches a crashed server. It misses almost everything that loses money in WooCommerce:

  • A broken cart or checkout page (PHP or JavaScript error on one page only)
  • A payment gateway that’s misconfigured, expired, or rejecting every payment
  • Webhooks being blocked, so paid orders never advance
  • The WooCommerce Store API failing, which block-based cart and checkout rely on
  • Background jobs stalling, so emails and stock updates stop
  • Caching serving a stale or broken checkout page
  • A sudden drop in orders because something upstream broke (ads, DNS for a payment script, a geo-blocking rule)

What to monitor on a WooCommerce store

Think about it in four layers.

Layer 1: Can people reach the buying pages?

Not just the home page, but shop, a product page, cart, and checkout, plus the Store API endpoints the block checkout uses. Each should load quickly and without errors.

Layer 2: Can they get to the payment step?

The real test is adding a product to the cart and reaching checkout. That’s where most plugin conflicts show up. This is called synthetic monitoring: a script behaves like a shopper on a schedule.

A word of caution: synthetic tests should not place real orders. Test orders pollute your reports, trigger fulfilment, and can create real charges. Good synthetic checks stop before payment.

Layer 3: Are orders that come in actually correct?

Orders can be created and still be wrong: stuck on Pending payment, charged twice, cancelled despite payment, missing a confirmation email. That needs integrity checks on the orders themselves. (See stuck pending orders) and double charges.)

Layer 4: Is order volume normal?

Sometimes nothing is technically “broken” by any test, but orders stop anyway. Comparing the current hour’s orders against comparable past hours (same day of week, same time of day) catches drops and spikes that point to a problem. The trick is avoiding false alarms on naturally quiet hours, which is why median-based comparisons work better than simple averages.

Alerts: the part people get wrong

Monitoring is useless if the alert goes to an inbox nobody reads, and equally useless if it fires so often everyone mutes it. Good alerting means:

  • The right channel: Slack or SMS for “checkout is down,” email for “weekly summary.”
  • Severity routing: urgent things wake someone, minor things wait.
  • Confirmation before alerting: one failed check could be a blip. Two in a row is a problem.
  • Throttling: one alert per issue, not one every five minutes.
  • A delivery log: so you can prove an alert was sent.

A free starting setup

You can get decent coverage for free:

  1. An uptime monitor on your home page *and* your checkout URL.
  2. WooCommerce → Status → Scheduled Actions checked weekly for past-due actions.
  3. ‘Tools → Site Health’ checked for loopback and REST API problems.
  4. [Ordafide Order Integrity for WooCommerce] (free) to scan orders for stuck payments, paid-but-cancelled orders, duplicate charges, refund mismatches, total mismatches, and customers who were never emailed. It also shows background queue and email delivery health, and sends an optional weekly summary when there’s something to report.
  5. A manual test purchase after every significant update, using a coupon to make it zero-cost or refunding immediately.

That covers layers 1 and 3 reasonably well. It leaves gaps in layers 2 and 4, and it relies on someone remembering to look.

A complete setup

[Ordafide Pro](https://www.premium-themes.co/ordafide-order-integrity-for-woocommerce/) fills those gaps:

  • Synthetic checkout monitoring every 15 minutes across shop, product, cart, checkout and the Store API, with response-time tracking. An optional deep mode adds a test product to a cart. It never creates orders, and a finding is raised only after two consecutive failures.
  • A signed heartbeat endpoint so an external monitor can confirm the store’s own checks are still running.
  • Order volume anomaly detection that compares the current hour with comparable past hours using median-based statistics, flags drops and spikes, and resolves itself when things return to normal.
  • Alerts via Slack, SMS (Twilio), signed webhooks (for Discord, Microsoft Teams, PagerDuty and similar) and email, with severity routing, per-check throttling, retries and a delivery log.
  • Read-only gateway reconciliation with Stripe, PayPal, Square, Mollie and Razorpay to catch payments with no order (see how to reconcile WooCommerce with Stripe and PayPal).

For agencies: monitoring client stores

If you maintain WooCommerce stores for clients, a broken checkout is an emergency you want to hear about before the client does, not from them.

What matters at agency scale:

  • One dashboard for all stores, not 20 logins.
  • Per-store alert routing, so the right person or client channel gets the right alert.
  • Silence detection, so a store that stops reporting entirely gets flagged rather than quietly looking “fine.”
  • Privacy. Clients’ order data shouldn’t be copied into a third-party service.
  • CLI access for scripted checks across many sites.

Ordafide’s free plugin includes WP-CLI commands (`wp ordafide scan`, `wp ordafide findings`, `wp ordafide health`, `wp ordafide digest`). Ordafide Pro adds a multi-store agency dashboard built on signed hourly snapshots that contain only counts and totals, not customer data. It flags any store that’s been silent for two hours, and the Agency licence adds per-store alert routing.

A monitoring checklist

  • [ ] Uptime checks on home and checkout
  • [ ] Synthetic check that reaches checkout without placing an order
  • [ ] Order integrity scan (stuck, duplicate, refund and total mismatches)
  • [ ] Background queue and email delivery monitored
  • [ ] Order volume compared against normal for the hour
  • [ ] Alerts routed to Slack/SMS for urgent issues, with throttling
  • [ ] Manual test purchase after major updates
  • [ ] For agencies: one dashboard and per-store routing

Frequently asked questions

How do I know if my WooCommerce checkout is broken?
Uptime monitors usually won’t tell you. Use synthetic monitoring that loads the cart and checkout on a schedule, plus order-volume anomaly detection and order integrity checks.

Can I monitor WooCommerce checkout without creating test orders?
Yes. Good synthetic monitoring checks shop, product, cart, checkout and the Store API, and can add an item to a cart, without ever placing an order. Ordafide Pro works this way.

How do I get Slack alerts for WooCommerce problems?
Use a monitoring plugin that supports Slack. Ordafide Pro sends Slack, SMS, email and webhook alerts with severity routing and throttling.

What’s the best way for an agency to monitor many WooCommerce stores?
A central dashboard that receives privacy-safe summaries from each store, flags stores that go silent, and routes alerts per store. WP-CLI commands help with scripted checks.

WooCommerce Customer Charged Twice? How to Find and Prevent Duplicate Orders and Double Charges

WooCommerce Customer Charged Twice? How to Find and Prevent Duplicate Orders and Double Charges

WooCommerce Troubleshooting, , , ,

Few emails damage trust faster than “You charged my card twice.”

Double charges are rarely caused by one dramatic bug. They come from ordinary things: a slow checkout, an impatient click, a firewall that retries a request, a payment plugin that times out and tries again. Each one is rare. Across hundreds of orders a month, they add up, and each one that goes unnoticed becomes a refund request, a chargeback, or a one-star review.

This guide covers what causes duplicate orders in WooCommerce, how to find every one in your store, how to refund them without breaking your records, and how to prevent them.

Two different problems that look the same

It helps to separate two situations:

  1. Duplicate orders: two WooCommerce orders for the same basket. The customer may have been charged once or twice.
  2. Duplicate charges: the customer’s card was charged twice. There may be one order or two.

The worst case is a second charge with no matching order at all. WooCommerce has nothing to show you, so you only find it in your gateway dashboard, or when the customer’s bank statement arrives.

What causes double charges in WooCommerce

Multiple clicks on “Place order”

On a slow checkout, shoppers click again. WooCommerce’s classic checkout blocks the form while it processes, but slow pages, custom themes, page builders and some checkout plugins can weaken that protection. A second click can create a second order and, depending on the gateway, a second payment.

The page was refreshed or the back button was used

A shopper who refreshes on the payment step, or goes back and resubmits, can create a second order with an identical basket.

Request replays by a firewall, proxy or host

Some firewalls, CDNs and reverse proxies resend a POST request when the first one is slow to respond, assuming it failed. If your checkout takes several seconds (often because of third-party API calls for tax, shipping rates or fraud checks), the replayed request can process as a brand-new checkout. Sucuri, in particular, has published guidance on configuring it for WooCommerce for this reason.

Payment plugin retries after a timeout

If the gateway responds slowly, a payment plugin may treat the request as failed and retry. If the first attempt actually succeeded, the customer is charged twice.

Subscription renewal retries

Renewal logic that retries a “failed” payment which actually went through can create two renewal orders and two charges.

One transaction ID attached to two orders

Occasionally a plugin conflict attaches the same gateway transaction to two different orders. You see two “paid” orders but only one payment. This inflates your revenue reports and can lead to shipping two parcels for one payment.

How to find every duplicate charge

Step 1: Look for near-identical orders

In WooCommerce → Orders, sort by date and look for the same customer email, same total and same items within a few minutes of each other. On a small store this is tedious. On a busy store, it isn’t realistic to do by hand every week.

Step 2: Check transaction IDs

Open each suspected pair and compare the gateway transaction IDs. Two orders with the same transaction ID usually means one payment, two orders. Two orders with different transaction IDs means two real payments.

Step 3: Compare against the gateway

Search your Stripe or PayPal dashboard for the customer’s email. Count the successful payments for that basket and compare against the orders in WooCommerce. This is the only way to catch a second charge that never produced an order.

Step 4: Check your logs

‘WooCommerce → Status → Logs’ and your server access logs can show whether two checkout requests arrived close together. That tells you whether it was the shopper, a replay, or a plugin retry, and that decides the fix.

How to refund a double charge without breaking your records

The cleanest fix keeps WooCommerce and your gateway in agreement:

  1. Decide which order to keep. Usually the first one.
  2. Refund the duplicate from inside WooCommerce, using the Refund button on the duplicate order and choosing Refund via gateway. This sends the refund to the gateway and records it in WooCommerce, so stock, revenue and reports stay correct.
  3. Avoid refunding only in the gateway dashboard. A refund made directly in Stripe or PayPal may never be recorded in WooCommerce. The order still looks paid, your revenue is overstated, and stock may be wrong. (See how to reconcile WooCommerce with Stripe and PayPal(/blog/reconcile-woocommerce-orders-stripe-paypal/).)
  4. Make sure the duplicate isn’t shipped. Once fully refunded, the order should move to Refunded. A fully refunded order still sitting in Processing is a classic way to ship an order you didn’t get paid for.
  5. Tell the customer. Let them know it was spotted, refunded, and how long their bank usually takes to show it.

How to prevent duplicate orders

  • Speed up checkout. The slower the checkout, the more people click twice and the more likely a proxy replays the request. Audit plugins that call external APIs during checkout.
  • Don’t break the built-in submit protection. If you’ve customized the checkout or use a page builder, test what happens when you double-click Place order on a slow connection (browser DevTools can throttle the network).
  • Review your firewall and CDN. Make sure nothing retries POST requests to checkout or payment endpoints.
  • Keep your gateway plugin updated. Retry and idempotency handling improves over time.
  • Test with block checkout and classic checkout separately if you’ve switched between them.
  • Monitor continuously. Prevention reduces duplicates. It doesn’t eliminate them.

Catch duplicates automatically

Ordafide Order Integrity for WooCommerce is a free plugin that scans your recent orders and flags problems in plain sentences, sorted by money at risk. Its Duplicate charge check looks for:

  • one gateway payment reference attached to two orders, and
  • the same customer charged twice for an identical basket within minutes.

It also runs a Refund mismatch check that catches orders marked Refunded with no refund record, refunds larger than the order total, and fully refunded orders still marked Processing, so a refunded duplicate doesn’t get shipped anyway.

The duplicate window and other thresholds are configurable, findings you’ve reviewed can be ignored, and the plugin never captures, refunds or voids a payment. Everything runs on your own server.

The one case a store-side scan can’t see is a charge with no order. Ordafide Pro covers it with read-only reconciliation against Stripe, PayPal, Square, Mollie and Razorpay, flagging money with no order, paid orders with no payment, and amount disagreements.

Frequently asked questions

Why did my customer get charged twice on WooCommerce?
Usually a double click on a slow checkout, a page refresh during payment, a firewall or proxy replaying the checkout request, or a payment plugin retrying after a timeout.

How do I refund a duplicate WooCommerce payment?
Refund it from the duplicate order in WooCommerce using Refund via gateway, so the refund is recorded in both systems.

Can a customer be charged twice with only one WooCommerce order?
Yes. If the second charge’s order was never created, WooCommerce shows nothing. Only comparing against the gateway, manually or with a reconciliation tool, will find it.

Does WooCommerce prevent duplicate orders on its own?
It has basic protection against repeat form submission, but it can’t stop request replays, plugin retries or every theme customization. Monitoring is the reliable safety net.