How to Build an E-Commerce App in India: Costs, Timeline and Tech Stack for 2026

┌─────────────────────────────────────────────────────┐
│              MOBILE APP (React Native / Flutter)     │
│         Android (Play Store) + iOS (App Store)       │
└────────────────────┬────────────────────────────────┘
                     │ HTTPS / REST or GraphQL
┌────────────────────▼────────────────────────────────┐
│              API LAYER (Node.js / FastAPI)           │
│         Authentication · Orders · Catalogue API      │
└──────┬──────────────┬───────────────────────────────┘
       │              │
┌──────▼──────┐ ┌─────▼──────────────────────────────┐
│  PostgreSQL │ │  Redis (session cache, cart state)   │
│  (primary   │ │  Cloudflare R2 (product images CDN)  │
│   database) │ └────────────────────────────────────-┘
└──────┬──────┘
       │
┌──────▼──────────────────────────────────────────────┐
│         PAYMENT LAYER                                │
│   Razorpay Orders API + Webhook   │  PhonePe PG      │
└─────────────────────────────────────────────────────┘

Should I build a native app or use React Native / Flutter for an Indian e-commerce app?

For 95% of Indian e-commerce use cases, React Native or Flutter is the right call. Building separate native iOS (Swift) and Android (Kotlin) apps doubles your development cost and creates two codebases to maintain. Cross-platform frameworks have closed the performance gap significantly — the only scenario where native makes sense is if you need deep hardware integration (camera-based AR try-on, for example) that cross-platform SDKs cannot handle.

Can I integrate both Razorpay and PhonePe in the same app?

Yes, and for apps targeting broad Indian audiences, this is often the right approach. You can show Razorpay as the primary payment option and PhonePe as an alternative UPI option within the same checkout flow. Both SDKs can coexist in a React Native or Flutter project without conflicts. Razorpay's standard integration handles UPI, cards, net banking, and wallets natively — so for an MVP, Razorpay alone covers the full payment surface.

How long does Razorpay KYC take for a new Indian startup?

Standard KYC approval for a registered business (Private Limited or LLP) takes 2–5 business days. Sole proprietorships can take 5–10 business days. Apply for your Razorpay account at least 2 weeks before your planned testing phase — not 2 days before launch.

What are the Play Store and App Store submission fees in India?

Google Play Console requires a one-time registration fee of approximately ₹2,100 (USD 25). Apple Developer Program costs ₹7,499 per year (USD 99/year). These fees apply per developer account, not per app. Factor them into your project budget from day one.

Is it possible to build an e-commerce app for under ₹5 lakh in India?

A genuine MVP — product catalogue, cart, Razorpay checkout, and basic order management — can be built in the ₹4–5 lakh range with an experienced cross-platform developer or a small focused agency. Below ₹3 lakh, you are typically looking at a template-based build with limited customisation and no proper QA, which creates technical debt that costs more to fix than the initial saving.

How should an Indian D2C startup structure a custom e-commerce app development budget, and what are the hidden operational costs beyond the initial build?

Building a custom e-commerce MVP in India requires strategic budget allocation. A typical production-grade build divides costs into specific execution phases: UI/UX design (₹80,000 to ₹1,50,000 for comprehensive high-fidelity Figma layouts), frontend mobile client development using React Native or Flutter (₹2,50,000 to ₹5,00,000), backend database and API layer development using Node.js or modern PHP (₹2,00,000 to ₹4,00,000), and rigorous multi-device QA testing on mid-range Android handsets (₹50,000 to ₹1,00,000).

However, the initial build is only the tip of the operational iceberg. Indian startups must account for significant monthly running costs that directly scale with transaction volume:

• Transactional and OTP Communication: User signups and order updates require OTP authentication. Standard SMS gateways (e.g., MSG91 or Kaleyra) charge per SMS, and integrating WhatsApp Business API templates via BSPs like AISensy costs between ₹0.30 and ₹0.72 per message. For 10,000 active monthly users, this totals ₹8,000 to ₹15,000 per month.
• Server Infrastructure and CDN: Managing high-concurrency database queries during sale events requires a relational database like PostgreSQL paired with an in-memory session cache like Redis. Running this architecture on AWS Mumbai or DigitalOcean, backed by a global CDN like Cloudflare to cache high-resolution product images, costs approximately ₹5,000 to ₹15,000 monthly.
• Payment Gateway MDR: While UPI transactions under Razorpay are 0% MDR, debit card, credit card, and corporate wallet transactions carry an average Merchant Discount Rate of 2% + 18% GST. High-average-order-value stores where card payments account for 30% of sales must budget for considerable gateway commissions.
• Ongoing Codebase Maintenance: iOS and Android release major system updates annually, which frequently introduce breaking changes in React Native or Flutter native modules. Securing a monthly technical retainer (₹30,000 to ₹70,000) for security updates, server patches, and payment gateway SDK updates is essential to keep the app operational.

React Native vs. Flutter for e-commerce: Which framework provides better rendering performance on entry-level Android devices using Jio/Airtel 4G networks in India?

In India, the digital retail landscape is unique: over 70% of shoppers use entry-level to mid-range Android devices costing under ₹15,000, powered by lower-tier MediaTek or Snapdragon processors, and connected to highly volatile 4G or 5G cellular networks from Jio and Airtel. A shopping app must render products rapidly without dropping frames during heavy scrolling, while keeping the initial download size small enough to prevent user drop-off.

Flutter offers an outstanding layout and rendering system. Because it compiles directly to native machine code and draws every pixel on the screen using its high-performance Impeller or Skia graphics engine, Flutter completely bypasses the OS platform layout bottlenecks. Complex, nested product layouts, interactive coupon carousels, and image-heavy grids maintain a buttery-smooth 60 FPS even on entry-level hardware during fast scrolling. The core drawback of Flutter is its larger base engine size, which adds an additional 5MB to 8MB to the final APK size. For storage-conscious shoppers in Tier-2 and Tier-3 cities, a larger download can be a high-friction barrier.

React Native approach uses native platform components, bridging JavaScript/TypeScript and the native OS. With the inclusion of the pre-compiled Hermes JS Engine and the modern Fabric Renderer, React Native has drastically reduced startup latency and memory overhead. React Native apps typically result in a smaller initial APK size (~12-15MB fully optimized), which downloads significantly faster on congested rural 4G connections. Additionally, React Native support for Microsoft CodePush allows developers to push instant, over-the-air hotfixes and content updates directly to user devices, completely bypassing the 3-day Google Play Store review cycle. For standard, content-driven e-commerce apps where fast initial download speed and an abundant pool of JavaScript developers are key, React Native is highly recommended; for premium brands requiring elaborate custom micro-interactions and absolute layout consistency, Flutter is the winner.

How do you implement a secure server-side Razorpay or Stripe checkout API integration in a PHP backend to prevent order tampering and handle webhook dropouts?

Relying on the mobile app's frontend client to verify payment status is a catastrophic security vulnerability. An attacker can intercept the client-to-server HTTP request, modify the payload, and send a forged payment success status, resulting in your database marking a tampered order as paid without actual funds being received. A secure transaction flow requires a strict server-to-server handshake.

First, when a user clicks "Proceed to Pay," your mobile client sends a request to your custom PHP API to initialize the checkout. Your server invokes a direct backend call to Razorpay (POST /v1/orders) or Stripe (POST /v1/payment_intents) containing the precise amount and currency. The gateway returns a unique order_id or client secret. Store this identifier in your database associated with the user's cart, locking the payable value. Your frontend SDK then presents the payment interface using this locked ID, preventing the client from altering the price tag.

Second, configure a secure webhook endpoint (webhook.php) in your gateway's dashboard to listen for the payment.captured (Razorpay) or payment_intent.succeeded (Stripe) events. Never trust incoming webhook payloads blindly. You must cryptographically verify the signature transmitted in the request headers (e.g., X-Razorpay-Signature) against your webhook signing secret using HMAC-SHA256.

Here is an enterprise-grade, secure implementation in PHP:

<?php
// SECURE WEBHOOK HANDLER FOR BKB TECHIES E-COMMERCE ENGINES
$webhookSecret = "your_secure_razorpay_webhook_secret_here";
$receivedSignature = $_SERVER['HTTP_X_RAZORPAY_SIGNATURE'] ?? '';
$rawPayload = file_get_contents('php://input');

if (empty($receivedSignature) || empty($rawPayload)) {
    http_response_code(400);
    exit("Bad Request: Missing Signature or Payload.");
}

// Calculate the expected cryptographic HMAC signature
$calculatedSignature = hash_hmac('sha256', $rawPayload, $webhookSecret);

// Use constant-time comparison to prevent timing attacks
if (hash_equals($calculatedSignature, $receivedSignature)) {
    $eventData = json_decode($rawPayload, true);
    $paymentStatus = $eventData['payload']['payment']['entity']['status'];
    $razorpayOrderId = $eventData['payload']['payment']['entity']['order_id'];
    $transactionId = $eventData['payload']['payment']['entity']['id'];

    if ($paymentStatus === 'captured') {
        // Securely update database using PDO prepared statements
        $stmt = $pdo->prepare("UPDATE orders SET payment_status = 'PAID', transaction_id = :tx WHERE gateway_order_id = :order_id AND payment_status = 'PENDING'");
        $stmt->execute([
            ':tx' => $transactionId,
            ':order_id' => $razorpayOrderId
        ]);
        
        http_response_code(200);
        exit("Transaction securely verified and inventory captured.");
    }
} else {
    http_response_code(401);
    exit("Unauthorized: Cryptographic signature mismatch.");
}
?>
  

To handle webhook dropouts due to server timeouts or temporary gateway delays, implement a two-pronged fallback strategy. First, ensure your database table is guarded by an idempotency index so multiple webhook retries do not trigger duplicate order processing. Second, build a daily reconciliation cron script that queries the gateway's API directly for any orders stuck in a PENDING state for more than 30 minutes, ensuring absolute alignment between your cash ledger and inventory records.

What is the precise technical workflow for integrating Delhivery or Shiprocket APIs to automate Indian pincode serviceability checks and shipping label generation?

Indian logistics present specific operational challenges: navigating Cash on Delivery (COD) cash-handling terms, managing regional shipping restrictions across 19,000+ postal pincodes, and avoiding unexpected carrier fees due to inaccurate package dimension measurements. Automating this through a unified API integration like Delhivery or Shiprocket is key to scaling a custom shopping platform.

The technical integration workflow consists of three distinct phases:

1. Pre-Purchase Pincode Serviceability Check: When a user adds an item to their cart and inputs their delivery address, your backend issues a background request to the courier's serviceability API (e.g., GET /v1/external/courier/serviceability/). Pass the source (warehouse) pincode, destination pincode, actual order weight, and order type (Prepaid vs. COD). The API responds with a payload listing serviceable courier partners, estimated delivery dates (EDD), and maximum weight limits. Cache this response in Redis with a short TTL (Time to Live) to prevent cart load-time bottlenecks.
2. Volumetric Weight Calculation & Order Creation: Indian carriers bill shipping fees based on the greater of actual physical weight or volumetric weight. Your CMS must automatically calculate volumetric weight using the standard formula:
   Volumetric Weight (kg) = (Length in cm × Width in cm × Height in cm) / 5000
   Once payment is confirmed, your backend calls the Create Order API (POST /v1/external/orders/create/adhoc) passing client contact details, item SKU dimensions, and payment mode. If successful, the gateway assigns a shipment ID and generates a unique Air Waybill (AWB) number.
3. AWB Booking and Shipping Label PDF Retrieval: Next, call the AWB Assignment endpoint to reserve delivery capacity with the selected carrier. Once locked, call the Label API (POST /v1/external/shipments/print/label/). The carrier returns a URL containing a standard 4x6 thermal barcode shipping label in PDF format. Your warehouse printing station fetches this PDF automatically, outputs the adhesive shipping label containing the AWB barcode, sorting zone, and COD values, and schedules a courier pickup manifest.

How does integrating a WhatsApp-first checkout flow and headless OTP authentication impact custom e-commerce conversion rates and engineering complexity in India?

For Indian consumer brands, friction is the ultimate conversion killer. Standard user registration screens requiring email verification and password creation have abandonment rates exceeding 45% in India, where mobile-first consumers frequently do not actively use personal emails or struggle to recall password credentials. Pivoting to a headless, mobile-first OTP validation flow combined with interactive WhatsApp deep links creates a frictionless path that can elevate checkout conversion rates by 25% to 35%.

The headless OTP authentication protocol operates through a secure, backend-controlled queue. When the user enters their 10-digit phone number, your backend generates a secure 6-digit numeric token using a cryptographically secure random number generator (such as PHP's random_int()). Save this OTP to a fast Redis key-value cache, hashed with a system-wide cryptographic salt, and set to expire in exactly 180 seconds: SET otp:91XXXXXXXXXX "hashed_token" EX 180. Your server then invokes the WhatsApp Cloud API or an SMS broker API to dispatch the OTP message template. The mobile client inputs the code, and the backend verifies the submission using a timing-attack-safe string comparison (hash_equals()). Upon successful match, the backend destroys the Redis cache record and issues a secure, signed JWT token to initiate the mobile user session.

To take user convenience a step further, brands are deploying WhatsApp-first quick checkout buttons directly on product description pages. By clicking "Buy via WhatsApp," the app triggers a deep link (e.g., https://wa.me/91XXXXXXXXXX?text=Order_Product_456) which opens the user's WhatsApp application pre-filled with their cart intent. Furthermore, by linking your store to the WhatsApp Cloud API's catalog features, customers can complete their address entry, select their preferred delivery timeline, and initiate a UPI payment intent within the WhatsApp interface, creating an incredibly seamless checkout experience. However, developers must enforce strict security boundaries, such as tight rate-limiting (e.g., maximum 3 OTP requests per phone number per hour) and IP-based firewalls, to prevent malicious SMS-bombing scripts from exhausting your corporate messaging API budgets.