Privacy Policy

1. Who this applies to

This policy describes how PayMQR handles information when a merchant uses the service, and when that merchant's customer opens a PayMQR checkout page.

If you are a customer who paid a business through PayMQR, the business you paid is responsible for your order and for its own handling of your information. PayMQR processes the payment evidence you submit on that merchant's behalf.

2. Merchant account information

When you create an account we store the name, email address and mobile number you provide, and a hash of your password. Passwords are never stored in a recoverable form.

Your business profile — display name, legal name, business type, website, support contact and address — is stored as you enter it, and is used to identify your business in the console and on your customers' checkout pages.

Your payment accounts store the UPI ID and payee name you configure. These are the destination shown to your customers.

3. Payment and order data

For every payment you create we store the amount, currency, your own reference, any description you supply, the payment destination as it stood at creation, the environment (test or live), timestamps and the payment's status history.

Where a customer's device reaches a checkout, we store what is needed to operate that checkout — the session, its expiry and its outcome. We do not build a profile of the customer, and no device fingerprint, IP-based identity or advertising identifier is recorded for them.

4. Payment evidence

When a customer uploads a payment screenshot, the image is stored privately, outside the web root, along with metadata about the file and the checks that ran against it.

A screenshot may contain personal information belonging to the person who paid — a name, a bank reference, a partial account identifier. It is visible to the merchant the payment belongs to, so that they can verify it, and to no other merchant.

PayMQR does not publish proof images, does not use them for advertising, and does not share them with other merchants.

5. Automated reading of evidence

PayMQR may use an automated model to read a payment screenshot and extract structured details from it, so that a person has less to check by hand.

Where that happens, the model's output is treated as evidence for the deterministic checks and for a human decision. It never marks a payment verified on its own.

This capability is off unless a deployment has configured it. When it is off, no evidence leaves PayMQR for that purpose.

6. Technical and security records

We record request metadata — timestamps, HTTP method, status, a request identifier and API key identifiers — so that problems can be diagnosed and abuse detected. Rate-limit counters are kept for the same reason.

Privileged platform actions are written to an append-only audit log, together with who performed them and when.

Sensitive values are redacted from logs. Credentials, API keys, webhook secrets and checkout tokens are not written to log output.

7. Cookies and sessions

PayMQR sets cookies to make the product work: a session cookie when you sign in, a separate one for platform administrators, a CSRF token to protect forms, and a short-lived cookie that lets a customer return to a checkout they already started.

On the pages listed in the next section, the Meta pixel also sets its own cookies in your browser — "_fbp" always, and "_fbc" when you arrived from a Meta advertisement. They are set on the paymqr.com domain, they identify a browser rather than a person, and they are used for the advertising measurement described below.

One further short-lived cookie is set when an account is created, so that the account-created page can report the signup once and not again if you refresh it.

No PayMQR page loads a tag manager, a session recorder or a third-party stylesheet or font, and no page requires JavaScript in order to work. Blocking the pixel — by a browser setting, a privacy extension or refusing its cookies — does not affect any part of the service.

8. Advertising and conversion measurement

PayMQR advertises on Meta (Facebook and Instagram) and measures which advertisements lead to a paid plan. To do that, some pages load the Meta pixel, a script served from this website that reports to Meta.

It runs on the home page, the "payment gateway rejected or approval pending" page, the pricing page, the sign-up page, the free tools pages, and the page where a merchant pays for a plan. It does not run on the other pages of this website, anywhere in the merchant console apart from that plan payment page, or anywhere in the platform administration area.

What it reports is a page view and a small number of named steps: viewing the pricing page, choosing a plan, opening the page to pay for it, and submitting a payment screenshot for a plan purchase. It does not report the screenshot itself, any UPI ID, any bank reference, any customer payment, or anything about the payments you collect from your own customers.

If a link to PayMQR carries campaign or click parameters — the standard "utm_" set, or a Meta or Google click identifier — those parameters are carried between PayMQR pages so that a later purchase can be attributed to the advertisement that led to it. Nothing else from a link's address is carried, and a parameter that is not one of those is discarded.

When a merchant starts paying for a plan, PayMQR stores the Meta cookie values described above, the IP address the request came from and the browser user-agent string, against that specific purchase. Where a cookie is not present, nothing is stored in its place and no value is reconstructed.

PayMQR also reports completed PayMQR plan purchases to Meta directly from its servers, so that a purchase is counted even when a browser cannot report it. This includes an irreversible (hashed) form of the account email address, the account mobile number and an internal account identifier, where PayMQR holds them — Meta uses those to match the purchase to an advertisement. It reports PayMQR plan purchases only. It does NOT mean a payment you collected from one of your customers is sent to Meta: those payments are never reported, and payment evidence — a screenshot, a UPI ID, a UTR or bank reference, or a proof image — is never sent, in any form.

This measurement is about PayMQR's own advertising and PayMQR's own plan sales. It is not applied to your customers: a customer paying you through a PayMQR checkout page loads no advertising script and no advertising cookie is set for them.

9. Who else sees this information

PayMQR does not sell personal information.

Meta receives the advertising measurement described in the previous section: page views and named steps from the pages that load its pixel, and the cookie values its own script sets. It does not receive payment evidence, UPI IDs, bank references, or any information about the payments you collect from your customers.

Information is shared with infrastructure providers strictly to run the service — for example hosting and database infrastructure — and, where a deployment has configured automated evidence reading, with the model provider it configured for that purpose.

Information may be disclosed where the law requires it, or where necessary to investigate abuse of the service.

10. Retention

PayMQR does not currently delete merchant accounts, payments, payment evidence, technical records or audit entries automatically. There is no scheduled purge and no built-in expiry on any of them.

This is deliberate for a payment record system — a record that vanishes is a record that cannot answer a later dispute — but it means retention is an operational decision for the operator of a deployment rather than a fixed period this page can quote.

A defined retention schedule, aligned to the legal and accounting requirements that apply, should be established before the service is used at scale. If you need data removed, ask through the contact page and we will tell you what is possible.

11. How it is protected

Each merchant's data is scoped to that merchant and is not reachable by another account. Secrets held by the platform are encrypted at rest, and API keys and webhook secrets are stored as hashes or ciphertext and shown only once.

Payment evidence is stored outside the web root and served only to the owning merchant through an authenticated request.

More detail is on the security page.

12. Access and correction

You can view and correct your business profile, payment accounts, API keys and webhook endpoints in the console at any time.

For anything you cannot change yourself — including a request to access or remove information — get in touch through the contact page.

13. Changes

We will update this policy as the product changes. The current version is always the one published here.