Eh, in that case you're asking for trouble by requiring the server to be successful. If I had to write an API like that I would definitely go with randomized tokens per logical request for dedupe on retries.
If it's a user facing transaction it should be a transaction resource that's created and then the server does the retries imo, with the user able to view the status.
Exactly, given a timeout you can't assume the server is clearly successful (or unsuccessful!). That was my point, we're definitely agreeing :) Usually you'd generate some kind of idempotency key (randomized token as you said) and retry with that.
You definitely can't just bubble that up to the user and assume things are fine
If it's a user facing transaction it should be a transaction resource that's created and then the server does the retries imo, with the user able to view the status.