Guest checkout was disabled and the login reminder was disabled at the same time. A returning customer reaching payment was asked to log in, with nothing on screen explaining how.
Claim language held in one reviewed place, and a monitor that asserts the checkout is not in the trapped configuration — every hour, on a schedule nobody has to remember.
Crawled after the work, with all 44 products loading and add-to-cart and remove-from-cart verified end to end rather than eyeballed.
The Install tier for a commerce rescue and the patrol. A store that needs a high-risk payment rail built rather than repaired is Build. How that is priced.
Nothing on the page looked wrong.
Selling in a regulated category means operating where mainstream platforms will not go. Claims are constrained by FDA and FTC rules, most processors decline the category outright, and a single unreviewed sentence on a product page is a regulatory problem rather than a copy problem. All of that was known and handled.
The expensive problem was none of those. It was a checkout setting, and it was invisible to everyone testing the site, because everyone testing the site was already logged in. The failures were sitting in the store logs the whole time.
- The trapped checkoutGuest checkout off and the login reminder off together. Returning customers reached payment and were asked to log in with no path shown. Silent, revenue-destroying, and invisible from an admin session.
- A button over the merchandiseA floating pill sat across the first product card’s category and title on the shop page — the first thing a shopper saw, covered.
- Five category pages returning 404Plus a blog pagination 404 caused by an archive grid asking for nine posts a page while the main query expected ten.
- Backup files served to anyoneOld backup files were publicly readable. Found, removed, and now asserted against on every patrol run.
Four files, four !important rules, and the last one won by accident.
That floating button was positioned in four different stylesheets, every one of them using !important. Which rule applied was decided by cascade order, not by anyone’s intent. Next to it, a second floating element had been targeted by class while the element only carried an id — so that rule had silently done nothing for months and nobody knew.
An !important in four files is not a fix, it is a coin toss. We now grep for every rule touching an element before adding another one, on every engagement. It is the cheapest habit we have and it came from here.
In the order it happened.
- FirstFind it in the logs
Stop guessing, read the failures
The checkout bug was not diagnosed from the front end. It was read out of the store logs, where the failed attempts had been accumulating in plain sight.
- Checkout returned to a configuration a returning customer can complete
- Verified from a logged-out session, which is how it should have been tested originally
- ThenSingle ownership
One owner per element, 404s closed, backups gone
The floating layer was given a single owner instead of four competing ones. Dead category URLs and the pagination mismatch were fixed. The exposed backup files were removed.
- 238 URLs crawled, zero 404s
- All 44 products loading; cart add and remove verified end to end
- 73KB of inline CSS removed from every page
- Lighthouse 100 for performance, accessibility and best practice
- Then it stays fixedThe hourly patrol
A monitor that can actually fail
Key pages returning 200. No errors leaking into the HTML. Exactly one skip link. The floating layer under single ownership. The payment gateway reporting itself available. The shop rendering products. The checkout not in the trapped configuration.
- Emails only on new failures, diffed against a stored baseline, so it never becomes noise people learn to ignore
- Every detector positive-controlled: fed poisoned input to prove it fails, because a monitor that cannot fail is not a monitor