Cookie Policy (Request a Visa)

Where it lives and how it renders

The content lives in C:\Users\Sabur\sites\visa-mvp\lib\i18n\dictionaries\nl.ts under legal.cookiebeleid. The page files C:\Users\Sabur\sites\visa-mvp\app\(site)\cookiebeleid\page.tsx and C:\Users\Sabur\sites\visa-mvp\app\[locale]\cookiebeleid\page.tsx are unchanged: they retrieve this block via getDictionary().legal.cookiebeleid and pass it to the LegalPage component.

LegalPage (C:\Users\Sabur\sites\visa-mvp\components\LegalPage.tsx) displays the title, the date from legal.updated ('28 June 2026'), the intro, all sections, and at the bottom a grey box with the company details from BRAND (name, street, postal code/city/country, Chamber of Commerce no., VAT, email). That is why I have not duplicated those details in the section text, only referred to them ('the email address at the bottom of this page').

The body format is, per section, an array of strings; each string is rendered as a separate paragraph (<p>). I have respected this: each body item is exactly one paragraph.

What the policy covers (10 sections)

1) What cookies and similar techniques are (incl. local/session storage, pixels, first- vs third-party). 2) Core principle: consent in advance, refusing as easy as accepting, no pre-checked boxes, Consent Mode v2 defaulting to 'denied'. 3) Strictly necessary/functional cookies (wizard progress, session/security, rav_consent choice, Vercel hosting).

4) Payment cookies (PayPal + iDEAL/card/Apple Pay/Google Pay as necessary for the payment service, the provider itself being responsible). 5) Analytics/marketing cookies only after consent: Google Ads + Enhanced Conversions with a hashed email address, plus international transfer (US). 6) Overview per category (parties, legal basis, retention period) in readable prose rather than an HTML table, because the render component only supports paragraphs.

7) Withdrawing/changing consent (no retroactive effect, banner again, consent logging). 8) Managing cookies via the browser (Chrome/Safari/Firefox/Edge, Do Not Track). 9) GDPR link: personal data, processors (PayPal, Vercel, MongoDB Atlas, Brevo, Zoho, Anthropic, Google), transfer outside the EEA, data subject rights + Dutch Data Protection Authority. 10) Changes to the policy + renewed consent for material changes.

Protection and compliance choices

Prominent and repeated: 'independent service provider, not a government body, not an embassy' already appears in the intro, in line with the non-government disclaimer that runs throughout the entire site. This guards against misleading/consumer-authority accusations.

The consent text matches the code exactly (Consent Mode v2 signals, rav_consent, equivalent buttons), so that the policy contains no false claims and is defensible in a data protection authority audit or chargeback dispute. Enhanced Conversions is described honestly as 'only after consent' and 'hashed', consistent with the existing privacy policy.

Cross-reference to the privacy policy for the weightier GDPR topics (art. 28 processors, transfer outside the EEA, data subject rights), so that the cookie policy is complete without overlapping or contradicting the privacy policy.

Point of attention: cookie table

The research context calls for a cookie table (name, purpose, type, retention period, party). The current LegalPage component renders only heading + paragraphs, no tables. I have therefore included the table content as structured paragraphs per category (section 6). If you want a real HTML table with exact cookie names and durations (e.g. _ga, _gcl_au, session cookies), then LegalPage must be extended with an optional table field, or a separate cookie-table component must be added. Say the word if you want that, and I will build it.

Concrete cookie names/retention periods from Google and the payment providers can be changed by those parties; the text states this explicitly and refers to their own policies, so that the policy does not quickly become 'untrue'.

Verification

npx tsc --noEmit -p tsconfig.json passes with exit 0: the change is syntactically valid and does not break the build.

Sanity check of the block: exactly 10 sections (10x 'heading:'), brackets balanced (11 open / 11 close for the arrays). No preview server needed; this is static, correctly wired content that appears via the existing render route at /cookiebeleid and /[locale]/cookiebeleid.