AT&T's website raising the price every time I refresh the page

It could be that some local taxes or fees comes out to $10, and the client code does `price += taxes` on page load.

There could be code to round up to a $10 increment, and then subtract 2 cents so the prices are all $X9.98, but the rounding logic is incorrect. Since this is JS, they will be using floating point prices. That is a minefield in itself.

I'm not saying it's definitely a bug. But it trivially could be.

No idea if GP is correct, but that would not even be close to the weirdest thing I've seen in production code in companies. Very plausible to me that an engineer for a large company could write code like that. Short answer, corporate codebases are messy and weird, and because they are already messy and weird they are therefore breeding ground for even more baffling decisions based on time constraints and partial understandings of already weird systems.

Especially in legacy systems, questionable, weird design choices keep producing other questionable, weird design choices until explaining why AJAX requests are getting parsed through hidden input fields or why all of the localstorage fields are Base64 encoded suddenly requires a multi-part, 5-10 minute story about the history of the codebase -- and that's if you're lucky enough to have anyone around who knows the story in the first place.

Related to the above, if you're in charge of an engineering team at a company please build more time into your team's schedule for refactoring and code cleanup.

----

To jump off of OP's (at the top of the thread) point, it could also be a bug with malicious pricing. A programmer might have tried to build a dynamic pricing system based on geographic area or whatever and just accidentally read the base price from the same cache they're writing to.

And if your followup question is "but why would you read the base price from localstorage instead of from the server, or why would you even have that logic clientside in the first place?" -- then see the first point above.

But none of the explanations here would be surprising to me at all. It's not really a debate about whether AT&T alters prices based on stuff like area and customer data, I'd be surprised if someone tried to claim they don't. But like OP said, this doesn't make much sense from a conversions point of view; and it's way more likely to be a bug than it is to be an executive mistakenly believing that raising the price by $10 on every refresh makes people more likely to buy Internet.

That executive already has better methods to increase prices: adding hidden fees and service charges, and raising prices behind the backs of long-term customers who aren't checking their bills regularly enough or who are unlikely to go to the trouble and inconvenience of switching or fighting the bill.

My suspicion is bug.

Not in the web space but I've seen similar with using pythons lrucache as using that on a function modifies the programs behaviour (if you mutate the returned value, you're in trouble).

Taking it a step further: a browser extension that tries several scenarios (like Honey, but just for re-fingerprinting and stuff... can an extension make a request that suppresses/manipulates cookies only temporarily?) as you're shopping.

The server validated that the coupon code was legitimate, but the actual discount value of the coupon code was validated client side in JS for some reason.

So he could turn any 10% off coupon into a 100% off coupon by modifying the API requests during the checkout flow. I'm sure this was illegal but he ate a lot of free fast food before they ever fixed it.

I doubt a “reasonable” person would think of it like the latter case, but for people who think about software agents, it’s interesting to think about.

Disclaimer: don’t try this at home…

This is why educating the public about jury nullification is so important.

Maybe I'm misremembering but I vaguely recall a story of a man who altered a contract, signed it, and mailed it back to a telecom company. They signed it without reviewing and when it went to court it was upheld because both parties signed the altered contract.

But I understand that's different than "demanding" they accept it so it doesn't negate your point.

That's the shocking thing. I've heard of cases where dropping cable would increase the bill. I suspect that's because it's easier to defend leveraging your monopoly power if you can show customers are "buying" other services like cable.

You can restart the flow from scratch, and you'll still get "n seats available at this price", which rules out that it was booked while I was looking.

> so they cache a lot of things and only get realtime inventory when you're very close to booking; then they often do a very poor job of cache invalidation (because it's hard)

Yet the end result is the same: the consumer gets a bait and switch.

You're not wrong here, but what you point to is the problem: companies using "blame computers" as a way to abdicate responsibility for the problem.

> There's a lot of ways you could organize the data so it's less terrible, but all of those involve a lot more IT involvement than airlines want to invest it.

Precisely. One can look at it too as there is no penalty these days for screwing consumers over, so there's no economic impetus to do anything about it when it happens.