GDPR checkout for Slovenian e-commerce : what actually needs to happen

A boutique selling natural-fibre clothing got a letter from the Slovenian Information Commissioner (IP-RS) on 14 October 2024. Amount: in the low four figures. The reason wasn’t a missing cookie banner — they had one. The reason was that “Accept all” was a green button 240 pixels wide, while “Reject” was a grey text link 11 pixels tall in the bottom-left corner. Unequal consent entry. GDPR Article 7(3) — read together with ZVOP-2, Slovenia’s national implementation in force since 2 February 2023 — requires that withdrawing consent is no harder than giving it. The regulator applies the same logic to giving consent in the first place.

We’ve seen four similar things this year in our own client base. A hotel had its Stripe merchant account frozen when Stripe’s compliance team couldn’t find a signed 2024 DPA on file — the merchant still had the 2019 version. A winemaker got a warning from IP-RS for storing every customer’s birthday “for a birthday coupon” — legitimate use case, no lawful basis. A bookstore’s erasure request took well over the 30-day window to complete because the built-in WooCommerce tool missed order metadata in three separate systems.

Compliance on a Slovenian WooCommerce checkout in 2026 is no longer “add a banner.” It’s a set of small, boring, technical decisions across seven different systems. This is what they are.

Why “we added a cookie banner” doesn’t cut it

IP-RS has been consistent since ZVOP-2 came into force. A cookie banner is a piece of UI; consent is a legal act. The banner is one piece of evidence that consent was given — it isn’t the consent itself.

What we see in the field:

• The banner covers “analytics cookies” but the site loads a Meta Pixel 200 ms before the banner appears.
• “Accept all” is styled loud, “Customise” is a pale text link.
• No proof of consent stored — no timestamp, no scope of choice, no version hash of the policy that was accepted.
• Cookie policy updated in April 2025 and existing consents from 2023 were never re-collected.

The 2024 IP-RS annual report puts banner-related complaints in the third-largest category, behind marketing emails and workplace CCTV. Fines run from EUR 200 for micro-businesses to EUR 50,000 for medium ones. Not theoretical.

Illustration

Consent: cookies, marketing, analytics

Google Consent Mode v2, mandatory since March 2024 for EEA traffic, forces you to distinguish four consent signals: ad_storage, analytics_storage, ad_user_data, ad_personalization. Older WooCommerce stores still route everything through a single “accept all” flag, and Google Ads campaigns silently underperform because conversion data is throttled.

The four consent tiers you actually need:

1. Strictly necessary cookies — cart, session, CSRF token, payment iframe. No consent required. No toggle.
2. Analytics — GA4, Matomo, Plausible. Opt-in in the EU. Anonymised IPs alone do not remove the consent obligation — the ePrivacy Directive 2002/58/EC governs the read/write to the terminal, not the payload.
3. Marketing and advertising — Meta Pixel, Google Ads conversion tag, Klaviyo tracking. Separate opt-in.
4. Preferences and personalisation — recently-viewed products, saved wishlist. Separate opt-in unless strictly necessary.

Plugin choices we’ve shipped in 2025–2026:

• Complianz Premium (EUR 79/year, 3 sites) — best for shops that need Consent Mode v2 wired out of the box. Fires GTM tags per category on its own.
• Iubenda (EUR 27–99/year depending on tier) — good if the client already uses Iubenda to generate the privacy policy; slightly heavier JS bundle.
• CookieYes (free tier plus EUR 10–55/month for auto-scan) — cheapest, decent UI, weaker on GA4 integration.
• WP Cookie Notice — don’t use for a Slovenian shop; doesn’t log consent proof by default.

IP-RS accepts “prior informed consent” when the store can produce: a timestamp, an IP or user ID, the chosen category, and the version hash of the policy at the time of consent. Complianz stores this natively. Iubenda stores it in its own dashboard. CookieYes needs manual export configuration.

Data minimisation at checkout

The most common Slovenian WooCommerce checkout asks for: name, address, postcode, city, country, phone, email. That’s fine.

What we still see in the wild that shouldn’t be there:

• Date of birth on a normal e-commerce sale
• Gender selector on a clothing store where sizing already tells you the answer
• EMŠO (Slovenian personal identification number) field on a B2C checkout — or as an always-visible field even on B2B
• Davčna številka (VAT ID) as a required field on B2C
• “Company name” as required on a B2C store

GDPR Article 5(1)(c). Data minimisation. Every field on the checkout must have a purpose you can defend. A birthday field “so we can send you a discount” is not a lawful basis unless the customer opts in specifically at the moment they enter the date.

VAT ID handling is the field we most often see done wrong. The rules:

• For B2C, don’t collect it. Ever. There’s no invoicing scenario that requires it.
• For B2B, it’s needed for the invoice under FURS rules and for reverse-charge VAT validation. Store it. Don’t display it in the customer’s account UI without a reason.
• Never send VAT ID to a third party (analytics, marketing) — treat it as a personal identifier.

WooCommerce Germanized and Slovenia-specific WooCommerce plugins toggle these fields conditionally per B2C/B2B. If your checkout still shows davčna številka as an always-visible field, you have a minimisation problem.

Screenshot

The DPA problem

Every processor of personal data that isn’t your own employee is a “processor” under GDPR Article 28. That’s Stripe, PayPal, Pošta Slovenije, GLS, Klaviyo, Google (via GA4), Meta (via Pixel), the hosting provider, and any freelance developer with database access.

Each one needs a signed Data Processing Agreement.

What we most often find during audits:

• No DPA ever signed with Stripe. Stripe’s DPA is auto-accepted by ticking a box during Stripe onboarding, so the merchant assumes it’s handled. It is — but only for the version they accepted. Stripe updated their DPA on 12 September 2023 and again on 4 June 2025. Merchants who onboarded before those dates have an out-of-date agreement.
• PayPal DPA never touched. It’s buried under Legal Agreements and needs manual acceptance.
• Klaviyo — the DPA lives at klaviyo.com/legal/dpa. Sign it. Older accounts pre-2022 don’t have it on file.
• Pošta Slovenije — merchants signed the standard shipping contract but never the DPA (obrazec obravnave osebnih podatkov, updated January 2024). Most Slovenian shops still have the 2021 version.
• The freelance developer who built the shop three years ago and still has SSH access. Almost never has a DPA. Almost always still has the credentials.

The fix isn’t glamorous. Sit down for one afternoon, list every processor, download each current DPA, sign it. Keep the signed PDFs in one folder with the version and date. IP-RS auditors will ask for exactly this folder.

FURS invoicing vs the right to be forgotten

The conflict most Slovenian merchants don’t see coming.

Davčno potrjevanje računov (fiscal receipt confirmation, in force since 2 January 2016) requires every invoice to be transmitted to FURS in real time and retained for 10 years under the VAT Act. GDPR Article 17 gives the customer a right to erasure.

The two rules don’t cancel each other. GDPR Article 17(3)(b) exempts “compliance with a legal obligation” — the 10-year retention wins. But you can’t just refuse the request. You have to:

• Confirm receipt of the request within one month (GDPR Article 12(3))
• Erase everything except what the invoice retention rule keeps
• Explain in the response which specific data is retained, on what legal basis, and for how long
• Restrict the retained data — no longer usable for marketing, analytics, or profiling

IP-RS published guidance on 18 May 2022 specifically on this conflict. The customer keeps their invoice record, but their name, email, and address are removed from Klaviyo, from the GA4 user-ID mapping, from the wp_users table, and from any CRM. Only the invoice PDF and the FURS transmission log remain.

WooCommerce’s built-in personal-data eraser doesn’t do this correctly out of the box. It deletes the user, orphans the invoices, and breaks the FURS trail. You need a custom eraser hook that redacts customer identity from live systems while preserving the invoice PDF as a fiscal document.

Shipping and third-country transfers

When Pošta Slovenije hands your parcel off to DHL for delivery to Serbia, the customer’s name and address just left the EEA. That’s a Chapter V transfer.

For most parcels to EU addresses, this doesn’t matter — Pošta Slovenije keeps the data in-EU. The moment you ship to Serbia, Bosnia, the UK, the US, or route through a DPD Balkan hub in Belgrade, you’re doing an international data transfer.

What needs to be in place:

• The shipping partner’s DPA needs a Standard Contractual Clauses annex (2021 SCC template, Module Two: Controller-to-Processor).
• For the UK: a UK IDTA or an addendum to the EU SCCs.
• For the US: not automatic since Schrems II; either the recipient is Data Privacy Framework-certified, or you use SCCs plus a transfer impact assessment.
• The privacy policy has to name the country and the safeguard.

Aramex, DPD Balkan, and some smaller regional couriers have thin DPAs. Read them. If the DPA doesn’t mention SCCs, don’t ship internationally with them.

Right to be forgotten in WooCommerce

The built-in tool under WooCommerce → Status → Tools → “Remove Personal Data” removes:

• Customer name, email, address on the order (replaced with “Anonymous”)
• User row in wp_users
• Billing and shipping addresses in usermeta

It doesn’t remove:

• The invoice PDF (correct — see FURS above)
• The Stripe customer object on Stripe’s side (needs a Stripe API call; the plugin doesn’t do it)
• Emails in the transactional email log (Mailgun, Postmark, SendGrid)
• The customer’s row in Klaviyo/Mailchimp (needs a separate API call)
• WooCommerce Subscriptions metadata if the customer had a subscription
• Order notes containing the customer’s name, phone, or comments
• Gravity Forms submissions from the contact page

A real right-to-be-forgotten workflow needs a checklist. We use a seven-step one:

1. Run the WooCommerce personal-data eraser
2. API-delete the Stripe customer object
3. API-delete or suppression-list the Klaviyo/Mailchimp profile
4. Delete Mailgun logs older than 30 days for that email
5. Redact order notes (small custom function)
6. Delete Gravity Forms entries from the same email
7. Log the deletion in a compliance ledger (date, requester, systems touched, retained items)

The whole thing in under 30 days. The clock starts when the request lands.

FAQ

Do I need a DPO (data protection officer)? Only if you regularly and systematically monitor data subjects on a large scale, or process special-category data as a core activity. A regular e-commerce shop doesn’t need a DPO. A private clinic selling appointment slots online — yes.

How long can I keep customer data? Marketing consent: as long as it’s valid. Order data: 10 years for the invoice under the VAT Act, 5 years for warranty. Analytics: 14 months in GA4 by default. Marketing engagement logs: as long as the campaign needs them, and no longer than 24 months without re-consent.

Can I email past customers with promotional offers? For existing customers, the “soft opt-in” under Article 13(2) of Directive 2002/58/EC applies — you can email them about similar products or services if they were given a clear opt-out at purchase and every email carries an easy unsubscribe. For non-customers on your list — hard opt-in only. No exception.

Do I need to translate my privacy policy to English if I sell EU-wide? Yes, if you actively target customers in non-Slovene-speaking markets. GDPR requires the notice to be understandable to the audience it’s directed at.

What if a customer asks for all their data (SAR — subject access request)? Reply within one month. Provide it in a common format (JSON, PDF). Include order history, marketing preferences, cookie consent records, chat transcripts if you keep them, and any freeform note the support team wrote about them. Free — no charge for the first request.

Is Klaviyo GDPR-compliant? Klaviyo is EU-adequate as a processor, has a signed DPA available, and the EU region (klaviyo.com/eu) keeps data in Ireland. Klaviyo itself is fine. What most Slovenian shops fail on: importing old customer lists without opt-in evidence, or using Klaviyo’s profile-enrichment features that pull from external sources without a lawful basis.

Do I need to notify IP-RS if there’s a data breach? Within 72 hours of becoming aware, if the breach is likely to result in a risk to rights and freedoms. Yes for a leaked customer database, no for a bruteforce attempt that was blocked. Keep an internal breach register regardless of whether you notify — IP-RS will ask for it during an audit.

GA4 consent — server-side or client-side? Server-side GTM via Consent Mode v2 with basic consent signals is the current best practice. Client-side alone means an ad-blocker or a strict cookie choice throttles your analytics data to zero. Server-side with basic signals gives you modelled conversions while respecting the customer’s choice.

Compliance isn’t a marketing story. It’s a set of small technical decisions across seven systems, checked once a quarter. If your Slovenian WooCommerce shop needs a compliance audit against ZVOP-2 and current IP-RS guidance, we do it as part of our Stores service and ongoing care & compliance ops. Borderline DPO questions and quarterly reviews go under fractional CTO.