DPDP Compliance for E-Commerce: Complete Guide to Data Protection for Online Stores
How Indian e-commerce businesses can comply with the DPDP Act — covering consent, cookies, order data retention, deletion requests, and third-party processors.
E-commerce stores process more personal data than almost any other type of business. Names, addresses, phone numbers, email addresses, payment details, browsing behavior, purchase history, device information, location data — the list is long.
Under the DPDP Act, 2023, every piece of that data is regulated. And with penalties reaching Rs 250 Crore, getting compliance wrong is not an option.
This guide covers exactly what e-commerce businesses need to do — from cookie consent on product pages to handling deletion requests for order data, and managing the compliance obligations of third-party processors like Razorpay, Shiprocket, and others.
What E-Commerce Data Falls Under DPDP?
The DPDP Act applies to all “digital personal data” — any data about an individual that is collected or stored in digital form. For e-commerce, this covers virtually everything you handle.
Data Categories in a Typical E-Commerce Business
| Category | Examples | DPDP Relevance |
|---|---|---|
| Identity data | Name, email, phone number, date of birth | Core personal data — consent required |
| Account data | Username, password (hashed), account preferences | Personal data tied to an identifiable individual |
| Address data | Shipping address, billing address, PIN code | Personal data — often shared with logistics partners |
| Payment data | Card numbers (tokenized), UPI IDs, bank details | Sensitive personal data — highest protection level |
| Transaction data | Order history, order values, return records | Personal data with retention implications |
| Behavioral data | Pages viewed, products browsed, time on site, cart activity | Personal data if tied to cookies or user accounts |
| Device data | IP address, browser type, device ID, OS version | Personal data if identifiable (pseudonymized IPs may qualify) |
| Location data | GPS coordinates, city/state from IP geolocation | Personal data — consent required for precise location |
| Communication data | Customer support chat logs, email correspondence | Personal data — retention policies apply |
| Marketing data | Email engagement, SMS opt-in status, ad targeting data | Consent required per purpose |
| Review/UGC data | Product reviews, ratings, uploaded photos | Personal data if tied to an identifiable account |
Data You Might Not Realize Is Covered
- Abandoned cart data: If tied to an email address or cookie, this is personal data
- Wishlist data: Reveals personal preferences and is linked to an account
- Search queries: If logged with a user identifier, these are personal data
- Referral data: “Referred by” records link two identifiable individuals
- Return/refund reasons: May contain personal circumstances or health information
- Customer support transcripts: Often contain names, order numbers, and personal details
Cookie Consent for E-Commerce Product Pages
E-commerce sites are among the heaviest users of cookies and trackers. A typical product page may load:
- Analytics cookies: Google Analytics, Hotjar, Mixpanel
- Advertising cookies: Meta Pixel, Google Ads, affiliate tracking
- Personalization cookies: Product recommendation engines, A/B testing tools
- Session cookies: Cart persistence, login state
- Third-party widgets: Live chat, review platforms, social sharing buttons
What DPDP Requires
Under DPDP, you must:
- Block all non-essential cookies before obtaining consent
- Display a consent banner that clearly explains what cookies are used and why
- Collect separate consent per purpose (analytics, advertising, personalization)
- Allow easy withdrawal of consent at any time
- Not gate the shopping experience behind consent (no cookie walls)
Essential vs Non-Essential Cookies
| Cookie Type | Essential? | Consent Required? |
|---|---|---|
| Session/cart cookies | Yes — site cannot function without them | No (legitimate operation) |
| Authentication cookies | Yes — login depends on them | No (legitimate operation) |
| Security cookies | Yes — CSRF protection, fraud prevention | No (legitimate operation) |
| Payment processing cookies | Yes — required by payment gateway | No (contractual necessity) |
| Analytics cookies | No — site functions without them | Yes |
| Advertising/retargeting cookies | No — not required for shopping | Yes |
| Personalization cookies | No — site works without recommendations | Yes |
| Social media pixels | No — not required for purchase | Yes |
| Affiliate tracking cookies | No — not required for shopping | Yes |
The Product Page Challenge
Product pages are where most e-commerce revenue is generated. They are also where the most trackers fire. The challenge is implementing consent without harming conversion rates.
Practical approach:
- Load only essential cookies on page load (cart, session, security)
- Display a clear, non-intrusive consent banner that does not obscure the product
- Allow browsing without consent — the user should be able to view products, read descriptions, and add items to cart without consenting to analytics or ads
- Fire analytics and ad pixels only after consent — use your CMP’s pre-consent blocking feature
- Position the consent banner thoughtfully — bottom bar or corner widget, not a full-screen overlay that blocks the product image
Impact on Analytics and Ad Tracking
Blocking analytics and ad cookies before consent means you will lose some data. Expect:
- 20-40% drop in analytics data (users who do not consent are not tracked)
- Reduced retargeting audience size (only consented users get pixels)
- Lower attributed conversions (some purchases will not be linked to ad clicks)
This is the trade-off of compliance. Strategies to mitigate it:
- Use server-side analytics where possible (less cookie-dependent)
- Implement consent rate optimization (clear value proposition in your banner)
- Use aggregated/modeled data for reporting where individual tracking is not possible
- Focus on first-party data from logged-in users who have consented
Order Data Retention Rules
E-commerce businesses face a tension: DPDP says minimize data and delete when no longer needed, but tax law, consumer protection law, and accounting standards say keep records for years.
Retention Periods by Data Type
| Data Type | Retention Period | Legal Basis |
|---|---|---|
| Tax invoices and GST records | 7 years from filing date | GST Act, Section 36 |
| Financial transaction records | 8 years | Companies Act, 2013 |
| Payment records | 7 years minimum | Income Tax Act; RBI guidelines |
| Customer identity data | Duration of account + legal retention period | DPDP (retention only while purpose exists) |
| Shipping/delivery records | 2-3 years (for dispute resolution) | Consumer Protection Act, 2019 |
| Customer support logs | 1-2 years after resolution | Reasonable operational need |
| Marketing consent records | 7 years after last interaction | DPDP audit requirements |
| Behavioral/analytics data | No legal retention requirement | Delete when purpose expires |
| Abandoned cart data | 30-90 days recommended | No legal requirement to retain |
| Wishlist data | Duration of account | No retention requirement beyond account life |
The Retention Principle
DPDP Section 8(6) requires that personal data be retained only for the period necessary to fulfill the purpose for which it was collected. Once the purpose is fulfilled, the data must be erased — unless retention is required by another law.
In practice for e-commerce:
- Active order data: Retain while order is being fulfilled
- Completed order data: Retain financial records for 7-8 years (legal obligation), delete non-financial personal details (browsing context, IP address at time of order) once no longer needed
- Account data: Retain while account is active; delete within 30 days of account closure (except legally required records)
- Marketing data: Retain while consent is active; delete upon consent withdrawal
- Behavioral data: Delete after the analytics purpose is fulfilled (typically 13-26 months)
Building a Retention Schedule
Create a formal data retention schedule that maps every data category to:
- Retention period: How long you keep it
- Legal basis: Why you are keeping it (legal obligation, active consent, contractual need)
- Deletion trigger: What event starts the deletion clock (order completion, account closure, consent withdrawal)
- Deletion method: How the data is actually deleted (automated purge, manual review, anonymization)
Document this schedule and make it available for DPB audits.
Customer Data Deletion Requests
When a customer requests data erasure under DPDP Section 13, e-commerce businesses face unique challenges.
The Deletion Dilemma
A customer orders a product, receives it, and then requests all their data be deleted. You want to comply, but:
- GST records for the transaction must be kept for 7 years
- Payment records must be retained under the Income Tax Act
- Delivery proof may be needed for dispute resolution
- Product review they posted is linked to their account
How to Handle It
Step 1: Identify what can be deleted vs what must be retained
| Data | Can Delete? | Reason |
|---|---|---|
| Account profile (name, email, preferences) | Yes | No legal retention requirement |
| Browsing history and behavioral data | Yes | No legal retention requirement |
| Wishlist and cart data | Yes | No legal retention requirement |
| Marketing consent and communication history | Yes | No legal retention requirement |
| Customer support transcripts | Yes (after reasonable period) | No legal retention requirement |
| Order details with financial data | No | GST Act, Income Tax Act |
| Payment transaction records | No | RBI guidelines, Income Tax Act |
| Tax invoices | No | GST Act, Section 36 |
Step 2: Delete what you can, pseudonymize what you must retain
For records that must be retained for legal purposes, you can pseudonymize them:
- Replace the customer name with a hash or pseudonym
- Remove the email address and phone number from the order record
- Retain only the minimum financial data required by law
- Disassociate the order from any browsing or behavioral data
Step 3: Respond to the customer within 7 days
Your response should clearly state:
- What data was deleted
- What data was retained and the specific legal basis
- When the retained data will ultimately be deleted (e.g., 7 years from transaction date)
- How retained data has been pseudonymized to minimize privacy impact
Deletion Across Systems
E-commerce data typically lives in multiple systems:
| System | Data Present | Deletion Action |
|---|---|---|
| Primary database | All customer data | Delete non-retained data, pseudonymize retained data |
| CRM | Customer profile, interaction history | Delete profile, retain pseudonymized transaction records |
| Email marketing platform | Email, name, engagement history | Delete subscriber record |
| Analytics tools | Behavioral data tied to user ID | Delete or anonymize user-level data |
| Customer support tool | Chat logs, ticket history | Delete transcripts |
| Payment gateway | Tokenized payment data | Request deletion from gateway (Razorpay, Stripe, etc.) |
| Logistics platform | Shipping address, delivery records | Request deletion from provider (Shiprocket, Delhivery, etc.) |
| Review platform | Reviews linked to account | Anonymize or delete per platform policy |
| Backup systems | All of the above | Ensure backup purge within defined cycle (30-90 days) |
You must confirm deletion from every system, not just your primary database.
Third-Party Processors: Your Compliance Chain
E-commerce businesses rarely operate alone. You share customer data with a chain of third-party processors (called “Data Processors” under DPDP). Each one creates compliance obligations for you.
Common E-Commerce Data Processors
| Processor | Data Shared | DPDP Requirement |
|---|---|---|
| Razorpay / PayU / Cashfree | Payment details, customer name, email, phone | Data Processor Agreement required |
| Shiprocket / Delhivery / BlueDart | Name, address, phone number, order details | Data Processor Agreement required |
| Google Analytics / Mixpanel | Behavioral data, device data, IP address | Consent required; DPA recommended |
| Meta (Facebook/Instagram Ads) | Email (hashed), behavioral data, purchase events | Consent required; DPA required |
| Mailchimp / Sendinblue / WebEngage | Email, name, purchase history, engagement data | Consent required; DPA required |
| Freshdesk / Zendesk / Intercom | Name, email, chat transcripts, order references | DPA required |
| AWS / GCP / Azure | All data (hosting) | DPA required; data residency terms |
| Shopify / WooCommerce / Magento | All store data (if SaaS-hosted) | DPA required; review platform terms |
| Affiliate networks | Order data, referral data, commission data | DPA required |
| SMS gateways (MSG91, Twilio) | Phone numbers, message content | DPA required |
What Is a Data Processor Agreement?
Under DPDP, when you share personal data with a processor, you must have a written agreement that covers:
- Purpose limitation: The processor can only use data for the specified purpose
- Security obligations: The processor must implement appropriate security safeguards
- Sub-processing: The processor must inform you before engaging sub-processors
- Deletion obligations: The processor must delete data when the processing purpose ends or when you instruct them to
- Breach notification: The processor must notify you immediately of any data breach
- Audit rights: You have the right to audit the processor’s data handling practices
Practical Steps for Processor Compliance
Step 1: Map all your data processors
Create an inventory of every third-party service that receives customer data. For each:
- What data do you share?
- Why do you share it?
- Where does the processor store the data?
- What are the processor’s own privacy and security commitments?
Step 2: Review existing contracts
Many third-party services already have Data Processing Agreements or Data Processing Addendums (DPAs) in their terms of service. Check:
- Razorpay’s DPA: Available in their legal terms
- Shiprocket’s data processing terms: Review their merchant agreement
- Google Analytics: Updated terms include processor commitments for India
- Meta: Data processing terms are available for advertisers
If a processor does not have a DPA, you need to negotiate one or consider switching to a processor that does.
Step 3: Implement data flow controls
- Share only the minimum data necessary for each processor’s function
- Do not share email addresses with logistics providers if phone numbers suffice
- Use tokenized payment data rather than raw card numbers
- Avoid sending full customer profiles to analytics tools — anonymize where possible
Step 4: Monitor processor compliance
- Review processor security practices annually
- Verify that processors delete data when instructed
- Track sub-processor changes (many processors update sub-processor lists periodically)
- Respond to processor breach notifications within the required timeframe
E-Commerce DPDP Compliance Checklist
Use this checklist to assess your current state and track progress toward compliance.
Consent Management
| # | Requirement | Status |
|---|---|---|
| 1.1 | Cookie consent banner deployed on all pages | |
| 1.2 | Non-essential cookies blocked before consent | |
| 1.3 | Separate consent per purpose (analytics, ads, personalization) | |
| 1.4 | Consent banner available in relevant Indian languages | |
| 1.5 | No cookie walls — site is browsable without consent | |
| 1.6 | Easy consent withdrawal mechanism in place | |
| 1.7 | Consent records stored with timestamp and purpose | |
| 1.8 | Email marketing consent collected separately from cookie consent | |
| 1.9 | SMS/WhatsApp marketing consent collected explicitly |
Data Principal Rights
| # | Requirement | Status |
|---|---|---|
| 2.1 | DSR intake form accessible from website and app | |
| 2.2 | Identity verification process for DSR requests | |
| 2.3 | 7-day SLA tracking for all rights requests | |
| 2.4 | Data access response includes all processor disclosures | |
| 2.5 | Correction process covers all data replicas across systems | |
| 2.6 | Erasure process differentiates deletable vs legally retained data | |
| 2.7 | Pseudonymization applied to retained financial records after erasure | |
| 2.8 | Grievance officer designated and contact details published |
Data Retention
| # | Requirement | Status |
|---|---|---|
| 3.1 | Formal data retention schedule documented | |
| 3.2 | Automated deletion for data past retention period | |
| 3.3 | Behavioral/analytics data purged per schedule | |
| 3.4 | Abandoned cart data cleaned up within 30-90 days | |
| 3.5 | Inactive account data handled per policy | |
| 3.6 | Backup systems included in retention/deletion processes |
Third-Party Processors
| # | Requirement | Status |
|---|---|---|
| 4.1 | Complete inventory of all data processors | |
| 4.2 | Data Processor Agreements in place with all processors | |
| 4.3 | Data sharing minimized to what is necessary | |
| 4.4 | Processor deletion requests process documented | |
| 4.5 | Sub-processor changes monitored | |
| 4.6 | Processor breach notification process in place |
Security and Breach Response
| # | Requirement | Status |
|---|---|---|
| 5.1 | Payment data encrypted in transit and at rest | |
| 5.2 | Customer database access restricted by role | |
| 5.3 | Regular security assessments conducted | |
| 5.4 | Breach detection and response plan documented | |
| 5.5 | DPB notification process ready (72-hour window) | |
| 5.6 | Customer notification templates prepared for breach events |
Privacy Documentation
| # | Requirement | Status |
|---|---|---|
| 6.1 | Privacy policy published and accessible | |
| 6.2 | Privacy policy available in relevant Indian languages | |
| 6.3 | Privacy policy covers all data categories and processing purposes | |
| 6.4 | Privacy policy lists all data processor categories | |
| 6.5 | Terms of Service updated to reference DPDP obligations | |
| 6.6 | Privacy policy is separate from Terms of Service |
Platform-Specific Considerations
Shopify Stores
Shopify provides some built-in privacy features (customer data request handling, data deletion API). However:
- Shopify’s built-in cookie consent banner does not meet full DPDP requirements
- You need a third-party CMP for proper pre-consent cookie blocking
- Shopify apps (reviews, loyalty, upsell) each process customer data — review their DPAs
- Shopify stores data on servers outside India — consider data residency implications
WooCommerce / WordPress Stores
WooCommerce gives you more control but more responsibility:
- You manage your own hosting — choose India-based servers for data residency
- WordPress plugins for consent management vary in DPDP readiness
- WooCommerce extensions (payment, shipping, marketing) each need DPA review
- Database-level data deletion requires technical implementation
Custom-Built Stores
If your e-commerce platform is custom-built:
- Privacy by design can be implemented from the ground up
- You have full control over data flows and retention
- However, you bear full responsibility for consent management, DSR handling, and security
- Consider using APIs from dedicated privacy tools rather than building everything in-house
Timeline for E-Commerce DPDP Compliance
| Phase | Timeline | Actions |
|---|---|---|
| Assessment | Now - May 2026 | Map all personal data flows, identify processors, audit current practices |
| Foundation | Jun - Aug 2026 | Deploy CMP, implement cookie blocking, publish updated privacy policy |
| Rights & Retention | Jul - Sep 2026 | Build DSR handling workflow, create retention schedule, set up automated deletion |
| Processor Compliance | Aug - Oct 2026 | Execute DPAs with all processors, minimize data sharing, verify deletion processes |
| Testing & Training | Oct - Dec 2026 | Run mock DSR requests, train customer support on rights handling, test breach response |
| Buffer Period | Jan - Apr 2027 | Collect consent records, resolve gaps, prepare for DPB audit readiness |
| Enforcement | May 13, 2027 | Full compliance required |
Starting now gives you a 12-month runway. Starting in 2027 gives you zero margin for error.
How ZenoComply Helps E-Commerce Businesses
ZenoComply provides a compliance platform built for the specific challenges e-commerce businesses face under DPDP:
- Lightweight consent widget: Designed for product pages — does not slow down your store or obscure product images
- Pre-consent cookie blocking: Stops analytics and ad cookies until the shopper consents
- 22-language consent banners: Serve consent notices in the customer’s preferred language
- DSR management with 7-day SLA tracking: Handle access, correction, and erasure requests with automated timelines
- Processor management: Track which processors have customer data and manage deletion confirmations
- Consent records for 7 years: Auditable records ready for DPB inspection
- Retention schedule tools: Define and enforce data retention policies across data categories
- India-hosted data: Customer consent data stays in India
Whether you are on Shopify, WooCommerce, or a custom platform, ZenoComply integrates with a JavaScript snippet — deploy in minutes, not months.
Running an e-commerce business in India? DPDP compliance is mandatory by May 2027, and e-commerce stores face unique challenges with order data, payment processors, and behavioral tracking. ZenoComply gives you consent management, DSR handling, and processor tracking in one platform — built for online stores, priced for Indian businesses. Start your free trial today and protect your customers and your business.
Check your DPDP compliance now
Free scan. No signup. Results in 60 seconds.
Scan Your Website arrow_forward