TL;DR: Ecommerce platforms selling into India and the EU now have to satisfy three overlapping compliance regimes at once — GDPR's consent and cross-border transfer rules, India's DPDP Act with its significant data fiduciary obligations and 72-hour breach notification, and PCI DSS 4.0.1's tightened checkout script and encryption requirements. Off-the-shelf plugins handle none of these well together, because each regime touches a different layer of the stack: consent management sits in the frontend, data retention and access rights sit in the database and business logic, and payment security sits in the checkout flow. This guide walks through what each regime actually requires for an ecommerce build, where the requirements conflict or overlap, and how to architect a custom platform that satisfies all three without bolting on three separate vendor tools.
Why This Is Now an Architecture Problem, Not a Legal Checkbox
For years, ecommerce compliance meant installing a cookie banner plugin, adding a privacy policy page, and calling it done. That approach no longer survives contact with any of the three major regimes an India-facing or EU-facing ecommerce business is likely to encounter in 2026.
India's average cost of a data breach hit a record ₹25.5 crore in 2026, a 15.9% jump from the year before, with the average breach now exposing close to 39,500 records. Regulators on both sides have also stopped treating enforcement as theoretical: the EDPB's 2026 Coordinated Enforcement Framework specifically targets transparency and information obligations across 25 data protection authorities, and India's Digital Personal Data Protection Act enters its Phase III enforcement window in May 2027 — which means the compliance architecture has to be built now, not when the first notice arrives.
The reason a plugin can't fix this is structural. GDPR's Article 6 consent requirements, DPDP's purpose-limitation and retention rules, and PCI DSS 4.0.1's script-inventory requirement for payment pages all reach into different parts of the same checkout flow. A consent management platform bolted onto WooCommerce can block a tracking cookie, but it can't tell your order database to purge a customer's data after your retention window closes, and it has no visibility into whether a third-party script on your payment page has been tampered with. Those are backend and infrastructure decisions — which is exactly why compliance for a serious ecommerce platform has become an engineering problem that sits squarely inside custom software development, not a marketing-team task.
GDPR: What Actually Applies to Ecommerce Checkout and Data Flows
If your ecommerce platform serves EU customers — even a handful, even through an affiliate or dropshipping arrangement — GDPR applies regardless of where your company is headquartered.
Consent has to be granular, not bundled
Cookie consent must be obtained before setting non-essential cookies, and pre-ticked boxes or "browsing equals consent" language do not comply with the CJEU's Planet49 ruling. For an ecommerce build, this means:
- Consent categories have to be genuinely separable: a customer can accept order-processing cookies while declining analytics and ad-retargeting cookies, and the checkout still has to work.
- Non-essential scripts (retargeting pixels, heatmap tools, A/B testing scripts) must be blocked from firing until consent is explicitly given — not just visually hidden behind a banner while still loading in the background, which is a common failure mode in ecommerce themes.
- Consent timestamps and the specific version of the notice shown need to be logged per customer, because "we had a cookie banner" is not proof of valid consent if a regulator asks for a specific record.
Cross-border data transfers need a documented mechanism
Personal data transferred outside the EEA needs a level of protection comparable to what GDPR guarantees inside it. For a typical ecommerce stack — a payment gateway in one region, a fulfillment partner in another, a customer support tool hosted in a third — this means Standard Contractual Clauses or an adequacy decision have to be in place and documented for every vendor in the data flow, not just the primary hosting provider. This is where custom builds have an advantage over SaaS platforms: you control which vendors touch EU customer data and can architect the data flow to minimize the number of cross-border hops in the first place.
The right to erasure has to reach every table
A customer's right to be forgotten under GDPR doesn't stop at the customers table. It has to cascade to order history (with financial-record retention exceptions handled correctly), abandoned cart data, wishlist entries, review submissions, and any data warehouse or analytics pipeline that ingested a copy. Building this as an afterthought after your schema is already in production is significantly more expensive than designing deletion cascades and anonymization rules into the data model from day one.
India's DPDP Act: The Compliance Layer Most Ecommerce Platforms Are Missing
The Digital Personal Data Protection Act, 2023, together with its 2025 and 2026 Rules, gives India its first comprehensive data protection framework — and it hits ecommerce platforms with obligations that go beyond what most teams have built for.
Consent under DPDP is stricter than most implementations assume
Every business processing personal data of Indian individuals must obtain valid, informed consent before collection, provide a plain-language notice at the point of collection, and honor requests to access, correct, or erase data. Critically, bundled consents covering multiple purposes are not compliant, and using personal data for targeted advertising requires separate, explicit consent from the data principal — the same granularity problem as GDPR, but with India-specific notice-language requirements.
Significant Data Fiduciary status changes the entire compliance posture
Section 5 of the DPDP Act defines a Significant Data Fiduciary (SDF) as an entity that processes personal data at significant volume, uses it for decisions that significantly impact individuals, handles sensitive data categories, or operates critical information infrastructure. While exact numerical thresholds haven't been formally notified for every sector, regulatory guidance points to markers like processing personal data of 50 lakh or more Indian residents or annual revenue above ₹250 crore for private companies — thresholds that a growing D2C brand or marketplace can cross faster than its compliance program matures. Ecommerce platforms and marketplaces are explicitly flagged as likely SDF candidates given the volume of personal data they process daily.
Being classified as an SDF adds real engineering obligations: mandatory Data Protection Officer appointment, Data Protection Impact Assessments before launching new data-processing features, and periodic independent audits. If your platform is anywhere near these thresholds, the architecture needs to support DPIA documentation and audit trails as first-class features, not something assembled retroactively when the notification arrives.
Retention limits and the 72-hour breach clock
As of the 2025 Rules, ecommerce platforms with more than two crore (20 million) registered users face a three-year data retention ceiling, measured from the user's last interaction with the platform — which means your architecture needs an automated purge job, not a manual quarterly cleanup script. Separately, every data fiduciary must notify the Data Protection Board within 72 hours of a breach, and the DPDP Rules set a 90-day window to respond to data principal requests, requiring a documented process, a dedicated intake channel, and clear ownership.
Penalties are not symbolic: DPDP non-compliance penalties start at ₹50 crore and scale up to ₹250 crore per violation, which puts data architecture decisions squarely in front of the board, not just the engineering team.
PCI DSS 4.0.1: Payment Security Requirements That Changed the Checkout Page
PCI DSS 4.0.1, published in June 2024, is now the fully operative standard — every requirement that was previously a "future-dated best practice" became mandatory on March 31, 2025, and 2026 assessments are evaluated against the complete requirement set with no transition relief remaining.
Script inventory is now mandatory, not optional
Requirement 6.4.3 requires a complete inventory of every JavaScript running on the payment page, a documented authorization record for each script, and integrity verification to catch unauthorized changes — a direct response to Magecart-style skimming attacks that inject malicious code into checkout pages via compromised third-party scripts. For an ecommerce site running a dozen marketing pixels, chat widgets, and personalization scripts on the checkout page, this single requirement often forces a redesign of how third-party scripts are loaded and monitored.
SAQ eligibility has tightened
The conditions for using the simpler SAQ A self-assessment have narrowed. If your payment page includes any non-iframe JavaScript that could affect checkout behavior, you may no longer qualify for SAQ A and will need SAQ A-EP or a higher assessment tier — which brings a much larger set of technical controls into scope, including the script inventory and header-monitoring requirements below.
Header monitoring and encryption baselines
Requirement 11.6.1 requires automated detection of unauthorized changes to HTTP security headers and payment page content, with alerting on deviation. Separately, TLS 1.2 or higher is required for all connections carrying cardholder data — TLS 1.0 and 1.1 are explicitly prohibited — and audit logs need to be retained for at least 12 months, with the most recent three months immediately accessible without restoring from backup.
Where the Three Regimes Overlap — and Where They Pull in Different Directions
| Requirement area | GDPR | DPDP Act | PCI DSS 4.0.1 |
|---|---|---|---|
| Consent granularity | Required, purpose-specific | Required, purpose-specific, no bundling | Not applicable (payment processing is a contractual necessity, not consent-based) |
| Data retention | "No longer than necessary" principle | Hard 3-year ceiling for large platforms | 12-month minimum audit log retention |
| Breach notification | 72 hours to the supervisory authority | 72 hours to the Data Protection Board | No fixed clock, but card networks require prompt reporting |
| Third-party script governance | Indirect (via consent for tracking scripts) | Not directly addressed | Explicit requirement (6.4.3) |
| Cross-border data transfer | SCCs or adequacy decision required | Government can restrict transfers to notified countries | Not directly addressed |
| Right to erasure | Full right to be forgotten | Right to correction and erasure, with exceptions | Cardholder data has separate PCI retention/disposal rules |
The overlaps mean a well-architected consent and data-lifecycle layer serves both GDPR and DPDP with shared logic. The friction point is retention: PCI DSS wants payment-related audit logs kept for 12 months minimum, while GDPR and DPDP both push toward minimal retention — which means your architecture needs to separate "cardholder-adjacent audit data" (kept for PCI reasons, access-restricted) from "personal data used for service delivery" (subject to the shorter privacy-driven retention windows), rather than treating all customer data as one retention pool.
A Practical Compliance Checklist for Custom Ecommerce Builds
- Consent layer: Granular, purpose-specific consent categories with per-customer timestamp and notice-version logging; scripts blocked pre-consent, not just hidden.
- Data mapping: A living data flow diagram covering every vendor and sub-processor that touches customer data, including cross-border transfers, updated whenever a new integration is added.
- Deletion cascades: Automated purge and anonymization logic that reaches order history, cart data, reviews, and analytics exports — not just the primary customer record.
- SDF readiness: DPIA templates and audit-trail logging built into any feature that processes personal data at scale, even before you're formally notified as a Significant Data Fiduciary.
- Breach response: A documented, tested incident response runbook with the 72-hour regulatory clock built into the escalation process, not discovered during an actual incident.
- Payment page script governance: A maintained inventory of every script on the checkout page, with change-detection alerting per PCI DSS 6.4.3 and 11.6.1.
- TLS and encryption baseline: TLS 1.2+ enforced everywhere cardholder data moves, with older protocols disabled at the load balancer, not just the application layer.
- Segregated audit retention: PCI-driven audit logs kept separately from privacy-driven personal data, each on its own retention and access-control policy.
Build vs. Buy: Where Plugins Fall Short
Consent management platforms, PCI-compliant payment gateways, and DPDP compliance SaaS tools all solve one slice of this problem well. The gap appears at the integration points: a consent platform doesn't know your database schema well enough to cascade a deletion request, a payment gateway's PCI compliance doesn't extend to the marketing scripts your team adds to the checkout page next quarter, and a generic DPDP compliance tool can't enforce your specific data retention rules inside your order-management logic.
This is the case for treating compliance as part of the core platform architecture rather than a set of bolted-on tools: the underlying data model, the API integrations connecting payment, fulfillment, and analytics vendors, and the audit logging all need to be designed together so that a change in one regulation doesn't require re-engineering three separate vendor integrations. Ecommerce platforms that get this right at the schema and API-integration layer usually spend less over three years than those retrofitting compliance onto commodity plugins piece by piece.
Getting the Architecture Right the First Time
Treating GDPR, DPDP, and PCI DSS compliance as three separate checklists leads to duplicated consent logic, inconsistent retention rules, and gaps at the exact integration points regulators and attackers both target. The teams that handle this well design the consent layer, data lifecycle, and payment security controls as one system from the start, with the API integrations between payment gateways, fulfillment partners, and analytics tools built to respect the same rules everywhere.
If you're scoping a new ecommerce platform or auditing an existing one against these three regimes, Syslabs works with ecommerce platforms and marketplaces on exactly this kind of compliance-by-architecture build, through both compliance and risk consulting engagements and full custom software development. Reach out for a working session on where your current stack has gaps.
Sources: CookieYes DPDP Act guide, Levo.ai DPDP 2026 handbook, IBM Cost of a Data Breach Report 2026 (India), UpGuard PCI DSS 4.0.1 compliance guide, DPDPA.com Significant Data Fiduciary guide, Gelato Ecommerce and GDPR Compliance 2026 guide.