How would you test concurrent requests with an idempotency key?

A fictional payment sandbox moves 1,000 cents from account A to account B. No real money is involved. A client supplies a tenant-scoped idempotency key and a fixed payload. For 24 hours, matching retries must refer to one payment and create one debit, one credit and one receipt event in a deduplicated outbox. The first completed request can return 201; completed replays return 200 with the same payment ID; an in-progress response is 202. Reusing the key with different payload data returns 409 with idempotency_conflict. A strongly consistent lookup by tenant/key and an independent sandbox ledger read are available. With the healthy executor in this fixture, processing finishes within 10 seconds. The outbox may be delivered more than once, but the receipt consumer must produce one visible receipt.