Every sensitive business flow must have explicit server-side limits on how much any single verified identity can participate:

• Ticket purchase: max 4 tickets per verified account per event. Enforced in the checkout API handler before processing payment.

• Limited-edition retail: max 1 unit per billing address, per payment method, per device fingerprint. All three checked server-side.

• Referral redemption: max 5 successful referrals per account per month. Checked at reward-trigger time.

• Appointment booking: max 1 active appointment per verified phone number at a time.

The OWASP Scenario 3 failure (quantity bypass) happens because the limit lived in the UI dropdown. Any client calling the API directly bypasses the UI. The limit must be in the API handler: if quantity > MAX_PER_ACCOUNT, reject the request with 422 Unprocessable Entity before any inventory is reserved or charged.

Per-account limits can be bypassed by creating multiple accounts. Stack identity layers: per account, per verified phone number, per payment method, per device fingerprint. The more identity signals required, the harder it is for a bot operator to scale.