An automated security scan of a checkout flow revealed no traditional vulnerabilities like SQL injection or cross-site scripting. A junior pentester was prepared to label the engagement as having no significant findings based on the scanner's results. However, a team member noticed an endpoint for applying discount codes did not invalidate the code until after order confirmation. This design flaw meant a single-use code could be redeemed multiple times concurrently.By sending the same request concurrently, a single-use 50% discount code was redeemed forty times within seconds. This type of vulnerability, a race condition, occurs due to a gap between checking code validity and marking it as used. Automated scanners cannot detect race conditions because they test requests sequentially, not concurrently. Vulnerable endpoints often involve a "check-then-act" pattern, such as redeeming coupons or withdrawing funds.To exploit race conditions, requests must be sent simultaneously, not just rapidly, to minimize network jitter. Tools like Burp's race condition tab or Turbo Intruder are designed for this purpose. Proof of a race condition lies in the final state of the system, such as the number of times a code was applied, rather than just successful response codes. This type of business logic flaw is missed by scanners and requires manual investigation into concurrent application behavior. Codelivly's resources and labs focus on these advanced vulnerabilities that go beyond automated scanning capabilities.