Your checkout returns a server error once a delivery option is chosen.

This is what a customer sees at the point they are trying to give you money.

This fault sits at the last step before payment. A customer has already found your product, decided to buy it, and started giving you their details. That is the most expensive visitor you have — every pound of marketing spend that brought them here has already been spent.

Because the failure happens after the basket, nothing earlier in the journey looks wrong. Your homepage is fine. Your product pages are fine. Standard uptime monitoring will report the site as healthy, because it is: the server is responding, it is just responding with an error on this one route.

Customers almost never report this. From their side it looks like your business is having a bad day, so they close the tab and buy elsewhere.

Your website appeared in our queue of publicly listed UK business websites. We walked the same publicly accessible route a prospective customer would: the homepage, a product page, the basket, and then the checkout.

When the delivery step returned an error, the finding was held rather than reported. It was checked again four minutes later, confirmed independently in a real browser, and re-checked two days after that. Only then did it become a report.

You can verify this yourself right now. Add any item to your basket, go to the checkout and select a delivery option. You should see the same failure we did. If you don't, tell us — see the note in the sidebar.

If this email arrived unexpectedly, this is the section that matters. Everything we saw, any visitor to your website could see.

• We did not log into any account, admin area or private system.
• We did not guess, test or attempt any password.
• We did not bypass authentication or any access control.
• We did not view, download or store any customer or private data.
• We did not enter payment or card details at any point.
• We did not place an order or complete a transaction.
• We did not submit any form, enquiry or contact message.
• We did not run any security, penetration or load testing.
• We did not modify anything on your website.

The failure above was returned by your own server in response to an ordinary page request. Nothing about our visit caused it.

A 500 on a single checkout step, while the surrounding pages are healthy, almost always points to the code path that runs when delivery options are calculated — not to the site as a whole. The most common causes are a shipping or delivery extension that has updated, a delivery rule referencing something that no longer exists, or an integration timing out without being handled.

The repair pack for this finding contains:

• A documented reproduction, so whoever fixes it can see the failure immediately.
• The technical diagnosis and the most likely root causes, ranked.
• The specific route, component and integration to inspect first.
• Server-log locations and what to look for in them.
• Implementation steps written for a developer to act on directly.
• A verification checklist to confirm the fix actually worked.
• A re-check by us once you tell us the change is live.

Your existing developer or agency can implement this. The pack is written to be handed over as-is — you do not need to involve us further.