DPDP for e-commerce
Your entire commercial engine runs on personal data. Browsing history, purchase patterns, payment details, location, behavioural analytics, ad-tech pipelines, loyalty programs, dynamic pricing. DPDP does not shut any of this down. It does force you to earn consent, keep purpose limitation honest, and stop dark patterns.
01Who this covers
Any online business that collects Indian personal data. Including:
- Marketplaces (Amazon, Flipkart, Meesho, Ajio, Nykaa, Snapdeal)
- D2C brands running Shopify, WooCommerce, Magento or custom stacks
- Quick commerce (Blinkit, Zepto, Instamart, BigBasket, Amazon Fresh)
- Food delivery and hyperlocal (Swiggy, Zomato, Dunzo)
- Travel and hospitality booking (MakeMyTrip, Cleartrip, Booking, Airbnb)
- Loyalty programs and coalition schemes
- Payment aggregators and BNPL providers (Razorpay, Simpl, LazyPay)
- Social commerce and creator commerce platforms
02DPDP stacked with dark-pattern rules
You are now regulated by two authorities for the same consent flow. The Data Protection Board under DPDP and the Central Consumer Protection Authority (CCPA) under the Consumer Protection Act 2019.
The CCPA published Guidelines for Prevention and Regulation of Dark Patterns on 30 November 2023. Thirteen specified dark patterns are prohibited: false urgency, basket sneaking, confirm shaming, forced action, subscription trap, interface interference, bait and switch, drip pricing, disguised advertisement, nagging, trick question, SaaS billing, and rogue malware.
DPDP does not name dark patterns but arrives at the same result. A consent obtained through interface interference is not free, specific or unambiguous, so it fails the Sec. 6 standard. Practical result: fixing your consent flow for DPDP compliance almost automatically fixes it for CCPA.
03The checkout and consent patterns that are about to become expensive
Most of the interface patterns Indian e-commerce has been running for the last decade are now problems. Not all of them are DPDP problems, some are CCPA (Consumer Protection Authority) problems. The Board and CCPA have started coordinating, so the two-track risk is real.
Pre-ticked marketing checkboxes at signup. Old habit. Fails Section 6 because there is no clear affirmative action, and CCPA already treats it as interface interference. Drop them.
"Accept all" as a bright button, "Reject all" buried in a nested menu. Fails the free-consent test in Sec 6 and the equivalent-ease withdrawal standard in Sec 6(4). CCPA calls it out separately as an interface-interference dark pattern. The fix is to match the visual weight or make Reject the primary.
Consent bundled across product purposes. One consent for marketing + personalisation + partner sharing + analytics + research fails specific-consent. Break them out. Marketing is not the same purpose as checkout.
Dynamic price based on personal data with no disclosure. Rule 3 requires the notice to state the processing purpose. Silent price personalisation on the same SKU is both a DPDP notice failure and a CCPA bait-and-switch risk. Disclose the practice or stop it.
Withdrawal via email or long forms. If it took one tap to consent, one tap has to be enough to withdraw. Anything else fails Sec 6(4). This is where the most sites will get caught first because the withdrawal UX was an afterthought when the consent UX was designed.
04Personalisation without breaking DPDP
Personalisation remains legal if the personal data used is limited to the specified purpose the Data Principal consented to.
Two paths keep you clean. Path one: use only the data the Data Principal gave for the personalisation purpose. Product recommendations based on the last five products they viewed on your site, in the current session, are fine because the purpose (helping the shopper) is obvious.
Path two: get an explicit, separate Rule 3 notice and Sec. 6 consent for behavioural personalisation across sessions. This is the honest path. The Data Principal knows what is happening and agreed. The consent flow will be longer, but it is defensible.
The path that will fail: silently building behavioural profiles from purchase history, browsing, location, and third-party ad-tech, then using them without disclosure. This fails the specificity and informedness limbs of Sec. 6.
05Children on your platform
If your platform is accessible to under-18s, Section 9(3) bans behavioural monitoring and targeted advertising to them, regardless of consent.
Retail platforms that sell toys, kids' fashion, gaming products, or edu content are the immediate risk. Even general-purpose marketplaces have children browsing. Practical response: run an age-gate on signup, treat under-18 accounts as "no-track, no-target," and switch off retargeting pixels on any session your systems flag as a minor.
Rs. 200 crore cap for Sec. 9 breaches. Second-highest under the Schedule.
06Sixty-day e-commerce checklist
-
Redesign checkout consent
Sec. 6 clean, CCPA clean. Separate consent per purpose. Match visual weight for accept and reject.
-
Publish your grievance officer
Sec. 8(9). Rule 3(b)(iii) publication link. Same page must accept DSRs and withdrawals.
-
Age-gate at signup
DOB, not "I confirm I am over 18." Route under-18 accounts to a parental consent flow. Strip trackers and retargeting.
-
Purpose-limit your data flows
Every processor gets only the data category the Data Principal consented to for that purpose. Ad-tech pipelines get consented data only.
-
Publish your retention schedule
Order history 7 years for GST, marketing preferences until withdrawal, browsing analytics 90 days by default.
-
Withdrawal at parity
If consent took one tap, withdrawal takes one tap. If consent is on the app home screen, withdrawal is on the app home screen.