Yep! I've noticed older games tend to utilize this trick; I spotted it in a certain Korean golf MMO from ~2004. It did have me scratching my head initially, but if I were the one designing the game, it definitely would've occurred to me that I don't want the value to mismatch.
Of course, I think this is a bit old-timey now. If I were developing a game today, I'd probably make the store emulate how a typical store with a shopping cart works; do everything on the server side, and just display it to the client. I can, however, imagine coming up with this scheme if I were faced with the same problem, and I can appreciate that it is an elegant way to reduce the load/statefulness of the server without adding the risk that someone might get shafted.
> [...] how a typical store with a shopping cart works; do everything on the server side, and just display it to the client.
The same concerns apply for a typical shopping cart design. The price can change in between the time when you sent the price to the client, and the time when the user actually decides to buy.
Well, in case of the server-side shopping cart, the server would have enough state to know if the price has changed since an item was added to the shopping cart, so the client wouldn't necessarily need to participate in preventing this scenario. I'm sure in practice, the checkout confirmation process for modern e-commerce sites also takes extra precautions to ensure that it can only happen exactly once and that it fails if any details change during the process of checking out.
