Site information / en-PL

Privacy policy

This policy describes the current static functionality of lunaveracasino.com. It is written in plain English and should be reviewed with the actual business identity, delivery route, and applicable legal advice before publication. The site operator is currently represented by the replaceable business identity fields for LunaVera Casino Hotel.

1. Who operates this site

The operator is the business or person responsible for LunaVera Casino Hotel and the domain lunaveracasino.com. The legal name, registered address, contact details, and data-protection contact should be inserted by the operator before the site is used as a live business service. Do not treat the visual brand name alone as a completed legal identity.

2. What the site does

This is a static, English-language website for visitors in Poland. It presents a physical hotel and on-site adult evening venue in Kraków. It does not provide online gambling, player accounts, betting registration, wagers, deposits, withdrawals, payment processing, bonus codes, or a gambling wallet. No promise of winnings or availability is made.

3. Information submitted through forms

Some pages contain hotel, room, dining, venue-information, accessibility, responsible-play, media, or partnership enquiry forms. The fields currently request a full name, email address, enquiry type, an optional general period, a message, and a privacy acknowledgement. The forms use method GET and action /success.

The pages do not ask for passport details, identity-document numbers, payment-card details, bank details, gambling budgets, income, medical details, account passwords, or exact dates of birth. Please do not put that information into a free-text message.

4. What happens when a form is submitted

Native browser validation and a small client-side script check required fields, email format, length, consent, and field errors. If the form is valid, the browser navigates to success. The success page is a confirmation of the page flow only. It does not prove that a message was sent, received, stored, booked, or reviewed.

No delivery backend, CRM, database, newsletter system, payment processor, analytics service, advertising network, or support ticket integration is configured in the generated static site. If an operator later adds one, this policy and the form wording must be updated before collecting data through that service.

5. Technical information

A web server or hosting provider may process ordinary technical information needed to deliver a page, such as an IP address, request time, user agent, referrer, response status, and requested file. The operator should confirm the actual server logs, retention period, hosting provider, and legal basis in the production environment. This project does not add a separate tracking script.

6. Essential storage and cookie preferences

The site uses localStorage only for the consent choice under the key lunavera-consent-choice. The value records whether optional storage was accepted, rejected, or left disabled through the preference panel. Essential storage is treated as always enabled so the consent interface can remember the choice.

On a first visit, a privacy ledger banner offers equal options to accept optional storage, reject optional storage, or manage choices. No optional analytics is loaded because no analytics service is configured. The visitor can reopen the preferences from the privacy control shown after a choice is made. If the browser blocks localStorage, the banner may appear again.

7. Optional analytics

Analytics, advertising pixels, behavioural tracking, marketing tags, and similar optional services remain disabled in this implementation. Accepting the optional category does not load a service that does not exist. A future configuration should name the service, purpose, provider, retention, transfer route, and withdrawal method before it is enabled.

8. Purposes and legal bases

Possible purposes include displaying the website, remembering a consent choice, responding to an enquiry where a working delivery route exists, protecting the service, and maintaining security. Depending on the final operator and facts, legal bases may include taking steps at the visitor's request before a contract, legitimate interests in operating a secure information website, legal obligations, or consent for optional storage. The operator must confirm the correct legal basis rather than copying this paragraph as a legal conclusion.

9. Retention

Keep information only as long as necessary for the purpose for which it was collected, legal obligations, dispute handling, or security. The static code does not define a server-side form retention period because it does not implement a delivery backend. The operator must document retention for any hosting logs, email inbox, contact system, or future integration actually used.

10. Service providers and international transfers

Hosting, domain, email, form delivery, security, or analytics providers may process information only if the operator configures them. Their names, locations, contractual safeguards, and transfer mechanisms should be added when known. Do not claim that a provider is active merely because a future integration could be added.

11. Security

Use HTTPS, current hosting controls, access restrictions, backups, and a careful process for handling enquiries. Do not send sensitive identity, financial, medical, or gambling information through these forms. Client-side validation improves usability but is not a security boundary and does not replace server-side controls in any future delivery system.

12. Children and adult-only areas

The hotel website is intended for adult visitors and must not target minors with gambling-related content. Casino areas are for adults aged 18 and over. The site does not knowingly invite children to participate in gambling, create accounts, or submit gambling information.

13. Responsible-play enquiries

A visitor may ask for information about responsible play or venue-level support. Those enquiries should be handled carefully and only through a verified delivery route. The site does not claim a specific self-exclusion programme, cooling-off process, helpline number, medical service, or treatment result. Visitors should verify current official Polish public-health and addiction-support resources directly.

14. External links

Some pages may link to official government or public-health resources, Figma-derived information, or other external sites. The operator should check that each external link is current and should not claim responsibility for the external site's privacy practices. Review the destination before entering personal data.

15. Your rights

Under applicable Polish and European data-protection rules, a person may have rights including access, rectification, erasure, restriction, objection, data portability, and withdrawal of consent, subject to the facts and legal limits. Contact the verified operator using the production contact details. A person may also have the right to complain to the competent data-protection authority in the relevant jurisdiction.

16. Policy updates

Update this policy when the operator identity, form delivery, hosting, cookies, analytics, advertising, storage, external links, or site purpose changes. Keep the publication date and a short explanation of material changes visible in the production version.

17. Contact procedure

For privacy questions, use the verified contact route published by the operator. The current static project provides the contact page as an information route but does not claim that a message has been delivered or stored. Do not use the form for urgent safety, health, or emergency matters.

18. Data minimisation in practice

Use the smallest amount of information needed to understand an enquiry and prepare a reply. A visitor can normally describe a room preference, general travel period, dining request, accessibility route, venue-information question, or responsible-play concern without submitting a passport number, payment-card number, bank information, account password, exact date of birth, medical record, or gambling budget. If someone sends unnecessary sensitive information anyway, the operator should restrict access, avoid copying it into unrelated systems, and follow the applicable incident and deletion process.

19. Verification before launch

Before this page is treated as a final production notice, the operator should verify the legal identity, registered address, privacy contact, hosting provider, form delivery route, security controls, transfer arrangements, retention schedule, cookie behaviour, consent records, and every external link. The static implementation is intentionally explicit about its current limits: there is no configured analytics vendor, no backend message store, and no claim that an enquiry has been delivered. The policy must change when the real system changes.

20. Consent interface behaviour

The first visit displays a privacy-choice notice. Rejecting optional storage, accepting optional storage, or saving an explicit choice records a small essential preference in localStorage so the notice does not reappear on every page. The current build does not activate optional analytics after acceptance. A future operator must not treat this interface as a complete compliance solution without matching the actual technologies, purposes, lawful basis, withdrawal method, and records required for production.

21. Operator checklist

Before publication, confirm that the privacy contact is monitored, the form delivery route is secure, the hosting contract is understood, access to submissions is limited, and deletion requests can be completed. Confirm that the consent interface matches the real cookie and storage inventory. If the owner adds a booking provider, map, newsletter, advertising tag, analytics tool, player account, payment flow, or external chat, document what that provider receives and update the notice before the feature is promoted.

22. Plain-language summary

This static site keeps optional tracking off, uses localStorage for a small consent preference, and uses forms that only prepare a general enquiry for a delivery route that the owner still needs to configure. Visitors should share only what is needed, avoid sensitive information, and use official or urgent services for matters that cannot safely wait. The summary does not replace the full policy or the verified production details.

23. If the build changes

Recheck this notice whenever the site moves from a static brochure to a booking flow, newsletter, map, chat, account, payment, player, analytics, or advertising system. New fields and providers should be documented before launch, not described after the fact. The operator should also review accessibility, age-related presentation, responsible-play wording, and the way an individual can withdraw optional consent or exercise a data right.

24. Keep the notice aligned

Visitors should be able to compare this explanation with the actual interface and network behaviour. If the two differ, the production implementation and this notice need to be corrected together.