If I were a user, and the system told me that it was aware of what I wanted to do, and capable to do it, and it was in both of our financial best interests that the system fulfill my request, but it was deciding not to until I went back and jumped through an additional pointless hoop, before doing what I'd attempted to do in the first place... I definitely would be more irritated than not.

It might be worth having a prominent notification that the system was fulfilling the expired request, so it's not confusing that the expired tickets work sometimes and not other times. Or, maybe just tell them the JWT they've got is expired, and ask them yes or no if they want the new (current) price instead, and update it transparently if they say yes. You can have a higher price if it's higher, and depending on your relationship with the customers, you could either lower the price if it's lower or just leave it at the current price and have them get what they get. But I would definitely make things easy and smooth for the customer in this type of situation as opposed to making the system easy to make, at the expense of having them have to click through a little circular runaround when the system is aware of exactly what they're trying to do.

From an API perspective I agree with you. From a UX perspective I agree with them.

In the end, you're writing software to benefit users, so user benefit is top priority.

Luckily, you can have it both ways. Keep the API pure and simple, returning a meaningful error to the client, and the client then procures a new JWT completely transparently to the user, and retries.

I suspect you're overcomplicating things by using a JWT, but that kind of decision screams "confounding factors" that affect design decisions that you haven't/can't elaborate on. It'd just take some minor tweaks of the standard "shopping cart" API/DB design to get what you want, so I assume there is a reason you haven't gone that route.

I don't really have an answer for you here, but isn't having the expiry pointless now if you're going to honour an elapsed token?

The argument has become "if price X mins ago is equal to price now, honour it" - so it could have expired 10 mins ago, or 10 days ago, etc. and you'd still be honouring it, right?

So, why have an expiry at all in this scenario? The question should become, if we're going to honour it after 5 mins, will we honour it at 10 mins? 100 days? Which? A cut off needs to be defined.

Just my opinion here but using a signed JWT instead of a server local variable seems needlessly risky for communicating a price. Considering the potential liability to the company if your signing token is compromised I'd much rather send the prices to the user and keep a server local copy tied to the account/session/auth token. When the user tries to confirm the price we'd just pull the information from local storage.

In terms of your primary question though... I can see the UX advantage of honoring the expired token if prices were stable but I'd probably roll out an MVP without that feature fully developed but with some logging to flag how often it'd activate - throw the statistics at business people and let them ponder how often it'd activate.

That all said, this is an API not a GUI so I really don't care as much about the UX since the consumer can just automate resubmitting for a new token - especially if we're putting together an SDK or code samples for clients to run the requests and double especially if we're controlling both ends with a distributed binary (but that doesn't sound like the case here).

The frontend should inform the user (that the "price lock" time has expired) and refresh the price automatically. Then when they click submit there should always be a non-expired token. You should also be storing details of these tokens server-side so you can validate that it's not been tampered with (if someone gets the private key. They can submit orders for any price?)