Security
Built so your codes don’t depend on us being perfect.
Managed infrastructure, encryption in transit and at rest, access control enforced by the database, and payments we never touch. Plus an export in your pocket, in case we ever get something wrong.
Last updated: 2 September 2026
- 01
The short version
QRever holds very little about you, runs entirely on managed infrastructure, and never touches your card details. Every row in our database is access-controlled at the database itself, not just in application code. And the strongest guarantee is structural: because every paid code ships with its own export and static fallback, your printed codes do not depend on our security being perfect forever.
This page describes how the service is built as of 2 September 2026. If we change something material here, the date changes with it.
- 02
Infrastructure
QRever is a Next.js application with no self-managed servers. Two providers do the heavy lifting, each maintaining its own independent SOC 2 Type II attestation:
- Supabase — Managed Postgres database, authentication, and file storage.
- Vercel — Application hosting and the global edge network that serves redirects.
The redirect engine that answers every scan runs on Vercel’s edge network, in the region closest to the person scanning, with a sub-100 millisecond target. The database, authentication, and uploaded images are all Supabase-managed Postgres and object storage. We patch nothing by hand and run no machines of our own to be misconfigured.
- 03
Encryption
In transit. Every connection to qrever.com, to the redirect engine, and to our database is HTTPS with modern TLS. HTTP is redirected to HTTPS, and the site sends a two-year HSTS header so browsers refuse to connect any other way.
At rest. The database and file storage are encrypted at rest by Supabase using AES-256. Automated backups are encrypted with the same standard.
- 04
Authentication
Accounts are handled by Supabase Auth. You sign in with an email and password, or with Google. Passwords are stored only as a salted bcrypt hash — never in plain text, never logged, and not recoverable by us; a reset issues a new one. Sessions are kept in a signed, HTTP-only cookie that JavaScript on the page cannot read.
Free static QR codes need no account at all — they are generated in your browser and never sent to us — so for those there is no credential to protect.
- 05
Database access control
Every table has Postgres row-level securityswitched on, with policies that scope reads and writes to the owning account. A logged-in session physically cannot query another user’s codes, pages, scans, or purchase records — the restriction is enforced by the database on every statement, not by application code that could have a bug.
Uploaded images follow the same rule: you can only write to your own storage folder. The high-privilege service key that the redirect engine uses to look up destinations lives only in server environment variables and is never sent to the browser.
- 06
Backups and recovery
The database is backed up automatically every day by Supabase, with backups retained on a rolling window and encrypted at rest. Uploaded images are stored redundantly by the same provider.
Our application code and the complete database schema are held in version control, so the service can be rebuilt and redeployed from source. The data that actually matters for a working code — its short ID and current destination — is tiny, and is also in your own hands the moment you export.
- 07
Availability and resilience
The redirect path is deliberately the most robust part of the system, because it is the part your printed codes depend on:
- Destination lookups are cached at the edge, so a scan still resolves during a brief database interruption. An edit to a destination busts that cache immediately, so changes are never stale.
- Scan logging happens afterthe redirect is sent, as a background task. If analytics writes fail, the visitor still reaches the destination — they never wait on it.
- On an unexpected error the redirect engine returns a small branded page with the right HTTP status, not a blank crash or a spinner.
We target high availability but do not sell a contractual uptime SLA. The reasoning, and the full request path, is on the reliability page.
- 08
Disaster recovery
Infrastructure-level failures — a bad region, a failed instance — are handled by Vercel and Supabase, which run redundant systems. A total loss of our environment is recovered by redeploying from version control and restoring the most recent database backup.
Beyond that, QRever’s continuity design does not rely on us recovering at all. Every paid code carries a one-click export, and every dynamic code can be turned into a static fallback QR that works with no servers and no company behind it. If the worst happened, your codes would outlive the incident.
- 09
Account security, and what you control
Your side.Use a strong, unique password or sign in with Google. You can delete any code, or your whole account, from the dashboard — deletion is real, not a soft-hide.
Our side. We collect the minimum to run the product: an email, a hashed password, your codes and their destinations, and coarse scan analytics with no IP address stored. There is no marketing profile of you or of the people who scan your codes, because we do not build one. What we do and do not collect is itemised in the privacy policy.
- 10
Payment security
QRever never sees or stores your card number, CVV, UPI PIN, or bank details. The payment form is served and processed entirely by a PCI-DSS certified provider:
- Razorpayfor orders in India (PCI-DSS Level 1). QRever is the merchant; Razorpay handles the card, UPI, or netbanking transaction.
- Dodo Paymentsfor orders outside India, acting as our Merchant of Record — the legal seller for that transaction, responsible for billing, tax, refunds, and chargebacks.
What we store is the order outcome: which product, the amount, the currency, and the gateway’s order ID. Payment webhooks are signature-verified and processed exactly once — a replayed or duplicated webhook cannot double-charge you or double-grant credits.
- 11
Reporting a vulnerability
If you believe you have found a security issue, email support@qrever.com with “Security” in the subject. Tell us what you found and how to reproduce it. We will acknowledge quickly, keep you updated, and we will not pursue action against good-faith research that avoids privacy violations, service disruption, and data destruction.
- 12
Operator
QRever is operated by Sanora Technologies, from India. Full operator and registered-office details are on the privacy policy. Security and privacy contact: support@qrever.com.
See also: Reliability · Data Export · Privacy Policy · The Promise