This can actually be a legal requirement, if I were running this site like this and I show you $35 for the ticket, but while your deciding if you want to make the purchase someone buys the last $35 ticket, or ‘demand pricing’ kicks in, do you want to server to just go ahead and charge you $45 for the ‘new’ ticket price or warn you that the price is different? There are of course other ways to do this entirely server side, but I’ve seen more than a few systems that rely on on client side state to reduce server stored session information. And you point out ways to do it securely, but I don’t know that I would expect most ‘enterprise’ developers to know of, much less know how to, build a secure cryptographic signature for a transaction.
I’d guess large multi-part contracting arrangement. Group A is contracted to make the site front end, ticket price display, pricing database, etc. Group B is contracted to make the payment system. Group B has requirements like ‘Accepts a price and payment details, on successful payment send a recipt+ticket.’ And dumb implementation choices ensue.
