Why E-Commerce Bugs Cost Revenue
E-commerce code failures have immediate revenue impact: a broken checkout flow loses sales in real time (every minute of downtime costs revenue), an inventory oversell creates orders that cannot be fulfilled (refunds, angry customers, marketplace penalties), a pricing error charges the wrong amount (legal liability if undercharged, chargebacks if overcharged), and a payment integration bug double-charges customers (chargebacks, trust destruction, potential card network fines).
AI-generated e-commerce code must handle: concurrent access (thousands of users buying the same product simultaneously), state consistency (inventory decrements must match order creations), price integrity (the price at checkout must match the price displayed), and payment safety (PCI compliance, idempotent charges, proper refund handling). These are not nice-to-have quality attributes — they are business requirements that determine whether the store makes or loses money.
The governance framework: e-commerce AI rules encode business invariants that must never be violated. The most critical: never allow checkout to succeed if inventory is zero, never charge a different price than displayed, never process a payment without an idempotency key, and never expose raw payment card data.
Checkout Flow and Inventory Safety
Checkout atomicity: the checkout process (validate cart → reserve inventory → process payment → create order → send confirmation) must be designed so that failures at any step result in a consistent state. If payment fails: release reserved inventory. If order creation fails after payment: refund the payment and release inventory. AI rule: 'Checkout is a saga or transaction with compensation. Every step has a rollback. Payment failure: release inventory. Order failure: refund payment + release inventory.'
Inventory race conditions: 100 users add the last item to cart simultaneously. Without protection: all 100 can check out, creating 99 oversells. Solutions: optimistic locking (decrement inventory with WHERE quantity >= requested), pessimistic locking (SELECT FOR UPDATE on the inventory row), or reservation system (reserve stock when added to cart, release after timeout). AI rule: 'Inventory updates: atomic decrement with quantity check. Never read quantity then separately update — use UPDATE inventory SET quantity = quantity - 1 WHERE id = ? AND quantity >= 1.'
Cart pricing consistency: the price displayed when the user adds to cart may differ from the price at checkout (flash sale ended, price updated). AI rule: 'Lock the price at the moment of checkout initiation, not at add-to-cart. Display the final price before payment confirmation. If the price changed since add-to-cart: show the user the updated price and require re-confirmation.'
The classic oversell bug: SELECT quantity FROM inventory (reads 1). Two requests read simultaneously. Both see 1. Both UPDATE quantity = 0. Both create orders. Result: 2 orders for 1 item. Fix: UPDATE inventory SET quantity = quantity - 1 WHERE id = ? AND quantity >= 1. Check affected rows — if 0, inventory was depleted. This single-query atomic pattern eliminates the race condition entirely.
Pricing Accuracy and Promotions
Price calculation: AI-generated pricing code must handle: base price, quantity discounts, promotional codes, loyalty discounts, tax calculation, shipping cost, and currency conversion. Each step introduces precision risks (use integer cents, not floats). AI rule: 'Price calculation: all values in integer cents. Apply discounts as percentage of cents. Round once at the final total, not at each step. Display formatted currency only at the UI layer.'
Promotional code handling: promotions have rules (one per order, minimum spend, specific products, date ranges, usage limits). The AI must generate validation that enforces all constraints. AI rule: 'Promo code validation: check expiration, minimum spend, product eligibility, usage count, and combinability before applying. Never apply a promo code without full validation. Store the applied promo with the order for audit.'
Tax calculation: sales tax varies by jurisdiction, product category, and customer type. AI rule: 'Never hardcode tax rates. Use a tax service (Avalara, TaxJar, Stripe Tax) or a configurable tax rate table. Tax calculation happens server-side at checkout, not client-side. The AI should integrate with the project's existing tax calculation method, not invent a new one.'
Rounding at each step of a price calculation compounds errors. $10.00 base - 15% discount = $8.50 (ok). $8.50 + 8.25% tax: if you round to $9.20, then add $5.99 shipping = $15.19. If you do not round until the end: $8.50 + $0.70125 tax + $5.99 shipping = $15.19125 → $15.19. The difference is pennies, but across millions of orders, it adds up. Calculate in cents, round once at display.
Order State Machine and Fulfillment
Order lifecycle: every order follows a state machine with defined transitions. Typical states: pending → paid → processing → shipped → delivered. Additional: cancelled, refunded, partially_refunded, on_hold. AI rule: 'Order status transitions must follow the defined state machine. The AI must not generate code that transitions directly from pending to delivered. Each transition has validation rules and side effects (paid → decrement inventory, cancelled → restore inventory + process refund).'
Refund handling: refunds must be atomic (the order status, inventory, and payment refund must all update together). Partial refunds: return specific line items, update order totals, process partial payment refund. AI rule: 'Refund endpoint: validate the refund amount does not exceed the paid amount. Process payment refund first. If payment refund succeeds: update order status and restore inventory. If payment refund fails: do not change order status.'
The AI should generate order management code that: enforces state machine transitions, handles partial operations (partial shipment, partial refund), produces audit events for every state change, and prevents invalid states (an order cannot be shipped if it was cancelled, a refund cannot exceed the paid amount).
Without a state machine: code can accidentally set an order from 'cancelled' to 'shipped' (a developer forgets to check current status). With a state machine: the transition function rejects invalid transitions and throws an error. The AI should generate order status updates through a transition function, never by directly setting the status field. This prevents every impossible state combination.
E-Commerce AI Governance Summary
Summary of AI governance rules for e-commerce platform development teams.
- Checkout: saga pattern with compensation. Every step has a rollback on failure
- Inventory: atomic decrement with quantity check. No read-then-write. Prevent overselling
- Pricing: integer cents throughout. Round once at final total. Never hardcode tax rates
- Promotions: full validation (expiration, eligibility, usage limits) before applying
- Payments: PCI compliant (tokenized). Idempotency keys. Never process payment twice
- Orders: state machine with defined transitions. Every state change audited
- Refunds: atomic (payment + status + inventory together). Amount cannot exceed paid total
- Cart: lock price at checkout initiation. Show updated price if changed since add-to-cart