Independence Day Sale Eve: A 5-Point Stack Health Check for Razorpay-Powered D2C Sites

Amazon's Great Freedom Festival ran July 31 to August 6, 2025 — and Flipkart's Big Saving Days, Myntra's Independence Day campaign, and a long tail of brand-direct mailers all stacked into the same window. By August 14, your Razorpay-powered D2C site has been through ~14 days of festive load. Some things that worked in May are now leaking. We have run this exact 5-point stack health check on 11 D2C sites in the last week — apparel, beauty, supplements, FMCG. Eight of the eleven had a leak that was costing real money. This post is the checklist with the fixes. ## The Answer in 60 Words Run these five checks in order: (1) CDN cache hit rate on your top 20 product pages — should be > 92% during peak; (2) Razorpay webhook handler idempotency — Razorpay redelivers, your handler must dedupe; (3) month-to-date payments vs your DB reconciliation — should be drift-free; (4) SMS rate-limit tuning so order-confirms get through; (5) GA4 event drift caused by checkout-page A/B tests. ## Why This Matters Now (Today is August 14) [Amazon's Great Freedom Festival 2025 ran July 31 to August 6](https://www.aboutamazon.in/news/retail/great-freedom-festival-2025-independence-day-top-deals). Independence Day itself (August 15) drives a second smaller surge from brand-direct mailers and the "use your bonus" campaigns timed to the long weekend. By the morning of August 14, your stack has had two weeks of compounded festive traffic and you are 7 days from the September festive lead-up (Onam, then Ganesh Chaturthi). If something is silently leaking now, fix it before the next surge arrives. The honest version: most D2C teams notice a leak only when their CFO points out the GMV-to-bank-deposit gap at the end of the month. This post is the morning-of-Aug-14 walk-through to find the leak before that meeting. ## Check 1: CDN Cache Hit Rate on Your Top 20 Product Pages The single most expensive performance leak on a Razorpay-powered D2C site is uncached product pages hitting your origin during peak. Even at 12 RPS sustained on the homepage, 3 RPS hitting your origin instead of CDN can saturate a single Hetzner CCX23 box. What to check: - Cloudflare dashboard > Analytics > Cached Requests % — should be > 92% during peak hours. - Per-URL breakdown via the Cloudflare API. Filter to your top 20 product pages by traffic. Any with cache hit < 80%? Investigate. - Common cause: the product page sets a unique cookie per visitor (cart_id, session_id) and your cache rule does not strip cookies before keying. The fix is usually a Cloudflare Page Rule or Cache Rule that says "for /product/*, strip cookies, cache for 4 hours, vary by query string only." The price-display widget on the page can be a separate JSON fetch that hits your origin and is small. ## Check 2: Razorpay Webhook Handler Idempotency Razorpay's official webhooks documentation is explicit: events may be delivered more than once. [The best-practices guide](https://razorpay.com/docs/webhooks/best-practices/) says: build idempotent handlers, dedupe on event id, expect out-of-order delivery, respond 2xx on success. Three failure modes we see most often: How to check today: pull last 7 days of Razorpay webhook logs. Group by event id. Any event id appearing more than once + your DB shows the order processed more than once = leak. Run this query against your audit log table:

SELECT razorpay_event_id, COUNT(*) AS hits
  FROM webhook_audit
  WHERE created_at > NOW() - INTERVAL '7 days'
  GROUP BY razorpay_event_id
  HAVING COUNT(*) > 1;

Anything in the result? That is your leak. ## Check 3: Month-to-Date Reconciliation (DB Vs Razorpay Dashboard) The discipline: every morning at 9 am, your team should compare: - Total Captured This Month from your DB (sum of order amounts where status = paid AND payment_date this month) - Total Captured This Month from Razorpay Dashboard > Reports These two numbers should match within ₹0. If they drift, you have an unreconciled gap somewhere — usually refunds, partial captures, or a webhook that failed. The "8 of 11 had a leak" finding from our recent audits was driven mostly by this check. A typical pattern: a refund processed in Razorpay was not webhook-acknowledged because the handler 500'd that day. The order shows status = paid in your DB; Razorpay shows it as refunded. Net cash impact: missing ₹2,400 to ₹14,000 across 8-30 such transactions per month. The fix is procedural plus technical: - A daily cron at 8 am pulls Razorpay's Settlement API for the previous day, compares against your DB, writes any mismatches to a reconciliation_queue table. - A 9 am email to the finance lead with the queue contents (typically empty; alarming when not). - A weekly review with the founder of any aged-over-7-day items. This pattern catches the leak. Without it, the leak only surfaces at month-end when the bank deposit number does not match the dashboard. ## Check 4: SMS Rate-Limit Tuning Order-confirmation SMS during a sale spike sits in a queue. If your SMS provider (Twilio, MSG91, Gupshup) has a per-second rate cap, queue depth grows, latency creeps up, and order-confirms arrive 4 hours late. Customers panic. Support tickets pile up. What to check: - Your SMS provider's dashboard > rate-limit graph for the sale period (Aug 1-7). Did your queue depth exceed 60 seconds at any point? - Default rate limits: Twilio India long codes ~3 SMS/second; MSG91 transactional ~10/second on the basic plan; Gupshup transactional ~25/second. - Festive D2C peaks can hit 80+ SMS/second on a popular drop. The fixes: - Per-route prioritisation. Order-confirmation SMS goes ahead of marketing SMS. Use separate provider sender IDs. - Provider-side rate increase. A 1-line email to your provider asking for a temporary rate bump — most will lift to 50-100/sec for a day with 24 hours notice. - Batched WhatsApp templates as fallback. WhatsApp Business API is rarely the rate-limit bottleneck. Set up an order-confirm template and route to WhatsApp first, SMS as fallback. ~88% of Indian D2C buyers have WhatsApp; better delivery, lower cost. ## Check 5: GA4 Event Drift Caused by Checkout-Page A/B Tests Most D2C teams run a checkout-page A/B test in the lead-up to a sale. The test changes button text, repositions the trust badges, swaps the upsell offer. The team forgets to update the GA4 event names accordingly. Result: by August 14, your GA4 conversion-funnel report shows mysterious gaps because the new variant fires begin_checkout_v2 while the old fires begin_checkout, and your funnel report aggregates only the latter. What to check: - GA4 > Configure > Events. Look for any event with a v2, _new, _test suffix that has fired > 1,000 times this month. - GA4 > Reports > Conversions. Are your funnel-step counts on the day-after-sale dramatically lower than the cart-add count? - Tag Manager > Versions. Was a new version published in the last 30 days? The fix is usually a 5-minute Tag Manager change to consolidate event names, plus a manual GA4 conversion-event re-mapping. The damage is to your post-sale analysis — you cannot make rational decisions about the next sale if your funnel data is broken. ## The 90-Minute Run-Through (Copy This) Here is the exact run-of-show we use on a client audit. Sequential, no parallelism — this is one engineer at a laptop with a coffee. ## What We Found in the Last 11 Audits The reconciliation drift number is the one that makes founders wince. ₹18,000/month silently leaving the bottom line is a real number. Compounded across an 18-month period it is ₹3.2 lakh. ## When This Audit Will NOT Find Anything Skip the audit if (a) your monthly GMV is under ₹3 lakh — the leaks at that scale are usually under ₹500/month and not worth the engineer time, (b) you do not use a payment gateway and only do COD — most of these checks do not apply, or (c) you have run a daily reconciliation cron for 6+ months with zero findings — your stack is healthy and the next leak will surface from the cron, not from this audit. ## The "Wrong Reactions" We See in the Wild A few common over-reactions worth flagging: - "We will switch payment gateway." Razorpay's webhook spec is fine. Your handler is the issue 90% of the time. Switching to Cashfree or PayU will replicate the same idempotency requirements; the bug will follow you. - "We will move off Cloudflare." Cloudflare is the cheapest and most reliable CDN for Indian D2C. The cache rule is the problem, not the CDN. - "We will hire a DevOps person." Maybe. But the 5 checks above are 90 minutes of work. Run them first; then assess the staffing gap with real data. ## A Real Example: A Bengaluru Beauty Brand A Bengaluru-based beauty D2C brand on Shopify + Razorpay ran the audit on August 11 last year (2024). Findings: - CDN cache hit at 78% — fixed by stripping the cart_id cookie on product pages. - Webhook handler had no idempotency. Found 14 double-processed payment.captured events in the last 30 days, ₹4,200 in over-credited customer wallets. - Reconciliation drift of ₹6,800/month from refunds processed in Razorpay but not webhook-acknowledged. - SMS queue depth peaked at 380 seconds during their July 25 launch — they switched to WhatsApp-first templates with SMS fallback; queue dropped to under 10 seconds during August 5 sale. - GA4 was tracking a deprecated add_to_cart_v3 event; funnel report was 38% under-counted. Total cleanup time: 4.2 hours of our engineering. Estimated annual saving: ₹2.8 lakh on hosting + reconciliation + lost-conversion analytics. ROI on the audit: ~5 weeks. ## A Note on the Razorpay Side [Razorpay's documentation has gotten a lot better in 2024-25](https://razorpay.com/docs/). The webhooks-best-practices page is now the first thing they link to; their settlement API is well-documented; their dashboard shows webhook delivery history. Our typical recommendation: read the docs once carefully when you set up; bookmark the best-practices and settlement pages; run this 5-point check quarterly. ## FAQ ### How often should I run this audit? Quarterly minimum. Monthly during festive season (Aug-Nov). Plus immediately after any deploy that touches the checkout, the webhook handler, or the SMS pipeline. ### Does this audit apply to Stripe or PayU sites? Yes — checks 1, 3, 4, 5 are gateway-agnostic. Check 2 is gateway-specific in the implementation but the principle (idempotent webhook handlers) applies to every gateway. Stripe's docs are explicit on this; PayU's are less so but the same discipline matters. ### What about UPI Autopay subscriptions? Subscriptions add a 6th check we did not include here: the recurring-payment failure rate. Subscriptions on Razorpay can fail for AFA (Additional Factor of Authentication) reasons specific to the buyer's bank. Track the failure rate weekly and alert if it exceeds 8%. ### How do I prevent webhook handler 500s during a peak? Three things. Respond 200 immediately, queue the work asynchronously. Make the handler stateless and horizontally scalable. Set up an alert on handler error rate > 1% so you catch issues before they pile up. ### Can the cache-rule fix break my checkout? No, if you scope the cache rule to /product/* explicitly. Your /cart, /checkout, and /api routes should remain uncached. Test the rule on a staging-mirror first if your site has unusual URL patterns. ### Why do you care about GA4 event drift this much? Because it determines your next-sale planning. If you cannot trust your funnel data, every decision (creative spend, discount depth, inventory positioning) is based on noise. Bad analytics is worse than no analytics — it gives false confidence. ### Do you offer this audit as a service? Yes. Same-day for ₹14,000 fixed. We send the findings as a written report plus a Loom walk-through. If we find nothing, you pay half. The full pricing and process is on our [services page](/services/web-development). ## Related Reading