Diwali falls on 8 November 2026. Count back 34 days and you land on 5 October, which is the last sensible date to start hardening a store rather than decorating it. Most Shopify store Diwali sale preparation checklists you will find are marketing lists: banners, countdown timers, email flows. Useful, but none of those are what breaks at 9pm on the biggest night of the year. Three things break. Payment failures spike on UPI and nobody is watching the gateway logs, COD volume runs away and takes your margin with it, and inventory goes negative on the one SKU everybody wants. Fix those three and the rest is just merchandising.
What follows is the run sheet we work through with Indian brands every October, in the order it has to happen.
The 34-day run sheet
Dates assume a 8 November Diwali. Shift them if your peak is Dhanteras, which for most jewellery, appliance and homeware brands is the real spike.
- 5–11 Oct (days 34–28): Pull 90 days of gateway data and split success rates by method. Audit app stack and delete what you are not using. Baseline mobile LCP on a throttled connection.
- 12–18 Oct (days 27–21): Fix the payment failure causes you found. Set COD rules: pincode list, value cap, verification. Clean up inventory locations and sync intervals.
- 19–25 Oct (days 20–14): Load-test your own theme, not Shopify. Confirm courier pickup capacity with Delhivery or Shiprocket for the surge week. Lock the discount structure so nothing is being invented on the fly later.
- 26 Oct–1 Nov (days 13–7): Buffer inventory. Dress rehearsal: run a real ₹1 order through every payment method on a real phone on mobile data. Then run it again as COD.
- 2–7 Nov (days 6–1): Code freeze. No theme edits, no new apps, no checkout experiments. Staff the war room. Pre-write the out-of-stock and delayed-dispatch messaging.
- 8 Nov onwards: Watch four numbers hourly: payment success rate, COD share, oversell count, and time-to-first-byte.
The code freeze is the part people argue with. We hold it anyway. More festive incidents come from a well-intentioned Friday theme change than from traffic.
Why UPI fails at checkout, and the Razorpay fix that actually moves the number
Open your Razorpay, PayU or Cashfree dashboard and filter attempted payments by method for the last quarter. You will see a success rate for cards, one for netbanking, and one for UPI. If UPI is sitting materially below your card success rate, the cause is almost always one of four things, and only one of them is the gateway's fault.
Collect requests timing out. This is the big one. A UPI collect request sends a pull notification to the customer's app and waits. The customer has to switch apps, find the request, authenticate, and approve, usually inside a two to five minute window. On a patchy 4G connection in a market crowd on Dhanteras evening, a meaningful share of those never get approved. UPI intent, where tapping the payment option deep-links straight into GPay or PhonePe with the amount pre-filled, removes three of those steps. On mobile, intent should be the default and collect should be the fallback for desktop, where intent cannot work and the customer scans a QR instead.
So the first question to ask your gateway account manager is not "why is UPI failing", it is "what percentage of my UPI attempts are going out as collect requests on mobile devices, and can we switch those to intent?" Most merchants have never asked. In our experience the gateway's default checkout configuration is rarely the one you would choose if you looked at the device split.
The other three causes: an app or theme script blocking the redirect back from the UPI app, so the payment succeeds at the bank but the order never gets created; webhook failures leaving paid orders stuck as abandoned checkouts; and bank-side downtime on specific handles, which peaks exactly when everyone is transacting. For the third one you cannot do much except make sure the customer gets offered a different method quickly instead of staring at a spinner.
Two concrete fixes before 18 October. First, turn on gateway webhook retries and set up an alert if a payment is captured without a matching Shopify order. Second, reconcile daily during peak week rather than weekly. A paid-but-not-created order found on 10 November is a refund. Found on 8 November it is a happy customer.
Capping COD before it eats the month
COD is still a large share of orders for most Indian D2C brands, and festive buying pulls in exactly the customers most likely to choose it and most likely to refuse delivery. Here is the arithmetic that decides your policy. Take an order with AOV ₹1,800:
- RTO on a COD order costs forward shipping plus return leg. At roughly ₹65 each way that is ₹130, plus around ₹40 in packaging and handling you do not get back.
- If your COD RTO rate is 25%, the expected RTO cost per COD order is 0.25 × ₹170 = ₹42.50.
- Add the COD collection fee, around 1.5% of ₹1,800 = ₹27.
- Total expected cost of taking that order as COD rather than prepaid: about ₹69.50.
Now look at the 5% prepaid discount everyone copies. On ₹1,800 that is ₹90 of real margin given away to save ₹69.50. You lose ₹20 per converted order, and you also hand the discount to every customer who would have paid online anyway. A flat ₹50 off prepaid, or free shipping on prepaid only, is usually the tighter instrument. Run your own numbers with your own RTO rate before copying anyone's percentage. If your RTO is 35% and your AOV is ₹900, the answer flips entirely.
For hard limits, there are three levers worth setting before Diwali:
- A COD order value cap. Above a threshold, COD disappears from checkout. On Shopify this is done with a payment customisation function, and most of the India-focused COD apps on the App Store ship one. Pick a ceiling where an RTO genuinely hurts: for many brands that is ₹2,500 to ₹5,000. Note that editing the checkout interface itself, as opposed to hiding a payment method, still requires Shopify Plus.
- Pincode-level rules. You already know which pincodes your returns come from. Block or restrict them for COD during the surge week. This is unglamorous and it works.
- Verification. An OTP or WhatsApp confirmation step on COD orders above a value, with auto-cancel if unconfirmed in 24 hours. The friction is the point.
One warning. Do not introduce a COD cap on 7 November. Ship it in the third week of October and watch what happens to conversion and to COD share for a fortnight. If the cap costs you more orders than it saves, you want to know that while you can still reverse it.
Stock buffers and why Shopify oversells during a flash sale
Overselling on a flash sale is rarely Shopify miscounting. It is lag. Three common sources:
Checkout reservation windows. Inventory is held when a buyer reaches checkout and released if they abandon. During a sale, a chunk of your stock can sit reserved in carts that will never convert, which makes the storefront show out-of-stock while real units sit in the warehouse. The inverse also happens when reservations expire in bursts.
Third-party sync intervals. If your ERP, WMS or a marketplace connector polls every 15 minutes, 15 minutes of sales on a hero SKU is your oversell exposure. Here is the buffer calculation. A SKU selling 40 units an hour during peak, with a 15-minute sync gap, can move 10 units between syncs. Set the buffer at 10 to 12 units, not a flat 5 across the catalogue. Buffers should be proportional to velocity, not uniform.
Multi-location arithmetic. This breaks more often than anything else. If you have a Bengaluru warehouse and a Delhi one, and your theme is showing the combined total while your fulfilment rules only pull from one, you will promise stock you cannot ship into the north. Test this specifically. We get location logic wrong on the first pass more often than we would like, usually because a client turned on a second location in September and told nobody.
The practical settings: continue-selling-when-out-of-stock off on everything except genuine pre-orders, per-SKU buffers on your top 20 lines, and a daily physical count on those 20 through the peak week. One person, one spreadsheet, ten minutes. It catches the drift that software does not.
How much traffic a Shopify store can handle
Shopify's infrastructure will not be your bottleneck. The platform absorbs flash-sale volumes that would flatten a self-hosted stack, and during extreme spikes buyers are held briefly in a queue at checkout rather than being dropped. Your theme is the bottleneck.
What actually degrades: a homepage carrying nine apps' worth of JavaScript, unoptimised hero images at 1.2MB, and a collection page that fires a search query on every keystroke. On a mid-range Android on 4G in a tier-2 city, that is a 4-second LCP, and a four-second wait during a sale is an abandoned cart. Measure on a throttled mobile connection, never on your office wifi.
Our rule for October: get mobile LCP under 2.5 seconds, and ideally under 1.8, before you add a single festive popup. That usually means removing apps rather than adding optimisation. If you want the measurement automated and tracked over the peak week instead of checked once, SwiftStore scans and monitors PageSpeed continuously, and our speed optimisation work covers the theme-level fixes a scanner cannot do on its own.
Also test your collection pages under load. A catalogue of 2,000 SKUs with a slow filter is a worse festive experience than a catalogue of 200. If filtering is where your sessions die, that is a navigation problem, not a traffic problem.
The back office nobody checks until it is too late
GST invoices with the correct HSN codes, generated automatically, for order volumes three times your normal day. If your invoicing app chokes at 400 orders a day, you will find out on 9 November. Test it with a bulk order import in late October.
E-way bills for consignments above the threshold, courier pickup slots confirmed in writing with your Delhivery or Shiprocket account manager for 9 to 14 November, and a decision made in advance about what you tell customers when dispatch slips. Pre-write that message. Nobody writes good copy at 11pm.
Set your WhatsApp order-update flow before the rush too. Shipping queries are the volume that drowns a two-person support team, and most of them are answered by a dispatch notification the customer never received.
Questions we get asked every October
Is UPI intent really better than collect? On mobile, yes, because it removes the app-switching and the approval timeout. On desktop you are stuck with collect or a QR. Check your own gateway's method-level success rates before and after switching rather than taking anyone's word for it.
Can I cap COD by order value without a Plus plan? Yes. Hiding a payment method above a cart value runs through a payment customisation function, which the India-focused COD apps provide. Restructuring the checkout page itself is the Plus-only part.
What buffer should I set for festive peak? Velocity times sync lag, per SKU, on your fastest 20 lines. A flat number across the catalogue either strands stock on slow movers or fails to protect the fast ones.
Should I migrate platforms before Diwali? No. If you are on a platform that cannot cope, do the work in January. A migration five weeks out is how you spend peak week debugging redirects instead of selling.
Start with the gateway data
Before anything else, export the last 90 days of attempted payments and split success rate by method and by device. That single query usually tells you where the money is leaking, and it takes twenty minutes. Once you know your UPI number, your COD share and your top 20 SKU velocities, the rest of the run sheet writes itself.
If you want a second pair of eyes on the checkout and inventory setup before the freeze date, our team in Bengaluru runs a free store audit and we book October slots early for exactly this reason.