Case study · Online store
The checkout stopped taking orders after an update. Two days later it was fixed and tested.
Customers could fill a basket but not pay. We found the cause on a copy of the shop, fixed it and proved it with test orders.
- Who
- A small online shop with a team of three. It sells through its own website.
- The problem
- After a routine update, customers could fill a basket but not pay. Orders stopped.
- What we did
- Found the cause on a copy of the shop, fixed it and proved the fix with test orders.
- The result
- Checkout worked again. The owner applied the fix to the live shop using our written steps.
- Time
- Two days, from first message to sign-off.
What was going on.
The shop sells through its own website. One morning the owner noticed that the usual order emails had stopped. Customers could still browse and fill a basket, but at the last step the page spun and nothing happened. Some had tried three times.
An update had gone through a few days earlier, along with new versions of several plug-ins. Nobody was sure which one mattered. The owner is not a developer, and the person who had built the shop's theme had moved on.
Every hour the checkout stayed broken cost sales. Trying fixes on the live shop could have made things worse.
What we found.
We never touched the live shop. We worked on a copy of it, with the payment provider in test mode and customer emails switched off, so nothing real could be charged or sent. Once the copy showed the same fault, we switched plug-ins and parts of the theme off one at a time until an order went through.
The cause was a clash between two things that were each fine alone. A plug-in that adds delivery options had changed how it hands the basket total to the payment step. The shop's theme still used an older copy of the checkout page that did not expect that. The update fixed the plug-in and quietly broke the older page.
The technical detail
An out-of-date copy of a checkout template in the theme did not match the updated plug-in. The part of the page that refreshes the totals after a delivery option is chosen returned an error, so the order button never submitted the order. The smallest fix was to bring that one template in line with the plug-in's current version.
What we did.
How we checked it.
These had to pass before we asked for sign-off.
- A test order from a guest customer paying with a test card went through and created exactly one order, with the right total and status.
- A declined test card left no paid order behind.
- Shipping, tax and the order confirmation email were right on the test order.
- No new errors appeared in the shop's error log during the tests.
What they have now.
The shop received the fix, written steps to apply it, written steps to undo it, and a short note naming the cause with before-and-after screenshots. The owner applied it to the live shop, and orders came through again the same day.
We also told the owner what would have caught this sooner: update plug-ins on a copy of the shop first, and treat a gap in the order confirmation emails as an alarm.
What we did not do.
- We took no live payment and made no refund. Every test used the payment provider's test mode.
- We did not look into orders lost while the checkout was broken or contact customers. That was the shop's decision.
- We tested the checkout path that was failing, plus shipping, tax and the confirmation email. Other payment methods were outside this job.
- We did not change anything in the shop's payment provider account.
The service behind this.
If an update has stopped customers paying and you cannot tell which change did it, the cause is usually findable on a copy, without risking the live shop.
One-off job
WooCommerce checkout after an update
Find and fix the one fault that stops customers completing an order after an update, proved with a test order on a copy of your store.
Priced in a written proposal. After the test order passes on the copy of your store and you sign off.
More case studies.
One-off job
Genuine payment messages were being rejected
Paid customers still showed as unpaid. The company's code was checking the wrong thing. We fixed it without switching the check off.
Software team · Three working days
Project
Hundreds of products flagged in Google's shopping feed
Several problems at once, and every earlier fix had only revealed the next one. We grouped them by cause and worked through them in order.
Online store · Three weeks, mostly waiting for Google to reprocess
Monthly service
Supplier payment runs checked before they go out
A second pair of eyes on every payment run, with the evidence for each flag, so a duplicate or a changed bank detail is found before the money leaves.
Finance and back office · Ongoing, monthly
Get a price for something like this
You are asking about: WooCommerce checkout after an update.
Sending this is not an order. We check we can help, then agree what is included, safe access and the price in writing before any work. Prefer email? hello@syntheticindustry.ai.