DPDP-Compliant Lead Capture: What Your QR Code Consent Screen Must Say

India's Digital Personal Data Protection Act sets a specific, testable bar for what counts as valid consent: it must be free, specific, informed, unconditional, and unambiguous, given through a clear affirmative action. A pre-ticked checkbox, a consent bundled in with an unrelated permission, or consent merely implied from someone continuing to use a service all fail that bar. For a business capturing phone numbers and emails through a QR code — often the single largest ongoing source of new personal data a small or mid-size business collects — getting this right on the consent screen itself is the cheapest place to fix it, long before a complaint or an audit makes it expensive.

SMLLR's Lead Capture Gate deliberately separates two things that a lot of lead-capture forms blur together: a mandatory contact field required to unlock the QR code's redirect, and a completely separate, unchecked-by-default marketing-consent checkbox underneath it. The contact field isn't consent to be marketed to — it's a functional requirement to continue, the same as typing a password to unlock a phone. Consent to actual marketing outreach is the second, optional element, and it's the one DPDP's rules actually govern. Conflating the two — treating "they gave us their number" as the same thing as "they agreed to be marketed to" — is exactly the kind of bundled, non-specific consent the Act is built to catch.

A pre-checked consent box counts as invalid consent under DPDP regardless of how clearly it's labeled, because it removes the "clear affirmative action" the law requires — someone has to actively opt in, not passively fail to opt out. SMLLR's marketing-consent checkbox on the Lead Capture Gate starts unticked on every single scan, with no way to configure it otherwise, and the redirect fires identically whether it's checked or not — so there's never a scenario where a business is tempted to gate the actual destination behind a forced opt-in just to inflate a subscriber count.

"Specific" consent means a person is agreeing to a particular use of their data, not a vague catch-all. SMLLR records consent per purpose — email marketing and ad targeting today, as its own named grant rather than one generic "I agree" toggle. A lead who grants email-marketing consent but never sees an ad-targeting request is only eligible for email campaigns; they don't automatically become eligible for a Meta Sync audience sync just because they ticked one box somewhere. This purpose-level granularity is what lets a business honestly answer "what exactly did this person agree to" for any individual lead, not just "did they agree to something."

Beyond capturing consent correctly, DPDP-minded practice means being able to prove what was captured and when. Every consent grant through SMLLR's gate is stored as its own append-only entry — the exact wording shown to the person at that moment, a timestamp, and the IP address — and it's never edited after the fact. If a lead later withdraws consent, that's recorded as a new entry superseding the old one, not a silent deletion of the original grant. This matters because "informed" consent under DPDP means the person has to have actually seen specific wording, not a wording that was quietly changed after the fact and retroactively applied to consents captured under an earlier version.

Businesses that already had a customer list before adopting SMLLR — from a previous system, an offline register, or a different tool entirely — aren't automatically compliant just because the people on that list are real, existing customers. CSV import lets a business explicitly attest that pre-existing consent genuinely exists for a given batch, timestamping and IP-stamping that attestation on the business's own liability, rather than defaulting every imported contact to zero consent regardless of what permission may have already existed. That attestation is a business decision with real accountability attached to it — it's not a way to bypass DPDP's requirements, it's a way to accurately record consent a business is confident it already legitimately has.

As of 2026, registration for the DPDP Act's consent-manager framework opens in November, with the Act's substantive provisions — consent requirements, privacy notice obligations, and security safeguards — becoming fully effective in May 2027. That timeline is not a reason to wait: the definition of valid consent isn't new or ambiguous, and building a lead-capture flow around unchecked-by-default, purpose-specific, auditable consent from day one costs nothing extra compared to building it the wrong way first and having to retrofit it later.