Back to the blog

DPDP Stack

Deletion requests: what you can and can't promise a shopper

8 October 2026

Deletion requests: what you can and can't promise a shopper

Sooner or later, a shopper emails or messages asking you to delete their data. Maybe they are closing their account, maybe they read something about data privacy and got cautious, maybe they just do not want you emailing them again. Whatever the reason, the question a merchant has to answer honestly is: what actually happens when I say yes.

The promise that sounds right but is not true

It is tempting to write back something like "done, your data has been deleted everywhere." It feels reassuring and it closes the conversation quickly. It is also not something most D2C stores can honestly say, because of how the data actually lives once it leaves the store's own database.

A shopper's personal data, once collected, is rarely sitting in one place. Their name and email are likely in an ESP like Klaviyo for marketing flows. Their phone number and order status may be in a WhatsApp business provider's system for delivery updates. Their address sat with a 3PL to ship a parcel, possibly more than once. A reviews app may hold their email to send a review request. None of these are under the merchant's direct technical control in the sense of a single delete button that reaches into every one of them at once and wipes the record.

Saying "your data is deleted everywhere" without actually going into each of those tools and removing the record is, in practice, a promise that was not kept. It just was not checked.

What a merchant can honestly promise

What a store can honestly promise is this: the request has been received, it has been logged, and it will be acted on across the store's own tools. That is a true statement and a useful one. The deletion request is recorded the moment it comes in, which matters because the Rules under the DPDP Act allow a response window of up to 90 days for a data principal's request, access, correction, or erasure, and that clock is only meaningful if the request was actually logged with a date rather than handled from memory in a busy week.

What a merchant should not promise is that the request propagates automatically across every connected tool. It does not. Deleting a customer's record from Klaviyo requires actually going into Klaviyo and deleting it. Removing a phone number from a WhatsApp provider's system requires doing that inside that system. A 3PL's shipping record is the 3PL's to remove. Each of these is a separate action, in a separate tool, usually done by the same person who runs the store.

Why the honest version is actually fine

None of this makes a deletion request impossible to honour. It makes it a short list of steps rather than a single switch. A store that records the request the day it arrives, works through its own tools one by one, and confirms back to the shopper once it is done, has done exactly what the Act expects and has not told the shopper anything that was not true.

The dishonest version, the instant blanket promise, is actually the riskier one. It sets an expectation the merchant cannot verify, and if a shopper ever checks, the gap between what was promised and what happened becomes the merchant's problem, not the tool's.

Where the logging actually happens

A deletion request is only as good as the record of when it came in and what was done about it. Consent Jet's fourth function receives shopper requests like this, logs them with a date, and gives the merchant a place to track action against the clock, without ever claiming the deletion itself happens automatically inside tools it does not control.

Deletion requests: what you can and can't promise a shopper | Consent Jet