A lawn care customer standing at checkout faces a choice that shapes how they think about the purchase. Pay for the whole season upfront — commit now, save later. Or pay per application — lower today, spread across the year. Same service, same lawn, same result. Different psychology.
The system already had prepay. Annual pricing, Stripe payment intent, done. But per-application pricing wasn't just dividing the annual cost by the number of applications. That was the first implementation, and it was wrong. Dividing the total doesn't account for application-specific pricing — the first treatment of the season might be discounted to get someone in the door, and a late-season application might use a more expensive product mix.
The correct price lives in the product's price_ranges table. Square footage maps to price, and per-application discounts or upcharges modify the result. The same pricing table that the frontend ProductCard uses to show the customer what they'll pay. The backend payment intent creation now does the same lookup instead of dividing.
A payment_mode column on the orders table tracks the choice: prepay, per_app, or null for legacy orders that predate the option. The frontend threads the selection through the wizard — QuoteStep emits the choice, LawnWizard relays it, CheckoutStep renders the appropriate Stripe form. Both modes show the same "Pay Now" button. The OrderSummary auto-selects the right pricing tab and, for per-app mode, shows a "Due today (1st app)" line so the customer knows exactly what they're paying for right now versus what comes later.
Backwards compatibility matters because thousands of existing orders have a prepaid boolean and no payment_mode. The confirmation handler checks both: new orders use the mode, old orders check the boolean. No migration needed on historical data.
The insight is that per-application pricing isn't a discount calculation — it's a different way of reading the same pricing table. The data was already there. The checkout just needed to ask the right question.