idempotency-audit

Send the same request multiple times with the same payload or idempotency key and compare the resulting effect. Then simulate a lost response followed by a retry, and check whether the server returns the original effect or executes the operation again.

An idempotency key is a stable identifier of the client's intent, such as an Idempotency-Key header or a webhook eventId. The server must look up the key before acting so a repeated request returns the original effect instead of duplicating it.

Require an idempotency key per charge attempt and enforce it with a unique constraint so the second insert fails. On retry, look up the existing charge by key and return it instead of charging again.

Providers redeliver events when they do not receive an acknowledgment, so the same eventId arrives more than once. Without deduplication on eventId, the handler processes the event again, duplicating effects like rewards or order updates.

Yes, if both requests perform the key lookup before either one writes, both pass and both execute. A unique constraint on the idempotency key makes the second insert fail, closing the race.

Naturally idempotent operations like GET, absolute-value PUT, and DELETE should not be reported. Also exclude cases with proper key verification plus unique constraints, or counters that are approximate by design and tolerated by the product.