'India e-commerce' collapses three shapes — D2C, marketplace (Amazon/Flipkart), social. Each needs a different WhatsApp workflow.
A D2C brand running its own Shopify India store, WooCommerce site, Instamojo or Dukaan storefront owns the customer relationship end-to-end. Order data, contact details, payment history, browsing behaviour, and post-purchase interactions all sit under the brand's own data-controller role. WhatsApp automation on this shape has the widest legitimate surface: pre-purchase enquiry response, cart-abandonment recovery, order confirmation with GST-compliant invoice attachment, dispatch and delivery updates from courier webhooks (Delhivery, Shiprocket, Xpressbees, Bluedart, Ecom Express), post-delivery review request, and re-engagement flows for lapsed customers. The templates fall predominantly into Meta's utility category (which is cheaper and pass-classifier-consistent) with marketing templates reserved for consented promotional sends. Because the D2C brand is the personal information fiduciary under the DPDPA 2023, the marketing-consent flag has to be captured at the point personal data is collected — typically at checkout or newsletter signup — and respected by the automation at send time. What automation genuinely moves on this shape: cart-abandonment recovery (industry data across markets consistently shows a measurable share of abandoned carts recovered by a well-timed reminder), first-purchase-to-second-purchase conversion (a post-delivery follow-up with a related-product suggestion), and average-order-value on repeat customers (curated re-engagement sequences based on prior purchase history). What it does not move: acquisition cost, the underlying product-market fit of the offering, or the operational cost of fulfillment.
A seller on a marketplace platform operates under that platform's Marketplace Services Agreement or equivalent. Two structural constraints that fundamentally change what a WhatsApp automation can and cannot do. First, buyer contact ownership: the marketplace owns the buyer relationship and typically restricts the seller's contact with the buyer to platform-mediated channels. Amazon India's Seller Central policies explicitly prohibit contacting buyers outside Amazon for anything other than order fulfillment and require that direct-marketing solicitations to Amazon buyers not occur through channels acquired from the marketplace. Flipkart's Marketplace Seller Terms carry equivalent restrictions. Sellers who scrape buyer contact details from marketplace orders and add them to a WhatsApp marketing list are in policy violation, and account suspension is a routine enforcement outcome. Second, buyer-communication surface: legitimate seller-buyer messages happen inside the marketplace's own Buyer-Seller Messaging feature, not on WhatsApp. WhatsApp automation for a marketplace seller therefore looks different: internal operations (inventory alerts to the seller's own team, courier-status webhooks into an internal fulfillment WhatsApp thread, low-stock alerts, return-merchandise-authorisation workflow), plus off-marketplace channels the seller controls (its own website, its own social channels), plus any legitimate D2C customer base built independently of the marketplace. What automation should not do: send marketing WhatsApp templates to marketplace-acquired buyers. Meesho is a partial exception to this pattern — Meesho's reseller model deliberately routes seller-buyer interactions through WhatsApp, and the platform's terms are structured around that. Read each marketplace's current seller terms before designing the workflow.
Social commerce in India — Instagram Shops, Meta Shops linked to a Facebook Page, and WhatsApp's own catalog and cart feature — treats WhatsApp as the storefront and checkout surface rather than the post-purchase communication layer. WhatsApp Business Platform's catalog feature lets a seller list products with SKU, price, description, and image inside the WhatsApp interface, add items to a cart, and either check out directly (in markets and product categories where WhatsApp Payments is enabled) or hand off to an external payment link. Meta rolled out WhatsApp Payments in India progressively from 2020 onward under RBI's NPCI-supervised UPI framework, and per-user transaction caps apply. Automation on this shape is fundamentally different from D2C or marketplace: the WhatsApp bot IS the storefront. Templates handle catalog browsing (product-list carousel messages), inventory queries ('is size M available?'), price negotiation for higher-value items (common in B2B social-commerce categories like textiles and imitation jewelry), payment-link dispatch (via Razorpay, Cashfree, PayU, or WhatsApp Payments where enabled), and dispatch-and-delivery updates. Product categories where this shape dominates: fashion resale, jewelry, home decor, wedding services, and food (particularly local Indian sweets, dry fruits, and specialty items where reputation-and-relationship matter more than search-and-compare).
Three rails apply regardless of channel shape and were covered in more depth in the India Shopify piece; here they surface with their channel-specific implications. DPDPA 2023 (personal-data processing): D2C brands are the fiduciary end-to-end; marketplace sellers process only what the marketplace shares; social-commerce operators process what customers enter into the WhatsApp conversation. The consent architecture and Data Processing Agreement obligations differ by role but the underlying Act is the same. GST e-invoicing (mandatory for aggregate turnover above ₹5 crore since 1 August 2023 per CBIC Notification 10/2023): the IRN-and-QR handoff to an IRP-registered invoicing tool (Zoho Books, ClearTax, TallyPrime, Vyapar) is required regardless of channel; the WhatsApp automation delivers the invoice, it does not generate the IRN. RBI PA/PG framework: payment aggregators (Razorpay, Cashfree, PayU, Instamojo, PhonePe for Business) must be RBI-authorised, and the WhatsApp automation dispatches links to a licensed PA — it does not hold funds. For social commerce specifically, WhatsApp Payments (where available for the seller's category and region) operates on the NPCI UPI rail under RBI supervision, with per-user monthly transaction caps that Meta publishes and updates. For D2C and marketplace-adjacent operations, the payment step almost always routes through a separate PA, not through WhatsApp itself.
For a D2C brand: WhatsApp Business Platform via a Meta-approved BSP for the pre-purchase, order-confirmation, dispatch-update, and post-delivery-review templates; utility category for transactional templates and marketing category (with consent flag) for promotional sends; IRP-registered invoicing tool integrated with Shopify or WooCommerce for GST e-invoicing above ₹5 crore turnover; RBI-authorised PA for the payment step. For a marketplace seller: WhatsApp Business Platform for internal operations and courier-status workflows (do not use it for marketing to marketplace-acquired buyers); marketplace's own Buyer-Seller Messaging for legitimate buyer contact; the marketplace's own invoicing rail (which is where the tax-invoice flow sits, since the marketplace is the entity generating the invoice for most transactions); RBI-authorised PA where the seller runs any independent D2C channel outside the marketplace. For a social-commerce operator: WhatsApp Business Platform with catalog and cart features enabled; product-list templates and payment-link dispatch; RBI-authorised PA for the payment step (or WhatsApp Payments where enabled for the seller's category); manual GST invoicing (via the invoicing tool) below the e-invoicing threshold, or integrated e-invoicing above it. In all three shapes the DPDPA consent architecture is the underlying compliance rail. Trying to run one shape on another shape's automation is the source of the majority of vendor-selection frustrations and, in the marketplace case, of policy violations that lead to account suspension.
Given the shape-first framing, the BSP-selection questions become concrete. Does the vendor's product surface understand the three channel shapes (or does it treat all e-commerce identically, which is a warning sign)? Does the DPA map explicitly to DPDPA 2023 and the January 2025 draft Rules, not only to GDPR? Does it integrate natively with the payment aggregators the seller actually uses (Razorpay, Cashfree, PayU) rather than requiring custom webhook development? Does it hand off cleanly to the invoicing tool (Zoho Books, ClearTax, TallyPrime, Vyapar) that produces IRN-registered invoices, rather than trying to generate invoices itself (which it should not)? Does it support the catalog and cart templates for social-commerce operators who need WhatsApp as the storefront surface? Does the pricing model — per-seat, per-conversation, per-MAU, or hybrid — match the shape's workflow economics? For a D2C brand with high inbound volume and multiple support agents, a per-seat model may be cheaper; for a social-commerce operator with lower agent count but high catalog-browse conversation volume, a per-conversation model may be cheaper. The right vendor is not the one with the longest feature list; it is the one whose specific product decisions align with the shape's actual workflow.
Data + numbers referenced in this article are sourced from these public documents:
BossBot supports the D2C funnel workflow on Shopify/WooCommerce, the marketplace-adjacent internal-operations workflow, and the social-commerce catalog-plus-payment-link flow — three shapes, one platform, defensibly separated.
See BossBot for Indian e-commerceNot ready to sign up yet? Try the free demo →