Privacy policy

This policy covers the IndiQR website, the QR code builder, the codes you save to an account, and the redirect that runs when somebody scans a dynamic code.

It does not cover what happens after a scan takes somebody to your own website, and it does not cover the pages your codes point at. Those are yours, and whatever you do there is between you and the people who visit.

Grouped by the moment it reaches us, because that is the honest way to read it — nothing here is gathered in the background.

When you create an account

Your name and your email address, and a password if you set one. Passwords are stored as a one-way hash: we cannot read yours, and nobody with access to the database can either. We also keep a note of whether you have confirmed your email address, and which optional emails you have turned off.

When you save a QR code

The name you give it, its type, and the content you entered — see what is inside your QR codes, which is worth reading before you save a Wi-Fi network. If you upload a logo, the image is stored with the code's design. A dynamic code also gets a short link of its own, which is what the printed code carries, and its current destination is stored alongside it.

When somebody scans a dynamic code

A short record of the scan, described in full under scan records. It does not include the scanner's IP address.

When you subscribe

Which plan you are on, whether it is billed monthly or yearly, what it costs, and the dates that matter: when it started, when a trial ends, when the term runs out, when you cancelled. A change of plan leaves the old record in place rather than overwriting it, so the history of what you were on is part of what we hold.

When you pay

The reference numbers for the order and the payment, the amount, the currency, whether it succeeded, the kind of method used — the word “upi” or “card”, not the account or the card — and the fee Razorpay charged us for it. No card number, expiry or CVV ever reaches us.

When you write to us

The name, address, subject and message you put in the contact form, and your account if you were signed in when you sent it. Nothing else is stored with the message: not your IP address, not your browser.

Your IP address is used to count requests, so that the contact form and the sign-in form can refuse a flood of them. Those counters are keyed by the address, expire by themselves within the day, and are not attached to the message or to your account.

While you are signed in

Each active session is stored on our side, and the row carries the IP address and browser identification string the session was created from. That is what a session recorded in a database holds, and it is how one can be recognised as still valid. The row is cleared when the session expires. A scan record, by contrast, carries no address at all — the two facts sitting next to each other is the honest version.

What we do not collect

• No advertising or third-party analytics. There is no Google Analytics, no advertising pixel and no session-recording tool on this site, so nothing here is shared with an ad network.
• No data bought from anybody else, and nothing added to your account from outside sources.
• No location beyond the coarse country and city already attached to a scan by the network it arrived over. Nothing asks your browser for its position.

We use what we hold to:

• Run your account and keep you signed in.
• Answer the scans of your dynamic codes by sending each one to wherever you currently point it.
• Show you reports on how often your codes are used.
• Take payments, start and end subscriptions, and produce receipts.
• Send the emails that go with an account: verifying an address, confirming a payment, warning that a trial or a term is ending. You can switch off the reminders and keep the rest — those are the ones that would be unhelpful to miss.
• Answer messages you send us.
• Look into a code somebody has reported, and switch it off if the report stands up. That is the one case where a person here goes looking at a code rather than answering a question about it.
• Keep the platform working: a record of failed payments, rejected webhooks and similar faults is what makes a problem findable.

We do not sell anything we hold, we do not rent it, and we do not use it to advertise to you or to build a profile of you. It is shared only with the services listed under who else sees your data, and only as far as they need it to do their part.

A saved code is stored as what you typed. Depending on the type, that can be personal or sensitive, and it is worth being specific about which:

• Wi-Fi codes hold the network name and the password. Both are stored in readable form, because both have to be in the QR image for a phone to be able to join.
• Payment codes hold the UPI address and payee name you entered, and the amount if you set one.
• Contact codes hold the name, phone number, email, company and website on the card.
• Event codes hold the title, dates, location and description.
• Everything else — websites, menus, documents, reviews, plain text — holds the address or the words you gave it.

The builder runs in your browser, and that has two consequences worth knowing. If you never save a code, nothing you typed reaches us at all — the image is drawn on your own machine and downloaded from there. And if you are part way through building one, the draft is held in your browser's own session storage so you do not lose it when you sign in, and is gone when you close the tab.

Saving is what puts a code in the database, and that is true of static codes as well as dynamic ones — the difference between them is where the content ends up when it is scanned, not whether we hold it. A dynamic code prints a link back to us, so we can send the scan on and count it. A static code prints the content itself, which is why it cannot be changed or counted later, and why the image on the poster carries your Wi-Fi password rather than a link to it.

We store what a code is configured to do — the fields above and the design — and not the image. Every picture you see or download is drawn again from those two things.

When somebody scans a dynamic code, the redirect passes through us, and we keep a record so you can see how the code is doing. Each record holds:

• Which code was scanned, and when.
• A country and, where the network supplies it, a city — no finer than that.
• Whether it was a phone, a tablet or a computer, and the name of the browser and operating system.
• The site the scan came from, if any, as a bare address such as https://example.com — never the full page.

That is the whole record. It deliberately does not include:

• The IP address. It is not stored, not hashed and not kept anywhere else. The country and city come from information the network already attaches to the request as it reaches us, so there is nothing to keep.
• The browser identification string. It is read to work out “phone, Chrome, Android” and then discarded rather than saved.
• Any cookie or identifier on the person scanning. Nothing is set on their device, so two scans cannot be recognised as the same person, and a scan cannot be followed from one of your codes to another.

The result is a report that can tell you a code was scanned four hundred times from two cities, mostly on phones. It cannot tell you who did it, and neither can we.

Static codes record nothing, for the simple reason that scanning one never contacts us.

You can sign in with a password or with Google, and either way we hold as little as the method allows.

Passwords

Stored hashed, never in a form anybody can read back. If you sign in with Google and never set one, there is no password on your account at all.

Google sign-in

We ask Google for the basic sign-in details — who you are, your email address and your name — and nothing beyond that. Of what comes back we keep three things: Google's own identifier for you and the email address on that Google account, so you can be recognised next time, and your name if this is the account being created. Your profile picture and everything else Google offers is not stored.

We do not receive or keep a Google access token, so there is no continuing access to your Google account from here: not your contacts, not your calendar, not your files. If the email address on your Google account matches an account here already, the two are linked rather than duplicated.

Email verification

Verification uses a signed link that expires. There is no token stored against your account, and changing your email address asks for confirmation of the new one.

Staying signed in

Signing in sets a session cookie. Ticking “keep me signed in” adds a longer-lived one so you are not asked again every time. Signing out ends that session. Changing your password turns out every other one: the next request each of them makes is refused, and whoever is holding it has to sign in again. You stay signed in where you changed it.

Payments are handled by Razorpay. Card and UPI details are entered on Razorpay's own checkout, which runs in your browser and sends them straight to them — those details never pass through our servers and we could not store them if we wanted to.

What goes to Razorpay when you start a payment:

• The amount, the currency, our own reference for the order, and which plan and billing cycle it is for.
• Your name and email address, so their checkout can fill those in for you rather than making you type them again. Not your phone number — we do not have one.

What comes back and is kept:

• The order and payment reference numbers, the amount, the currency and the outcome, plus a receipt number we generate ourselves for your records.
• The kind of method used, the fee and tax Razorpay charged us for handling it, and, when something fails, the reason they gave, so support can explain what happened.

Everything else in their response is dropped as it arrives rather than filtered later: the card record, the UPI address, the bank, the wallet, the reusable payment handles, and the email address and phone number the payer typed into their checkout. The signature that proves a payment is genuine is checked and then thrown away rather than stored. What you give Razorpay is also covered by their own privacy terms, which are theirs rather than ours.

This site uses cookies for signing in and nothing else. There are three, and all of them are necessary for the thing they do:

• A session cookie, which is what keeps you signed in. It cannot be read by JavaScript.
• A CSRF token, which is how the server can tell a form you submitted from a request another site made on your behalf.
• A longer-lived sign-in cookie, only if you ask to stay signed in.

Two things are also kept in your browser's session storage, which is cleared when you close the tab and never sent to us: a QR code you are part way through building, and whether you last looked at monthly or yearly prices.

There are no advertising cookies, no analytics cookies and no third-party scripts on the pages you browse — Razorpay's checkout loads only when you actually go to pay. Fonts are served from this site rather than fetched from Google. Nothing is set on somebody who merely scans one of your codes.

This is why you are not asked to accept cookies: there is nothing here to opt out of that would leave the site working. If that ever changes, this page changes with it and a choice comes with it.

People running the platform

An administrator account can see your name, email address and subscription, the codes on your account, and where a dynamic code currently sends people. That is what answering a support question or a report about a code takes.

The moderation screens are deliberately narrower than the database behind them. A Wi-Fi password, a phone number and an email address inside a saved code are withheld from them — the screen says the field is not shown rather than pretending it is empty — and a static code is not redrawn there, because a picture of one on screen is the content, scannable off the monitor. Whoever changes a plan, a role or a setting has that recorded, with their own address, in a log they cannot edit.

Services we use

Four are involved in running the platform, and each sees only its own part:

• Razorpay — payments, as described above. Only if you pay.
• Google — sign-in. Only if you choose that button.
• An email provider — delivers the messages the platform sends, which means it handles your address and the contents of those emails.
• Hosting and a content network — serves the site and passes on the country and city that end up on a scan record.

Beyond those, data goes out only if we are obliged to hand it over by law. There are no advertising networks, no data brokers and no analytics companies in the list, because none are used.

• Your account — while it exists. See your choices for closing it.
• Your QR codes — until you delete them. Deleting a code deletes its scan history with it, and that cannot be undone.
• Scan records — for as long as the code they belong to exists.
• Payments and receipts — kept as the billing record, because a receipt you cannot find later is not a receipt. A failed or abandoned payment is kept too, marked as what it was.
• Sign-in sessions — each row lasts as long as the session it belongs to, which by default ends after two hours of inactivity. Signing out ends it immediately.
• Contact messages — kept. Nothing removes them on a schedule, and there is no screen for deleting one, so a message stays until it is removed directly from the database. If you want yours gone, ask.
• Fault records — deleted after 90 days by default, and the record itself is a description of what went wrong with an account or a payment reference, not your details: email addresses, payment payloads and anything resembling a secret are stripped out before it is written.
• Records of emails sent — the fact that a message was sent, with no address or contents, kept for 180 days by default so the same reminder is never sent twice.
• Notes of Razorpay's server-to-server messages — an identifier and the name of the event, so the same one is not acted on twice. The message itself is not stored. These are kept.
• Administrative actions — when somebody running the platform changes a plan, a role or a setting, that is recorded permanently, including their own IP address. It is a record of what was done to accounts, so it is deliberately not editable and not deleted.

What you can do yourself, today, from your account:

• Change your name or email address, and set or change your password, from your account settings.
• Turn off the optional reminder emails in notification settings. The ones about your account and your payments cannot be switched off, because missing them would cost you something.
• Delete any code, which deletes its scan history, from your codes.
• Cancel a subscription, and see every past payment, from subscription settings.
• Sign out, which ends that session.

What there is no button for yet: closing your account and downloading everything we hold about you. Neither exists in the software at all — not on your side and not on an administrator's — so both are done by hand against the database. Write to the contact form and say which you want. We would rather say that plainly than describe a control that is not there.

One thing worth knowing if you are closing an account: your codes are not attached to it in a way that removes them with it, so delete the ones you want gone first. Deleting a code takes its scan history with it, and a dynamic code stops redirecting the moment it goes — which is the point, and is also why it cannot be undone.

What is actually in place, rather than an adjective: passwords are stored hashed and, in production, a new one is refused if it appears in the published lists of leaked passwords. Sign-in and the contact form are rate limited. Forms are checked against a token, so another site cannot post one on your behalf. Verification links are signed and expire. Card details never reach us. The keys and passwords the operator configures — for the payment gateway, for email — are encrypted where they are stored, and administrative actions are logged where the person taking them cannot edit the log.

The security page goes through this in more detail and, just as importantly, lists what is not in place: no two-step verification, no self-service password reset, no certification of our own.

No system is beyond being broken into, and anybody who tells you otherwise is selling something. If you find a weakness, the security page explains how to report it.

When the platform changes what it collects, this page changes too, and the date at the top moves. That date is how you can tell whether what you are reading is current.

We do not currently email everybody when the wording changes. If a change means we would start collecting something materially different from what is described here, we will say so on the site rather than leaving you to notice a new date.

Questions about any of this, or a request about your own data, can go to the contact form, or through the contact form. A person reads it.

If something on this page does not match what you see the platform doing, tell us — that is a mistake worth fixing quickly, and we would rather hear it from you than not.