By Ryan Richardson · Published 8 October 2026
A customer is charged a different amount than the price shown on the page, and no one on the team noticed until the customer mentioned it, or didn't.
A checkout should run on one rule: the server owns the price. The browser sends an identifier, and the server looks up the actual price from its own file; nobody can set their own total by editing the page. When a price is instead typed directly into the page's own copy, separate from that server file, the two can disagree the moment either one is updated without the other. This is the single most common failure in a small checkout, and it's quiet by nature: nothing crashes, no error fires, the wrong number just sits there being charged until a buyer says something, which is worse than a complaint, since it means some buyers never say anything at all.
Write an automated test asserting that the page price and the server price agree, and run it on every single build, not only before a launch. Treat the price file, the consent threshold and the refund wording as decisions that stay with the business owner, never handed fully to an integration partner to maintain independently.
Change one price in your server's price file right now and check whether the page, the checkout, and the receipt all update to match within a day. If any of the three still shows the old number, you have exactly this gap, and it's been open for as long as that surface has been stale.
| Claim | Value | Source |
|---|---|---|
| Why prices written into the page and left to drift are the most common checkout failure | they're the commonest failure here, and it stays quiet until a buyer notices before you do | THE BOOK FULL.md Piece 16, line 1790 |
| The fix: an automated price-parity test | an automated test asserting the page price and the server price agree, run on every build, not just before a launch | Measured in Real Money, Field Manual |