We use cookies and similar technologies to keep the Service secure and operational and, with your consent, to enable functional, analytics and marketing features.
You can manage your choices in the cookie banner or in Cookie settings (footer link). You may accept all, reject non-essential categories, or choose categories individually.
We store your consent preferences in browser storage (for example consent_prefs_v1 in localStorage).
Session cookies expire when the browser is closed. Persistent cookies have a predefined retention period (for example, a few months), depending on configuration and providers.
session) — authentication and active session maintenance.language) — remembers selected UI language.consent_prefs_v1 in localStorage) — stores category selections.We may use third-party services. Those providers may set their own cookies and process data under their own policies.
Most browsers allow you to block or delete cookies in privacy settings. Please note that disabling necessary cookies can prevent secure login and normal Service operation.
If non-essential providers process data outside the EEA, we apply appropriate safeguards (for example standard contractual clauses) and activate those categories only after consent.
This policy can be updated due to legal, technical, or product changes. The current version is always available at /cookies-policy.
If you have questions about cookies or consent choices, contact us at support@qrtransfers.com.
No. Only necessary cookies are required. You can reject or customize non-essential categories.
Yes. Open Cookie settings from the footer and save updated preferences at any time.
Removing cookies clears session tokens, so re-authentication is required for account security.
For the avoidance of doubt, browser-side storage used by the Service is not intended to store complete card credentials, CVV/CVC values, plaintext passwords, recovery codes, full identity-document scans, or private support attachments. Non-essential analytics or marketing scripts are not intended to load before consent where consent is required by law.
Cookie and localStorage records are affected by browser settings, private mode, tracker blocking, device synchronization, user-side deletion, and vendor privacy controls. As a result, stored consent choices, session continuity, and retention periods may reset or differ across devices. Technical proof of consent can therefore rely on a combination of browser-side records and server-side event logs where legally appropriate.
Where a third-party analytics or marketing provider is enabled, that provider may apply its own retention periods, identifiers, and cross-service policies under its own documentation. This page describes the Service-layer implementation and consent model, not every downstream practice of each external provider in full detail.
The practical consent flow can involve several technical stages: initial banner display, user action capture, local preference storage, conditional script loading, and later re-checks of the stored preference on subsequent page views. Because browser environments differ, the Service aims to enforce a consent-first model for non-essential categories, but timing, storage persistence, and load order may still be affected by client-side privacy settings, blockers, browser vendor controls, or network conditions.
When this policy refers to cookies and similar technologies, it may include HTTP cookies, localStorage, sessionStorage, temporary state markers, session-integrity tokens, analytics tags, conditional third-party scripts, and related browser-side persistence mechanisms that help maintain security, interface state, or consent choices. Not every such mechanism serves the same purpose, and not every browser exposes them in the same user-facing diagnostics.
Users should not assume that the absence of a visible HTTP cookie means the absence of all browser-side storage, or that the presence of an identifier automatically means cross-site marketing activity. Some identifiers exist purely for session integrity, anti-CSRF protection, login continuity, language preferences, or consent logging. Likewise, rejecting a category on one device does not necessarily replicate that preference to every browser profile or device unless a separate synchronized mechanism exists.
Private mode, automatic storage clearing, anti-tracking features, DNS filtering, content blockers, extension-based script rewriting, enterprise browser policies, and operating-system privacy settings can all alter how browser-side storage behaves. This means a consent choice may expire sooner than expected, a banner may reappear, or a script may remain blocked even after consent. The Service does not control those third-party environment settings.
Unless required for core functionality or explicitly enabled under an appropriate legal basis, the Service does not intend to use browser storage for plaintext passwords, full card details, CVV/CVC data, complete identity-document scans, or other excessive sensitive payloads. It also does not treat every technical identifier as a marketing tracker and does not assume that third-party providers will retain identifiers indefinitely.
This document describes the Service's intended implementation model and compliance posture for browser-side technologies. It does not replace mandatory law, browser-vendor documentation, or provider-specific third-party notices where those providers are enabled under a lawful basis. Where a short banner summary differs from this fuller policy, the more detailed explanation in this document should be read as controlling, subject to any stronger mandatory user protections under applicable law.