Skip to main content
QR Code for Business
  • Pricing
  • Sign in

Draft, not reviewed. A lawyer has not reviewed this text yet. It can change.

Privacy policy

Last change: November 11, 2026

1. Who is responsible

Followers B.V., Lekdijkerf 2, 4125VN Hoef en Haag, Netherlands, is the controller of the personal data of QR Code for Business. Contact:support@qrcodeforbusiness.com.

[Owner decision needed: the data protection contact, and whether a data protection officer is necessary.]

2. The data that we keep

  • Account. Your email address, an account ID, and the time when you made the account. Firebase Authentication (Google) does the sign-in with Google or with an email link.
  • Codes. The name, the destination link, the vCard data, the PDF file, and the design (with the logo image) of each dynamic code. Static codes stay in your browser. We do not store them.
  • Scans. For each dynamic code we store the number of scans, the time of the first scan, and the number of scans for each hour, each country, and each device group (iOS, Android, desktop, or other). The country comes from Cloudflare. The device group comes from the user agent of the browser. We do not store the IP address or the full user agent of a person who scans a code.
  • Payments. The Stripe customer ID, the plan, the status, and the end date of the subscription, and the fact that the account paid at any time. A flag that stops a new checkout after a card dispute. The price group of the account (price_arm). The price group also goes to Stripe with the checkout and to Google Analytics with the payment events. We do not see or store card data.
  • Measurement. Events of the site (for example "code created" or "purchase") with the account ID or a random browser ID. The first landing page, the ad click IDs (gclid, gbraid, wbraid), the UTM values, and the Google Analytics client and session IDs. In the EEA, the United Kingdom, and Switzerland, your browser keeps and sends the browser ID, the landing page, the click IDs, the UTM values, and the Google Analytics IDs only after you select Accept. In other countries, your browser keeps the browser ID and the landing page. It keeps the click IDs, the UTM values, and the Google Analytics IDs until you opt out.
  • Withdrawal of consent. When you select Reject in "Cookie settings", or "Do Not Sell or Share My Personal Information", we delete the ad click IDs and the Google Analytics client and session IDs of your account. If you are not signed in at that time, your browser keeps the request and sends it at your next sign-in on that browser. While this choice holds, your browser does not send these IDs again. The UTM values and the first landing page of your account stay.
  • Emails. A list of the emails that we sent to the account, and your choice about marketing emails.
  • Abuse reports. The code ID, the text of the report, the time, and the email address of the reporter if the reporter gives one. A copy of the report can also go by email to our support mailbox and stays there.

[Owner decision needed: the legal basis for each kind of data (contract, consent, or legitimate interest).]

3. The services that process data for us

  • Cloudflare hosts the site and the short links, and stores the data (D1, KV, R2). Cloudflare Email Service sends our emails. Cloudflare Workers logs record each request to the site and to the short links, with the request data that Cloudflare collects, and the log lines of our code.
  • Firebase Authentication (Google) does the sign-in and keeps the sign-in record of your account.
  • Stripe sells the paid plan as the merchant of record. Stripe collects the payment data, the tax data, and the invoice data under its own privacy policy.
  • Google Web Risk checks the destination links and the web address of a vCard. We send the full link (not a hash) to Google when you set it. We send the destination link again about once each day while the code is active.
  • Google Analytics 4 measures the use of the site and our ads. It uses Consent Mode v2. When we send a payment event from our server to Google Analytics, the event has the Google Analytics client ID of your browser only if we have one for your account.

[Owner decision needed: the transfers of data outside the EEA and the safeguards for each service.]

4. Cookies and browser storage

  • In the EEA, the United Kingdom, and Switzerland, the site does not load Google Analytics, does not write the qr_attr cookie, does not make a browser ID, and sends no browser events to our server until you select Accept in the cookie banner. After Reject, the same applies, and the site deletes the qr_attr cookie and the Google Analytics cookies. After Reject on a page where you accepted before, the Google Analytics script stays in that page until you leave or reload the page. It sets no cookies.
  • In other countries, analytics and ad measurement are on, and you can turn them off. After Reject in "Cookie settings", Google Analytics runs without its cookies (Consent Mode v2), and the site deletes the Google Analytics cookies and the ad data of the qr_attr cookie. The random browser ID and the browser events to our server stay.
  • We honour Global Privacy Control. With Global Privacy Control or the "Do Not Sell or Share" choice, the ad measurement is off in all countries, and your browser sends no Google Analytics IDs to our server. Thus a payment event that our server sends to Google Analytics has no client ID of your browser.
  • qr_consent keeps your banner choice, and qr_no_ads keeps your "Do Not Sell or Share" choice. Each is a cookie and a local storage value. The cookie expires after 365 days.
  • qr_attr is a first-party cookie for 90 days. It keeps a random browser ID and the first landing page. It can also keep the ad click IDs and the UTM values, under the rules above. The sign-out and the account delete remove it from the browser.
  • Google Analytics sets its own cookies (_ga and _ga_*). In the EEA, the United Kingdom, and Switzerland it sets them only after you select Accept.
  • qr_generator_state is a local storage value. When you sign in during the design of a dynamic code, it keeps the unfinished design and content for 2 hours maximum, with a random value that ties it to the sign-in of that page. The site does not use an older design and removes it. The site also removes it when you create the code, when you go back to the design, when you sign out, and when you delete the account.
  • qr_signin_email is a local storage value. It keeps the email address to which we sent a sign-in link, until the link completes the sign-in in this browser.
  • qr_generator_started and qr_generator_designed are session storage values. Each keeps a flag, so the site sends each of these two events one time for each browser tab. They go when you close the tab.
  • Firebase Authentication keeps your sign-in (an ID token and a refresh token) in the IndexedDB store firebaseLocalStorageDb of the browser until you sign out. The site keeps a short "signed in" flag (qr_signed_in) in local storage.
  • qr_clear_ads_pending is a local storage value. It keeps a request to delete the ad data of your account until our server confirms the delete.
  • qr_consent_region is a session storage value. It keeps the answer to "is the visitor in the consent region" until you close the browser tab.

To change your choice, select "Cookie settings" at the bottom of each page. To stop the use of your data for ads, select "Do Not Sell or Share My Personal Information" at the bottom of each page.

5. How long we keep the data

  • We delete a paused code 90 days after the pause, or 12 months after the pause for an account that paid at any time.
  • When we delete a code, we remove its name, its destination, and its PDF file. We keep the short ID, so that we never use it again. The design and the scan statistics of the code stay.

[Owner decision needed: the retention periods of the account data, the scan statistics, the events, the email list, and the Workers logs.]

[Owner decision needed: retention period of abuse reports, in the database and in the support mailbox.]

6. When you delete your account

You can delete your account in the dashboard. You must cancel an active subscription first. The delete does this:

  • It deletes all your codes that are not blocked, with their names, destinations, and PDF files.
  • It removes your email address, the random browser ID, the ad click IDs, the UTM values, the landing page, and the Google Analytics IDs.
  • It removes the qr_attr cookie and a saved design from the browser in which you delete the account.
  • It turns off marketing emails.

We keep these data after the delete:

  • The account ID, the number of dynamic codes that the account made without payment, and the payment flags. Thus a new sign-in with the same account does not get new codes without payment.
  • The Stripe customer ID and the subscription record.
  • The events with the account ID, the list of sent emails, and the scan statistics of the deleted codes.
  • The design of each deleted code, for example a logo image.
  • Blocked codes and their files, as evidence of abuse.

The delete does not remove your sign-in record at Firebase Authentication.

[Owner decision needed: the process to delete the Firebase Authentication record on request.]

[Owner decision needed: the retention period of the account ID and the count of codes made without payment after the account delete.]

[Owner decision needed: the retention period of blocked codes and their files after the account delete.]

7. Your rights

You can ask for a copy of your data, a correction, a deletion, or a limit on the use. You can object to the use. Send an email tosupport@qrcodeforbusiness.com. You can also complain to a data protection authority, for example the Dutch Autoriteit Persoonsgegevens.

[Owner decision needed: the answer time for a request, and the text for the rights of California residents.]

Company

Followers B.V.

Lekdijkerf 2, 4125VN Hoef en Haag, Netherlands

Support: support@qrcodeforbusiness.com

Legal

  • Terms
  • Privacy
  • Refunds
  • Acceptable use
  • Company
  • Report abuse
  • Pricing