GDPR-Compliant Webshop Development: What It Actually Requires
What GDPR compliance really means for a webshop: consent, data mapping, EU hosting, payment data, and how to build it right from the start.
A GDPR-compliant webshop needs five things built into it, not bolted on: a lawful basis for every piece of personal data it collects, a consent mechanism that blocks non-essential cookies and scripts until the customer agrees, data processing agreements with every third-party service that touches customer data, a way to fulfil data subject rights (access, deletion, portability) without heroics, and infrastructure that keeps personal data inside the EU or under valid transfer safeguards.
Most webshops fail on the second and fifth points. A cookie banner that loads Google and Meta trackers before anyone clicks anything is decoration, not compliance. And a shop hosted on US-controlled cloud infrastructure has a data transfer question its owner usually cannot answer. This article walks through what compliance actually requires when you build or rebuild an online shop — from the perspective of a studio that builds them. It is engineering guidance, not legal advice; for your specific situation, particularly around transfers and special categories of data, talk to a data protection lawyer.
What GDPR-Compliant Webshop Development Means in Practice
A webshop processes more personal data than almost any other type of website: names, addresses, emails, phone numbers, order histories, payment references, and behavioral data from analytics and marketing tools. GDPR applies to all of it, whether you are a sole trader or a multinational, as long as you sell to people in the EU.
Compliance breaks down into decisions made at build time. Here is what each area requires.
Data mapping: know what you collect and why
Before writing code, list every data point the shop collects and assign each a lawful basis. For a webshop, most of it is straightforward:
| Data | Purpose | Typical lawful basis |
|---|---|---|
| Name, address, email | Fulfilling the order | Contract (Art. 6(1)(b)) |
| Order history | Contract, warranty, accounting | Contract / legal obligation |
| Invoice data | Tax law retention | Legal obligation (Art. 6(1)(c)) |
| Marketing emails | Newsletters, abandoned cart | Consent (Art. 6(1)(a)) |
| Analytics, ad pixels | Measurement, retargeting | Consent |
| Account credentials | Customer login | Contract |
Two practical consequences follow. First, checkout must work without consent to marketing — you cannot make “subscribe to our newsletter” a condition of buying. The checkbox must be unticked by default. Second, retention differs by basis: invoices are kept for years because tax law says so (commonly 5–10 years depending on the member state), while marketing data must be deletable on request. Your database schema should reflect that separation, which is exactly the kind of thing that is cheap to design in and expensive to retrofit.
Consent management that actually blocks scripts
The single most common GDPR failure we see in webshop audits is a consent banner that does not do anything. The requirements are concrete:
- Non-essential cookies and third-party scripts (analytics, ad pixels, embedded videos, chat widgets) must not load before consent.
- “Reject” must be as easy as “Accept” — one click, same layer, no dark patterns.
- Consent must be logged: who consented to what, when, via which banner version.
- Consent must be withdrawable as easily as it was given.
Technically, this means script loading is gated by the consent state, not fired on page load and “documented” in a banner. If you view source on your shop and see the Meta pixel in the initial HTML, you have a problem. This applies to fonts and CDNs too: loading Google Fonts directly from Google’s servers transmits visitor IP addresses to a US provider, which a German court in 2022 already found problematic. Self-host your fonts. It is trivial at build time.
Consent mechanics also interact with your marketing performance and SEO — badly implemented banners hurt Core Web Vitals and can block crawlers. We build shops so that the compliant path is also the fast path.
Payment data: keep it out of your hands
Good news: you should never store card numbers, and with a properly integrated payment provider (Stripe, Mollie, Adyen, and similar) you never touch them — the card data goes directly to the PCI-DSS-certified processor. Your GDPR job is narrower: sign a data processing agreement (DPA) with the provider, document them in your privacy policy as a processor, and understand where they process data. European providers like Mollie and Adyen simplify the transfer analysis; US providers rely on transfer mechanisms discussed below.
What you do store — order references, billing addresses, payment status — is ordinary personal data and follows your normal retention rules.
Data subject rights: build the buttons
Customers have the right to access their data, correct it, delete it (within limits — you keep invoices, tax law wins), and export it. GDPR gives you one month to respond. In a well-built shop, this is not a fire drill:
- A customer account page shows and exports the customer’s data (access and portability, mostly solved in one feature).
- Account deletion anonymizes marketing and behavioral data while retaining legally required order records.
- Newsletter unsubscribe works instantly and propagates to your email tool.
If fulfilling a deletion request requires a developer to write SQL by hand across three systems, the shop was not built for GDPR — it was built and then had GDPR apologized onto it.
Hosting and third parties: where the data physically lives
Every service in your stack that touches personal data is a processor: hosting, email delivery, analytics, search, reviews, CRM, helpdesk. Each needs a DPA, and each needs a transfer assessment if it processes data outside the EU.
This is where US cloud services complicate things. Since the CJEU’s Schrems II ruling in 2020 invalidated Privacy Shield, EU–US data transfers have rested on mechanisms that keep getting challenged; the current EU-US Data Privacy Framework (2023) provides an adequacy decision, but it faces ongoing legal contest, and the US CLOUD Act independently allows US authorities to demand data from US-controlled providers regardless of where servers sit. We wrote a full plain-language explainer on this: EU hosting vs US cloud, Schrems II and the CLOUD Act.
Our engineering position is simple: the fewer transfer assessments your shop needs, the more robust it is. We host webshops on EU infrastructure under EU jurisdiction by default, and we prefer European processors (or self-hosted alternatives, like cookieless EU analytics) where they are technically equal. That way your privacy policy describes reality instead of hedging it.
The paperwork the shop must ship with
A compliant build includes documents, and they must match the actual implementation:
- Privacy policy listing every processing activity, every processor, retention periods, and data subject rights — generated from your real data map, not a template with someone else’s tools listed.
- Cookie policy matching what the consent banner actually controls.
- Records of processing activities (Art. 30) — required for most shops in practice, and trivial to produce if you did the data mapping.
- DPAs signed with every processor.
- Depending on your setup: a legal-notice/imprint page where national law requires it, and terms of sale covering EU consumer rights (14-day withdrawal, etc. — adjacent to GDPR but part of the same compliance pass).
What Non-Compliance Costs
GDPR fines scale to €20 million or 4% of global turnover, but for SMB webshops the realistic risks are smaller and more frequent: national data protection authorities routinely fine four and five figures for missing consent, unlawful trackers, or ignored deletion requests, and competitors and consumer organizations in several member states can send costly cease-and-desist letters for visible violations like a broken cookie banner. The cheapest time to fix all of this is while the shop is being built.
Building It Right From the Start
Retrofitting compliance onto a finished shop means auditing every script, renegotiating processors, restructuring data retention, and rewriting policies — typically days of work and some awkward migrations. Building it in from day one costs almost nothing extra, because it is mostly a matter of making the right default choices: EU hosting, gated scripts, self-hosted assets, a schema that separates contract data from marketing data.
That is how we build. Every webshop we deliver ships on EU-hosted infrastructure with a working consent setup, a real data map behind the privacy policy, and data subject rights implemented as features — at our published fixed prices, from €1.000 one-time or €50/month, with larger builds from €2.200 (see pricing). See our webshop development service for what is included, or start with our guide to what websites cost in Europe if you are budgeting the wider project.
If you already run a shop and want to know where you stand, the fastest first step is a self-audit: open your shop in a private browser window, open the network tab, and see which third-party requests fire before you touch the cookie banner. If the answer is more than zero, you know where to start.