There is a class of bug that never shows up in testing, never throws an error, and costs real money: trusting what the browser sends you.
It is an easy pattern to fall into, and I see it regularly, especially in sites that were built in a hurry or generated by an AI tool. The page has already worked out the total to show the customer: quantity, delivery, fees, the discount code. Passing that number straight to the checkout feels efficient. It is right there. Why calculate it twice?
Because the browser belongs to your customer, not to you. Every value the page sends back to your server, form fields, hidden inputs, the contents of a request, can be edited by anyone who opens their browser's developer tools. A £400 order becomes a £4 order with one modified request, and your payment provider will process it without complaint. No alarm, no error. Just a completed sale at one percent of the real price.
This is not a sophisticated attack. It is the first thing a curious person tries.
The rule: recalculate everything server-side
On every site I build, the checkout ignores the total the browser sends entirely. When an order arrives, the server works everything out again from its own data: the product's price, the quantity, what is actually in stock, the delivery cost, whether that discount code is real and still valid. Only that server-calculated figure goes to the payment provider.
The page still runs its own version of the calculation, but only to show the customer what they will pay. It has no say in what they are actually charged. Both sides can share the same pricing logic; they do not share the same authority.
The same principle covers everything else that matters. Stock limits, delivery eligibility, whether someone is allowed to view a page or download a file, anything that affects what a person pays or receives gets confirmed on the server. The browser's job is to make the experience smooth. The server's job is to make it correct.
Why it is worth doing from the start
What makes this worth writing about is the cost difference. Building the server-side check from the start is nearly free, it is the same logic you would write anyway, just put in the right place. Adding it after someone finds the gap costs an investigation, refunds to chase, an awkward conversation with your customers, and a line in every future due-diligence questionnaire. I have reviewed sites where this gap sat open for months. Whether anyone used it was, uncomfortably, impossible to know.
The general rule: any number that moves money, and any check that grants access, gets worked out where the customer cannot touch it. Everything the browser sends is a suggestion. Some suggestions are safe to accept. Prices are not among them.
If you are not sure whether your site does this, get in touch. It is one of the first things we check.
Written by
Steven Noble
Steven Noble is the founder of Graphics Cove, a senior full-stack engineer with 19 years building web products for startups and established companies. He writes about engineering, delivery and running a technical practice.