Yes, I wouldn't do it any other way, and it's not the cause of the bug here (except in so far as it didn't contribute to protecting the implementation details by security through obscurity).

There are other ways to do this, but not necessarily simpler:

- explicitly version every change to the store catalogue and require the version to be passed with a purchase, disallowing purchases from old catalogues

- make an expiring signed piece of data (like JWT) for each offer in the store catalogue and require it to be passed back with a purchase, accepting old prices briefly

- make the purchase API two-phase, locking in the price on the first phase and letting the client notice that it changed and potentially neglect to go through with the second phase

There is a good chance they don't even know what the price should be on the backend. The worst kind of apps are constantly running sales, special offer, limited discount, etc... Im pretty sure it's only calculated frontend side since it's very tied to if you just lost or if you are stuck in a game.

And tbh, I think they are okay with 10 hackers are ruining the game, as long as 1 thousand mothers are putting their credit card to pay for gems.

in the article it's explained that they do in fact check the price on the back end

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.

Majority of times I've seen this being solved with shopping cart items being copied from the main product table by SKU with the current price.

There is a TTL on the shopping cart itself. However, that meant for a period of time you had a frozen cost per-line-item in a shopping cart.

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.