[raffael_de]

> Send the same payment twice and one of them should respond "payment already exists".

You are hiding the relevant complexity in the term "same". What is here the same? I mean, if accidentally buy only 1 instead of two items of a product and then buy afterwards again 1 item. How is this then the same or not the same payment?

[mrkeen]

> What is here the same?

The idempotency key of the request

[raffael_de]

How and based on what is the idempotency key calculated which the clients sends with its request? In my double-purchase example above: when would the second purchase be requested with the same key or not?

[Xenoamorphous]

If it’s a retry of the same request it should have the same key. If it’s not a retry, a different one. I don’t see the issue.

If the client sends the same key but a different payload that’s a 400 or 409 in my eyes.

[shiandow]

It shouldn't, an error would be the right response.

[mrkeen]

1) Fresh UUID

2) Client's choice

[raffael_de]

now you are moving the core question to where the fresh UUID is calculated. a UUID is calculated or reused based on a process-defined decision.

[mrkeen]

It's not the 'core question'.

I can choose to purchase a 2nd item, or I can choose to retry purchasing the 1st item. The server making that choice for me is not idempotency.

Idempotency is the server supporting my ability to retry purchasing the 1st item, safe in the knowledge that they won't send me a 2nd one.