3 ms·

> Ok, weird. That means that the client has to send a correctly calculated price in the purchase order, because the server validates the order by performing its

> Ok, weird. That means that the client has to send a correctly calculated price in the purchase order, because the server validates the order by performing its own price calculation. While this left me stumped as to why the client-side calculation even exists, it meant I couldn't just tell the game to give me free cards, or cards at a negative price, or anything else. I assume it's to detect stale data. What if the price changes while they're looking at the screen? At the very least, you want to make sure the player sees how much they're paying for something if the price changes out from under them. Another alternative is to honor the price they saw, but that can be more complicated. It's easier to do a price check on the server side, reject the wrong price, then have the client refresh with the correct pricing.

__turbobrew__ 3y ago
When the client fetches the prices it could come with a catalog version number or some other opaque cursor which could be submitted with the purchase. If the cursor is out of date the server can simply reject it or choose to honor the old price by looking up the price in the old version pf the catalog.
- genocidicbunny 3y ago
  The calculated price _is_ that version number, but smarter because it requires fewer checks and additional data. You don't really care if the catalog changed version, you care if the specific item in the catalog, for a given quantity of it, changed prices. You do lose the ability to look up the old price and apply that, but that is very rarely desirable anyways. Far easier and straightforward to just reject the transaction and have the user try again.
  - __turbobrew__ 3y ago
    > You do lose the ability to look up the old price and apply that For certain e-commerce sites that would be a big loss. This is largely a solved distributed systems problem and I don’t see how passing the cursor back to the server is any more complex than calculating prices.
    - dontlaugh 3y ago
      It's quite common in games for the store catalogue to be produced by pricing tools and handled as a static file by the server. It's then simpler overall for the client to volunteer a maximum price and the server either charges the current price in the file or refuses.
- MrStonedOne 3y ago
  [dead]

__turbobrew__ 3y ago

When the client fetches the prices it could come with a catalog version number or some other opaque cursor which could be submitted with the purchase. If the cursor is out of date the server can simply reject it or choose to honor the old price by looking up the price in the old version pf the catalog.

genocidicbunny 3y ago
The calculated price _is_ that version number, but smarter because it requires fewer checks and additional data. You don't really care if the catalog changed version, you care if the specific item in the catalog, for a given quantity of it, changed prices. You do lose the ability to look up the old price and apply that, but that is very rarely desirable anyways. Far easier and straightforward to just reject the transaction and have the user try again.
- __turbobrew__ 3y ago
  > You do lose the ability to look up the old price and apply that For certain e-commerce sites that would be a big loss. This is largely a solved distributed systems problem and I don’t see how passing the cursor back to the server is any more complex than calculating prices.
  - dontlaugh 3y ago
    It's quite common in games for the store catalogue to be produced by pricing tools and handled as a static file by the server. It's then simpler overall for the client to volunteer a maximum price and the server either charges the current price in the file or refuses.
MrStonedOne 3y ago
[dead]