DPDP Compliance for E-Commerce Platforms: Checkout, Returns and Loyalty Data

A single checkout flow typically gathers a phone number, a delivery address, an email, and payment instrument details, and often a GST number for business buyers. Guest checkout does not remove the obligation to give notice under Section 5 before that data is used; it only removes the account. The itemised notice needs to say plainly what is collected, why, and who it goes to, not bury it in a fifty-clause policy linked from a footer.

Payment data is rarely stored by the platform itself; it usually passes through a payment gateway or aggregator acting as a data processor. That relationship needs a written contract under Section 8(2) before any card or UPI data reaches the gateway, and the platform stays accountable to the customer even though the gateway does the actual processing. Saved cards and one-click checkout tokens deserve their own consent line, separate from the general checkout consent, since they persist well beyond a single transaction.

A return generates its own data set: photos of the defective item, refund bank details, pickup address confirmation, and often a recorded reason code that feeds fraud-detection models used to flag serial returners. That fraud score is a decision that affects the data principal, so Section 8(3)'s accuracy requirement applies squarely — a wrongly flagged customer should be able to ask what data fed that score and have it corrected.

Refund processing frequently routes through a different vendor than the original payment gateway, and reverse-logistics partners handling pickup add a third party into the chain. Each of those handoffs needs to sit inside a processor contract, and the platform's notice should mention returns processing as a purpose, not just checkout.

Loyalty and rewards programs stitch together purchase history, browsing behaviour, and sometimes location data to build a spending profile used for personalised offers. That profiling is a distinct purpose from fulfilling an order, and consent obtained at checkout for order processing does not stretch to cover it. A separate, specific consent for marketing and profiling — with an equally easy withdrawal path — is what Section 6 requires.

Loyalty points and tier status often get shared with co-brand partners (a card issuer, a travel partner, an airline programme). Each of those is a new disclosure that the original notice should have flagged, and each partner relationship should be documented, whether the partner is acting as a joint fiduciary or as a processor receiving data solely to administer the co-branded benefit.

E-commerce platforms accumulate large numbers of dormant accounts — carts abandoned years ago, one-time buyers who never returned. The Rules contemplate erasure of personal data tied to inactive accounts after a defined period of inactivity, with a prior notice period before deletion, so a platform needs a working definition of dormancy and a scheduled sweep rather than indefinite retention on the theory that the data might be useful someday.

Order records that feed statutory requirements — tax invoices, warranty registers — can be retained under the applicable legal-compliance ground even after account deletion, but that retention should be scoped narrowly to what the law actually requires, not the entire purchase history.

Use the Data Flow Mapper to trace how a single order moves from checkout through the payment gateway, warehouse, courier, and returns desk, and flag each hop that needs its own processor contract or notice line. Then run the Consent Notice Builder to produce separate, specific consent language for checkout, marketing, and loyalty profiling instead of one blanket clause.