DPDPA Compliance for E-commerce in India: A Practical Playbook

The Hidden Data Trail Behind Every Online Order

An individual order triggers an invisible flow of data that teams seldom visualize completely. The personal information, such as the name, telephone number, shipping address, and payment method entered by the customer while making an online purchase does not remain static. It travels from the store to the payment gateway to the order management system and further into the tracker of the logistic company and perhaps into a marketing tool.

DPDPA compliance for e-commerce in India starts with recognizing this spread. A retailer that describes its data collection as "name, email, phone, address" is usually looking at the checkout form alone. The technology stack behind that form typically touches a dozen or more categories of personal data across five or six connected systems before a single order ships.

As per the provisions of Digital Personal Data Protection Act, 2023 (DPDPA), all online retailers who collect data from customers are Data Fiduciaries, who take the responsibility of deciding the reason and manner of processing of personal data. The customer here would be the Data Principal, and as per the Act, he or she has some specified rights, i.e., right to know about the processing of his or her data, right of access, and right to withdraw consent for any particular purpose. If an organization is not able to prove valid and purpose-specific consent for any particular purpose, the same shall be treated as unauthorized use of personal data.

Most D2C or marketplace-based e-commerce businesses have a different perspective towards consent management in such cases. This guidebook provides insight into how this process can be mapped and what technical steps should be taken at each stage.

When These Obligations Take Effect

The DPDPA rules were notified through gazette notification G.S.R. 846(E) on November 13, 2025. The provisions for Consent Managers, the registered entities that will operate under Rule 4 of the Act, take effect from November 13, 2026. Core operational obligations for Data Fiduciaries, including consent notice requirements, data security safeguards, and breach reporting, take effect from May 13, 2027. Businesses that build their consent architecture ahead of these dates are positioned to adapt smoothly as each phase of the rules comes into force. Starting this work early also spreads the technical and process changes across a longer runway, ahead of the compliance deadlines.

Where Consent Needs to Be Captured Across the Customer Journey

Under the DPDPA, a single consent checkbox saying “I agree” covering multiple purposes is not sufficient to establish valid consent. Section 6 of the Act requires consent that is free, specific, informed, unconditional, and unambiguous, and tied to a defined purpose. In e-commerce, that standard translates into treating consent as something collected at several distinct moments in the customer journey, not once at account signup.

Mapping a storefront against the moments below is a useful starting point for any e-commerce team looking at its current consent flows.

Checkout

• Order-processing data (name, address, payment details) is treated as necessary for fulfilling the transaction, separate from marketing consent

• Marketing consent (email, SMS, or WhatsApp promotions) is captured through its own opt-in checkbox, left unticked by default

• Third-party data sharing, covering ad networks, analytics platforms, and affiliate tools, has its own distinct consent, stated directly on the checkout page as a separate item from the general privacy policy link

• Guest checkout customers are added to marketing lists only when they actively opt in

Account Creation

• Sign-up flows separate data required for the account (email, password) from optional data (birthday, gender, preferences)

• Consent language names the specific purpose in direct terms, for example "order updates" or "promotional offers." A general phrase such as "improve your experience" does not meet this standard

• Each consent event is logged with a timestamp, the version of the notice shown at the time, and the method of capture, since this record is the evidence, a business would present if the Data Protection Board raised a query

Cart Abandonment and Behavioural Emails

• A clear line separates transactional nudges, which help a customer complete a purchase already in progress, from marketing-style re-engagement

• Cart abandonment emails sent to customers who have not opted into marketing stay scoped to the items already in the cart, without introducing cross-sell content

• Browse abandonment and personalized recommendation emails depend on behavioural tracking. These require explicit marketing or analytics consent, since they fall outside the service-necessary basis used for order-related communication

Other Moments That Need Their Own Consent

• WhatsApp and SMS order updates run on a different consent basis than WhatsApp or SMS marketing broadcasts

• Post-purchase review requests and referral prompts carry their own consent trail

• Customer support chat logs and call recordings sit under a separate, stated purpose

A single blended consent checkbox covering several of these moments at once is one of the more common gaps in e-commerce consent design, since checkout, marketing, and third-party sharing each call for a distinct legal basis under the Act.

Building Granular Consent into the Backend

The moments mapped above depend on a backend that can enforce each one on its own terms. A single combined yes or no toggle cannot represent five different legal bases operating at once. A structured consent management platform addresses this by functioning as part of the operational design, built into the stack from the start.

Granular consent means each category of processing exists as its own independently trackable record:

• Marketing: email, SMS, WhatsApp, and push notifications, with each channel potentially needing its own toggle depending on channel-specific regulatory requirements

• Analytics: behavioural tracking, personalization engines, and product recommendation algorithms

• Third-party sharing: ad networks, affiliate partners, logistics providers, and payment processors receiving data beyond what fulfilling the transaction requires

For this structure to hold up on a live storefront, the underlying system needs four technical properties:

1. Purpose-tagged storage. Every stored data point links to the specific purpose it was collected for, instead of sitting inside one general "customer record."

2. Independent revocability. A customer can turn off marketing consent while leaving analytics or transactional consent untouched, and the system reflects that change immediately.

3. Machine-readable consent status. Every downstream system, including the CRM, marketing automation tool, ad pixel, and CDP, can query current consent status through an API before triggering an action, instead of relying on a periodic export.

4. Auditable history. A complete timeline records what was consented to, when, under which version of the notice, and when it was withdrawn, if applicable.

This is the function a consent management platform performs. For a broader look at why businesses are moving towards structured consent governance, read our guide on why consent management is becoming a business priority under the DPDP Act.
Engineering teams building purpose-tagging and revocation logic separately inside every tool that touches customer data face a heavier build. A CMP acts as the single reference point every connected system checks against, spanning the website, app, CRM, and marketing stack.

What Happens to Order Data When a Customer Withdraws Consent?

Consent withdrawal needs to be managed at the purpose level rather than as a single on-off switch. For example, withdrawing consent for marketing should update that specific permission without automatically affecting other processing activities associated with an active order, return, or service request.

A consent architecture built around a single customer-level consent flag can create gaps across connected systems. A withdrawal may fail to reach the marketing platform, or it may suppress communications unrelated to the consent being withdrawn.

A purpose-based consent model avoids this by ensuring that:

• The relevant consent category is updated independently.

• The change is propagated across connected systems.

• Other consent categories and customer records remain unaffected.

• The withdrawal event is recorded as part of the audit trail.

Consent Gaps That Tend to Show Up in E-commerce

The patterns below show up often when checkout, marketing, and CRM systems have grown separately over time, sometimes added by different teams at different stages of the business. Comparing them against a current setup is one way to spot where the consent design might benefit from tightening.

• One consent checkbox covering order processing, marketing, and third-party sharing together, when the Act calls for each to have its own basis

• Marketing opt-ins pre-ticked at checkout or sign-up, where DPDPA requires an affirmative, active choice from the customer

• Consent changes that do not sync to every connected tool, so a withdrawal recorded in the CRM does not reach the ad pixel or the email platform

• No re-consent flow when a new purpose is introduced, for example a new personalization feature that was not covered by the original notice

• Guest checkout customers added to marketing lists because their email was captured during payment, without an active opt-in

• No documented consent trail available for a given customer, including timestamp, notice version, and method of capture

• The privacy policy footer link treated as the consent mechanism itself, when the Act calls for consent that is specific to each purpose

• No defined process for consent withdrawal requests, leading to manual handoffs between customer service and engineering without a service-level timeline

Each of them can be solved independently of a platform migration.

Solving them beforehand, while the number of orders and integrations remains manageable, usually turns out to be an easier task than going back through all the orders, campaigns, and integrations after the business has already grown further.

How OneConsent Supports This Approach

Purpose-specific checkout consent, granular categories, real-time withdrawal propagation, and audit-ready records together describe a connected system. OneConsent by Easyrewardz was built to provide that system for Indian e-commerce and retail businesses.

A few specifics worth knowing when evaluating how to put this approach into practice:

• Purpose-level consent capture. OneConsent records permissions for marketing, transactions, and service communications as distinct, independently manageable consents, so the moments mapped earlier in this guide reflect how the system is built and enforced, extending beyond a policy document.

• Real-time enforcement across channels. Consent status is checked through APIs and webhooks before a campaign or message goes out, so a withdrawal is enforced against live sends, addressing the withdrawal scenario covered above.

• CDP-integrated design. OneConsent operates within the customer data platform layer, allowing consent status to propagate across website, app, CRM, POS, and marketing automation without a separate sync process.

• OTP-backed validation and unified audit trails. Every consent event is recorded with a verifiable trail, which supports a business that needs to demonstrate valid consent to the Data Protection Board.

• Coverage of the full data lifecycle. OneConsent supports data principal rights under DPDPA, including erasure and anonymization requests with safeguards against accidental loss of order history or loyalty benefits, alongside a structured grievance-handling process with defined service-level timelines.

• Built on established retail-scale infrastructure. Easyrewardz, the company behind OneConsent, has worked with client engagements spanning more than 250 brands and 10,000 stores across retail, D2C, BFSI, and other sectors, and holds ISO/IEC 27001:2022 certification for information security, ISO/IEC 27701:2019 for privacy information management, and PCI-DSS certification for payment data handling.

This approach allows an e-commerce team to avoid building purpose-tagging, revocation logic, and cross-system propagation separately inside every tool in its stack.
OneConsent functions as the consent layer that the storefront, CRM, and marketing tools check against, addressing most of the patterns covered in the earlier section.

Book a demo to see how OneConsent can support consent management across your e-commerce data and customer journey.

Start With a DPDPA Readiness Assessment

Many of the compliance gaps covered in this guide become visible only when businesses take a structured look at how personal data is collected, used, shared, and governed across the customer journey.
A practical starting point is the OneConsent DPDPA Readiness Framework, designed to help organisations assess their current level of preparedness across key areas such as data discovery, privacy governance, consent and preference management, Data Principal rights, security, third-party compliance, and internal training.

Use the framework to identify gaps, prioritise actions, and build a clear path towards DPDPA readiness.

Explore the DPDPA Readiness Framework