Discount logic correctly applies percentage or fixed amounts
Why it matters
Incorrect discount arithmetic produces wrong prices in every context where the formula runs — cart totals, checkout confirmations, order emails, and refund calculations. The canonical bug: subtracting percentOff as a dollar amount instead of a fraction (charging $100 - 20 = $80 when the intent is $100 × 0.80 = $80 — those happen to be equal, masking the bug until 10% off $50 yields $50 - 10 = $40 instead of $45). A fixed discount that allows negative final prices means a $200 off coupon on a $150 product produces a -$50 cart that Stripe rejects or, worse, creates a refund. ISO 25010:2011 maintainability is the external mapping — calculation logic must be testable and auditable.
Severity rationale
Low because incorrect discount logic is detectable before release via manual testing, affects a bounded set of promotional transactions, and does not expose a security vector.
Remediation
Implement all discount types in a single utility in src/lib/pricing.ts with explicit floor guards to prevent negative prices.
export const applyDiscount = (
basePrice: number,
discount: { type: 'percent' | 'fixed'; amount: number }
): number => {
if (discount.type === 'percent') {
return Math.max(0, basePrice * (1 - discount.amount / 100))
}
return Math.max(0, basePrice - discount.amount)
}
For stacked discounts, apply percentage discounts first, then fixed amounts — document the order explicitly in src/lib/pricing.ts so it doesn't become implicit tribal knowledge.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Catalog & Product Logic Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · maintainability — Maintainability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from ecommerce-catalog·automated