Does your idempotency key cover partial refunds, or just the original charge?

Most idempotency key discussions stop at "don't double-charge on retry." Fewer teams talk about what happens once a refund enters the picture.

Say a customer gets two partial refunds on the same charge, submitted a few seconds apart by two different support agents — or by one agent double-clicking through a slow UI. If the refund endpoint keys idempotency off (charge_id, amount) alone, the second request looks identical to a retry of the first and gets silently deduped. The customer expected two refunds. They got one.

The fix isn't complicated once you see the gap: the key needs to include something that distinguishes intent, not just the target — a client-generated request ID, a ledger-entry reference, whatever ties the call back to "this specific refund action," not "any refund on this charge."

Curious how other teams have handled this: separate idempotency scope for refunds vs charges, or one scheme that just happens to include enough entropy to avoid the collision?