The hardest part of idempotency is often not the retry. It is deciding when two attempts represent the same business operation.
Sometimes the identity is a request ID or external message ID. Sometimes it is a business key or a state transition that may happen only once. Once that identity is explicit, a transaction and database uniqueness constraint can enforce it, even when two attempts arrive together.
Without identity, "make it idempotent" is not yet a design. The system still does not know what must not happen twice. This matches how Stripe and AWS describe safe retries: repeated attempts need a stable identity so the original side effect is not performed again.