The idempotency-key header the adapter sends on every capture, cancel and
refund. A caller's idempotencyKey is arbitrary; Adyen's header takes at
most 64 characters. A SHA-256 hex digest is exactly 64 and deterministic, so
the same caller key on the same endpoint always derives the same header value
and a replay dedupes at Adyen.
The request path is part of the digest because Adyen stores idempotency keys
at company account level, not per endpoint: without it, a capture and a
refund under one caller key would receive each other's stored answers. A
modification's path also carries the payment's pspReference, which Adyen
makes globally unique, so two merchant accounts of one company never derive
the same value; and it is the value 0.1.0 sent on every call, so a
modification retried across the upgrade still dedupes. /payments and
/payments/details carry no pspReference in their path, so the adapter
derives their header differently, covering the merchant account as well.
The
idempotency-keyheader the adapter sends on every capture, cancel and refund. A caller'sidempotencyKeyis arbitrary; Adyen's header takes at most 64 characters. A SHA-256 hex digest is exactly 64 and deterministic, so the same caller key on the same endpoint always derives the same header value and a replay dedupes at Adyen.The request path is part of the digest because Adyen stores idempotency keys at company account level, not per endpoint: without it, a capture and a refund under one caller key would receive each other's stored answers. A modification's path also carries the payment's pspReference, which Adyen makes globally unique, so two merchant accounts of one company never derive the same value; and it is the value 0.1.0 sent on every call, so a modification retried across the upgrade still dedupes.
/paymentsand/payments/detailscarry no pspReference in their path, so the adapter derives their header differently, covering the merchant account as well.