Discussion on ""Your product configurator should price server-side, not in JavaScript""

Dominik Groński · 2026-11-04T09:00:00.000Z

Open the devtools on a lot of product configurators, switch to the Network or Sources tab, and you can read the price list. Quantity tiers, wholesale discounts, margin logic, all of it, because the pr

I've seen the same thing with small tools. It's easy to focus on hiding the logic, but trusting a price from the browser is the bigger mistake. Always let the server have the final say.

Exactly. Obfuscation just buys a false sense of safety, anyone with the Network tab still sees the request go out. I keep a client-side price purely for the instant feel while someone drags a slider, but the server recomputes it from scratch at quote and checkout, and that number is the only one that counts. If the two ever disagree, the browser was wrong by definition.

This is the part I keep relearning on small B2B tools. If the browser can see the tier table, a customer will too. I used to ship the total from the client and only check it loosely on submit. Moving the price calc behind the API, and treating the posted number as untrusted, saved me from a messy discount bug. For a single public price I still leave it in the page.

Exactly this. “Treat the submitted number as untrusted” is the whole game. Keeping one public price for display is fine, the sin is letting that number decide what actually gets charged. Sounds like you landed in the right spot.

The integrity half is the one I keep underestimating. I used to think hiding the price list was the whole problem, then realized a tampered total on submit is worse if the server just trusts it. Sending the config and letting the server recompute on confirm is the version I would actually ship. The bit about a price change being a data change, not a deploy, would have saved me a few Friday releases.

Recompute on confirm is the key line. And pricing as data instead of deploys was half the reason I wrote this, good to hear it maps to real pain. No more Friday releases just to change a number.

One detail worth handling on the live-price side is out-of-order quote responses: if option changes fire several quote calls, a slower earlier response can overwrite a newer price unless requests are aborted or responses are sequenced against the current configuration.

Good catch, that race is real. I abort the in-flight request on every change with AbortController and tag each response with the config it belongs to, so stale answers get dropped. Probably worth its own follow-up post.

Separating information leakage from price integrity is useful. I would make the quote reference carry an explicit pricing-version and expiry policy too: if the rules change between preview and acceptance, silently recomputing can surprise the buyer even when the server is authoritative. A clear “quote expired, review the new total” step keeps the security boundary and the buying experience aligned.

Yes. A quote should carry a version and an expiry, and on acceptance you revalidate server-side. If the rules moved, show “quote expired” with the new total instead of silently recalculating. Silent recalculation is how you lose trust.

Search Hashnode

"Your product configurator should price server-side, not in JavaScript"

Responses10