Privacy that matches how PayMyQR actually works

1. Who we are and how this policy works

PayMyQR is the publisher and operator of the PayMyQR app and this landing site. This Privacy Policy explains what information PayMyQR may process, why it is processed, when it may be shared, and what choices and rights you may have under applicable law, including Indian law and, where relevant, frameworks such as the GDPR and California privacy law.

PayMyQR is designed around a local-first model. In normal use, much of the content you create or manage in the app is intended to stay on your device or in storage locations you choose. That said, PayMyQR is not a zero-third-party product. Depending on the features you use, third-party services such as Google Play Billing, Google Mobile Ads, Android system services, or your chosen storage provider may also process limited information under their own terms and privacy policies.

2. Information PayMyQR may process

Depending on the features you use, PayMyQR may process the following categories of information:

• Information you enter directly, such as profile names, UPI IDs, contact details, QR content, links, email addresses, WhatsApp numbers, bank-related profile details, business-card content, notes, reminders, and utility labels.
• Camera input, imported images, scanned QR content, document captures, and image-based autofill data when you use capture, scan, vault, or document features.
• Microphone or speech input when you choose optional voice-driven capture or todo features.
• Contacts data when you choose to import contacts into PayMyQR flows.
• SMS content, message metadata, and transaction-related details when SMS-based financial parsing or payment confirmation is enabled.
• Notification content if you enable Android notification-listener access for payment or financial-detection features.
• Calendar data when you choose reminder or event-sync flows.
• Files, exported archives, imported backups, and user-selected storage destinations for import, export, backup, restore, or vault-related workflows.
• Vault password entries you choose to store, including site domains or URLs, usernames or email addresses, passwords, optional labels or notes, and optional links between an Android app package name and a website domain when you use password-manager or assisted-capture features.
• Investment and portfolio information you choose to import or sync, including holdings positions (such as mutual funds, equities, government securities, alternative investments, insurance wrappers, or NPS where supported), scheme or instrument identifiers, folio or account references, quantities, cost or average price, last-known prices or NAVs, profit and loss figures, transaction history derived from statements, and aggregated Net Worth totals computed on your device.
• Broker connection metadata when you authorize read-only portfolio sync, including OAuth tokens, session identifiers, broker profile hints, and cached holdings responses needed to refresh prices or positions you request.
• Consolidated Account Statement (CAS) PDF files and the decryption credentials you supply (such as PAN or PAN combined with date of birth) when you initiate a CAS import. These are used solely to decrypt and parse the statement you selected.
• Technical and entitlement information needed for app security, app integrity, purchase status, subscription handling, ad eligibility, backup metadata, and feature availability.
• Splits cloud sync (optional): when you use the cloud split-sync feature, your split group data — including member display names, member Google account identifiers, expense descriptions, amounts, currency, and timestamps — is stored in Google Firebase Firestore (hosted in the United States). This data is stored until you delete the group or disable cloud sync.
• Firebase anonymous session (Splits cloud sync): when you first use cloud split-sync, an anonymous identifier is created at Firebase (Google) to authenticate your device. If you sign in with Google, your Google account is linked to this identifier. This identifier persists until you revoke cloud sync in app settings.
• BBPS bill-pay records: when you pay a bill using the in-app BBPS feature, a payment order record is created containing secured references to your mobile number and bill consumer number (no full numbers stored), payment amount, currency, and order status. These records are retained for up to three years for dispute resolution and reconciliation.
• DigiLocker session and audit records: when you link DigiLocker, an encrypted session record and an audit log of document-access events are stored on PayMyQR's backend. Audit records are retained for up to one year; inactive session tokens are deleted after ninety days.
• Claim Connect (employer-linked expense claims): if your employer uses Claim Connect, your work email address and expense claim payload (amounts, categories, receipts you submit) are stored on PayMyQR's backend linked to your employer's tenant. Resolved claims are retained for up to three years; revoked or pending employee links are deleted after one year.

3. Why we process information

PayMyQR processes information only for feature and operations purposes that are reasonably connected to the app, including providing QR, overlay, vault, capture, financial tracking, payment confirmation, backup, restore, reminder, and monetization functionality.

• To create, display, edit, secure, export, restore, and delete user content inside the app.
• To detect and confirm relevant financial events, transaction states, and payment-related activity.
• To support user-requested imports from SMS, notifications, contacts, images, audio, or files.
• To provide premium purchases, subscriptions, entitlement restoration, ad-free access, and related customer support.
• To show ads in supported versions of the app.
• To maintain app security, prevent abuse, diagnose failures, and comply with legal obligations.
• To store, fill, and update login credentials you explicitly save in Vault, including through optional Android Autofill and assisted capture flows you initiate.
• To fetch, normalize, display, and refresh investment holdings and Net Worth summaries you request, including through read-only broker connections and CAS statement import flows you initiate.
• To orchestrate transient parsing of CAS PDFs through secure backend infrastructure and return normalized portfolio data to your device for local storage.

Where applicable law requires a legal basis, PayMyQR may rely on consent, performance of a contract or requested service, legitimate interests in secure and responsible operation, and compliance with legal obligations.

4. Permissions and sensitive access

PayMyQR may request Android permissions or sensitive access only when those permissions are tied to a current feature offered in the app. Permissions are intended to support the feature you choose to use, not broad unrelated collection.

• Camera: used for QR scanning, profile capture, vault capture, card capture, and document/image workflows.
• Microphone: used for optional speech and voice-input features.
• Contacts: used only when you choose to import or use contact-based flows.
• Calendar: used only when you choose reminder or event-sync features.
• Notification access: used only if you enable financial or payment-related notification parsing features.
• Storage and file access: used for import, export, backup, restore, and user-selected file handling.
• Autofill service (optional): if you enable PayMyQR as your device’s Autofill provider in Android settings, the app may offer to fill or save login fields in other apps through the platform Autofill framework when you use those apps. PayMyQR does not use Accessibility services or screen recording to read login fields in other apps.

If you deny or later revoke a permission, the related feature may stop working, may work in a limited mode, or may become unavailable. Other parts of the app may continue to function depending on the feature and app configuration.

5. Vault passwords, assisted capture, and Autofill

PayMyQR Vault can act as a local password manager for credentials you choose to store. This section describes how assisted password capture works and what PayMyQR does not do.

• Local storage: passwords and related login metadata are stored on your device as part of your Vault content, subject to your Vault security settings (such as passcode or biometric unlock). PayMyQR does not sell vault passwords or use them for advertising personalization.
• Manual entry: you may type or paste site, username, and password details yourself.
• Assisted website capture: if you choose “Browse website,” PayMyQR opens an in-app browser. You navigate to sign-in pages yourself. Credentials are read from that in-app page only when you tap an explicit action such as “Save login.” PayMyQR does not monitor browsing in the background or read pages you do not choose to save.
• Assisted app capture: if you choose “Pick app,” you may launch another app and complete sign-in there. Saving typically occurs through Android’s Autofill save prompt after you submit a login form, or through a link-only entry you confirm in Vault when you choose to save an app association without a password yet.
• User control: capture happens only when you start a Vault flow and confirm a save action. PayMyQR does not silently harvest credentials from Chrome, other browsers, or other apps outside the Autofill framework.
• Multi-step sign-in: some websites (for example Google or Microsoft) show email and password on separate screens. You may need to continue to the password step before saving. PayMyQR may show guidance when a password field is not yet present on the current page.
• Third-party sites and apps: when you sign in to a third-party service inside Vault or through Autofill, that service’s own terms and security practices also apply. Some providers limit or discourage sign-in inside embedded browsers.
• Broker login auto-fill (optional): when you connect an investment broker such as Angel One, you may opt in to saving that login — client code, PIN, and the TOTP (two-factor) secret — into your encrypted Vault so PayMyQR can auto-fill it and generate the time-based code on later connections. This is strictly opt-in: nothing is saved unless you tick the “Save to Vault” option, and saved broker logins are protected by your Vault unlock (passcode or biometric) like any other Vault item. The TOTP secret is decoded only transiently in memory to compute the current code and is never transmitted off-device. You can delete a saved broker login from Vault at any time.

If you disable PayMyQR as your Autofill provider or revoke related permissions, autofill and assisted app-save features may stop working while manual Vault storage may still be available depending on your configuration.

6. Investment holdings, Net Worth, and CAS import

PayMyQR may offer optional features that help you view a consolidated picture of investment holdings and Net Worth on your device. These features are informational and user-initiated. PayMyQR is not a stock exchange, broker, depository participant, mutual-fund distributor, investment adviser, research analyst, or portfolio manager, and displayed values are not a recommendation to buy, sell, or hold any security.

6.1 What these features do

• Net Worth display: the app may aggregate holdings, loans, crypto, and other categories you choose to track into summary totals and breakdowns for your personal reference on your device.
• Read-only broker sync: where supported, you may connect a third-party broker account (such as Upstox or Angel One) through that broker’s authorized login or OAuth flow. PayMyQR uses read-only access to retrieve holdings and related market data needed to populate your portfolio view. PayMyQR does not place trades, modify orders, move funds, or operate a brokerage account on your behalf.
• CAS (Consolidated Account Statement) import: you may upload a mutual-fund CAS PDF from your device and supply the password required to open it (commonly your PAN or PAN plus date of birth, as required by the statement issuer). The app sends the PDF and password over encrypted transport to PayMyQR’s backend orchestration layer, which forwards the file for parsing on isolated parsing infrastructure. Parsed holdings and related metadata are returned to your device and stored locally in your portfolio database. Support is limited to statement formats handled by the parsing engine (currently CAMS/KFintech mutual-fund CAS in supported builds); demat or other statement types may not be supported.
• Local portfolio store: normalized holdings used for Net Worth are intended to be stored primarily on your device. Server-side storage, where used, is limited to orchestration needs such as rate limiting, device-bound session handling, and optionally sealed import metadata — not a permanent cloud portfolio ledger.

6.2 Sensitive handling of CAS passwords and PDFs

• CAS decryption credentials are used only to unlock and parse the PDF you selected for that import request. PayMyQR’s policy is not to log, persist, or reuse CAS passwords after parsing completes.
• CAS import screens may use platform safeguards (such as screenshot blocking) while sensitive content is visible. You remain responsible for choosing a private environment when entering statement passwords.
• You should import only statements relating to accounts you own or are lawfully authorized to access.

6.3 Third-party brokers, registrars, and market data

Broker connections, registrar formats, statement issuers, and market-data sources are operated by independent third parties under their own terms, privacy policies, and regulatory frameworks. When you connect a broker or import a CAS file, those third parties may also process information according to their policies. PayMyQR does not control third-party availability, accuracy, latency, or API changes.

Prices, NAVs, day change percentages, XIRR or return metrics, and other calculated fields may be delayed, estimated, incomplete, or based on last-synced values. Displayed figures are provided for convenience and may differ from official broker, registrar, AMC, or tax records.

6.4 Infrastructure involved in holdings processing

• On your device: portfolio rows, import results you keep, and Net Worth calculations derived from local data.
• PayMyQR backend: session issuance, upload orchestration, normalization, optional sealed storage of import payloads, and broker proxy calls you initiate. Backend routes use scoped authentication separate from other app modules where implemented.
• Isolated parsing infrastructure: transient PDF parsing for CAS imports. PDF bytes are processed in memory for the parse operation and are not intended to be retained as a user file archive by PayMyQR after processing completes.

We do not use holdings content, CAS PDFs, broker holdings responses, or Net Worth totals for advertising personalization. We do not sell your portfolio data.

6.5 Retention, deletion, and your choices

• You may disconnect broker integrations, delete imported portfolio rows, clear app data, or uninstall the app to remove local holdings from your device, subject to normal Android and backup behavior.
• Where server-side import metadata exists, it is retained only for as long as reasonably necessary to support the feature, security, abuse prevention, and legal compliance, after which it is deleted or rendered inaccessible according to operational schedules.
• If you revoke broker authorization at the broker or in PayMyQR, new syncs stop; previously stored local rows may remain until you delete them.

6.6 Data you enter about family or household members

PayMyQR lets you organize the holdings, plans, PAN, and tax details of family or household members alongside your own, so you can track a household's finances in one place. This is a personal record-keeping feature; PayMyQR is not a portfolio management service and does not manage anyone's money (see the Terms, Section 5.7).

• What is processed. Information you choose to enter or import about another person — such as their name, relationship, PAN, holdings, plans, income, statements, and derived tax estimates — is processed on your device to attribute that data to the correct person and compute their household view.
• Where it lives. This data is stored locally on your device under your single account. A PAN (yours or a family member's) is stored encrypted on the device and is not required to be transmitted to us for these features to work. We do not create separate accounts or logins for family members.
• You are the source and the controller of consent. You decide what to record about others. When you add another person's data you confirm you have their informed consent and the lawful authority to provide it, as required by the Digital Personal Data Protection Act, 2023. For a child or a person under guardianship, you confirm you are the parent or lawful guardian. PayMyQR processes this data on your instruction and on your device; it does not independently collect it from the family member.
• Honouring their rights. Because the data lives on your device under your control, requests by a family member to access, correct, or delete their information are handled by you within the app (edit or delete the person, their plans, holdings, or PAN). You are responsible for responding to such requests.
• Deletion. Deleting a person in People, clearing their holdings/plans, clearing app data, or uninstalling removes the corresponding local data from your device, subject to normal Android and backup behavior. Encrypted PAN entries are excluded from cloud backups.

7. SMS: reading, sending, and PayChat

7.1 Reading SMS (READ_SMS)

PayMyQR requests READ_SMS access because SMS-based payment and transaction detection is a core feature. When you use payment QR or financial-tracking flows, PayMyQR may read relevant transaction-related SMS messages on your device to help detect whether a payment was completed, credited, debited, settled, or updated by a bank, UPI provider, card issuer, or other financial institution.

• PayMyQR processes SMS-derived financial information primarily on-device.
• We do not request READ_SMS access for advertising, unrelated profiling, or generic marketing.
• We do not knowingly sell SMS content.
• Because Android permission controls may grant broader technical access than a single message, our policy is to use SMS read access only for the limited financial and payment-confirmation purposes described above.

If READ_SMS permission is denied or revoked, payment or transaction confirmation features may not work correctly or may be unavailable.

7.2 Sending SMS (SEND_SMS) and PayChat

PayMyQR also requests SEND_SMS permission to enable PayChat, a peer-to-peer payment messaging feature. If you grant SEND_SMS, the app may send app-originated SMS messages directly from your device and SIM to phone numbers you have stored for your contacts in the app. You are the sender; PayMyQR acts on your behalf using your SIM, your phone number, and your device.

App-originated outbound messages may include:

• Your own payment details (UPI ID, pay link) when you choose to share a payment profile or introduce yourself to a contact.
• Split-request notifications sent to split-group members when a new expense is added: expense description, total amount, the recipient's calculated share, and a UPI pay link.
• Payment receipt confirmations sent when you mark an incoming payment as received in the app.
• UPI payment sent confirmations when a UPI payment is completed within the app.

Outbound messages contain only your own payment details. The app is designed so that a recipient's own personal data is never sent back to them in an outbound SMS — this is a deliberate design safeguard under DPDPA 2023 and IT Rules 2021 to prevent accidental data exposure if an incorrect phone number has been stored. Custom freeform user-typed text cannot be sent as SMS directly through the app; only structured, app-originated messages are dispatched via SEND_SMS.

If you deny or revoke SEND_SMS permission, the app falls back to sharing via WhatsApp, your default SMS app (compose mode requiring manual send), or clipboard. PayChat conversation history continues to work; only direct automated send is affected.

7.3 Inbound PayChat SMS and local storage

When the app detects an inbound PayChat SMS from a phone number that matches one of your stored contacts, it may store the message text, sender phone number, and timestamp in a local on-device database, associated with the relevant contact. This stored content is used solely to display PayChat conversation threads in the app.

Inbound PayChat message content is not transmitted to PayMyQR servers. It remains on your device unless it is included in a backup or export you initiate.

7.4 PMQ profile deep-link marker

When you share a QR profile via PayChat, the SMS body includes a structured app deep link in addition to human-readable payment details. This link encodes your profile name, UPI ID or other identifier, and profile type. A future version of PayMyQR may offer a recipient the option to import your payment details automatically when this link is recognized in an inbound SMS or RCS message. No additional personal data beyond what you chose to include in that profile is encoded in the link.

7.5 Wrong-number and data-protection considerations

SMS is a best-effort delivery mechanism. PayMyQR sends messages to the phone numbers you have stored for your contacts. If a stored number is incorrect, the SMS — including your payment details — may reach an unintended recipient. You are responsible for ensuring the accuracy of phone numbers in the app. Under DPDPA 2023 and applicable privacy law, you hold responsibility for personal data you choose to transmit via SMS and should verify contact details before using SMS-based payment sharing for sensitive information. PayMyQR is not liable for delivery to wrong numbers resulting from data you entered or imported.

7.6 Bank account verification via SMS signals

When you add a bank account to PayMyQR, the app can mark it as verified if it detects a genuine transaction SMS on your device whose account last-4 digits and bank name match that account. This confirms only that your device receives that account's bank SMS — it is a visibility signal, not a legal proof of ownership. Verification matching happens entirely on-device; the matched SMS content is processed as described in section 7.1 and is not transmitted to PayMyQR servers for this purpose.

Because banks in India commonly register a single mobile number for several family members' accounts, you can label each account you add as your own or as family / other. A family account may verify under the relative's name when your device receives its SMS. The verified badge shown in the app states whose account it is and never implies that you own it.

7.7 Account-number + IFSC ("ifsc.npci") payments

PayMyQR can let you pay a bank account directly using the National Payments Corporation of India (NPCI) Account+IFSC virtual address format (<account>@<IFSC>.ifsc.npci). When you choose this, PayMyQR constructs a standard upi://pay request and hands it to a UPI app you select on your device; PayMyQR does not move money and is not a payment system or payment aggregator. The receiving UPI app or rail may return the bank-registered holder name for the account so you can confirm you are paying the right person. Support for this address format varies between UPI apps, so the payment is best-effort and may be declined by some apps. PayMyQR does not store other people's account numbers other than what you yourself enter for a saved account.

7.8 Verified-account signals over PayChat (where available)

Where this feature is made available, PayMyQR can include, inside an encrypted, signed PayChat message to another PayMyQR user, a signal that your own verified account is SMS-verified. This is sent only for accounts you have labelled as your own and that are verified; family or unspecified accounts are never broadcast. The encrypted payload carries only display details (your name, bank, and the last 4 digits) and a signed commitment that lets the recipient verify authenticity — your full account number and IFSC are never transmitted. Recipients who do not use PayMyQR cannot read this content; their phone shows only the ordinary human-readable message. Received signals are stored encrypted on the recipient's device. A "verified" indicator means only that the other user's app asserts their own account passed on-device SMS verification; it is not an identity check, a creditworthiness check, or a statement that the person is trustworthy.

8. Ads, billing, and third-party services

Some versions of PayMyQR may display ads. If ads are enabled, Google Mobile Ads (AdMob) may process technical information associated with ad delivery, fraud prevention, and measurement. Users who are under 18 years of age have ads disabled; no ad request is made for those users. PayMyQR does not use your SMS content, contact imports, vault passwords, or payment details for advertising personalization.

If you use paid features, purchases, subscription handling, entitlement restoration, and billing-related status may be processed through Google Play Billing or related platform infrastructure. Payment instruments and store-managed purchase records are handled by Google or other platform providers under their own terms.

PayMyQR may also interact with user-selected storage providers, Android system services, email or messaging apps, sharing targets, and other third-party services when you choose to export, share, back up, restore, or otherwise connect the app to them. Those services remain subject to their own privacy policies and security practices.

8.1 Third-party data processors

The following third-party processors may handle data on PayMyQR's behalf depending on the features you use:

• Google Firebase Firestore (Google LLC, USA) — stores split group sync data (member names, Google IDs, amounts) when you use cloud split-sync. Governed by Google's Terms of Service and Privacy Policy.
• Google Firebase Authentication (Google LLC, USA) — issues an anonymous device identifier and optionally links a Google account identity when you use cloud split-sync. Governed by Google's Terms of Service and Privacy Policy.
• Google Firebase Analytics — we do not collect or transmit Firebase Analytics data.
• Google AdMob (Google LLC, USA) — serves ads in the free version of the app for users aged 18 and above. Governed by Google's Privacy Policy.
• Amazon Web Services (AWS, USA) — isolated infrastructure used for transient CAS PDF parsing. PDF and password are processed in memory and not retained after parsing completes.
• Cloudflare (USA) — backend infrastructure and data storage for DigiLocker sessions, DigiLocker audit logs, and BBPS order records.
• PhonePe Payment Gateway (PhonePe Pvt. Ltd., India) — processes payment collection for BBPS bill pay, including your mobile number and payment amount. Governed by PhonePe's Privacy Policy.
• BBPS fulfilment infrastructure (India) — bill fetch and payment fulfilment for BBPS transactions.
• Google Sheets API (Google LLC, USA) — used when you authorize PayMyQR to export your financial data to your own Google Sheets. Data is written to your own Drive account under your Google account's privacy settings. PayMyQR does not retain a copy of data exported this way.
• DigiLocker (Ministry of Electronics and Information Technology, India) — issues document access tokens when you choose to link your DigiLocker account. Governed by DigiLocker's privacy policy.

PayMyQR does not sell your personal data to third parties.

9. Sharing, backups, retention, and security

We do not treat your in-app content as something to commercially sell for cash. However, information may be disclosed when necessary to operate app features, respond to lawful requests, protect rights or safety, investigate abuse, complete a merger or restructuring, or support services you explicitly choose, such as export, sharing, or backup destinations.

Disclosure for unlawful use of PayChat or SMS features. If PayMyQR receives a lawful request, court order, summons, notice under the Information Technology Act, 2000 or IT (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021, direction from a law-enforcement agency, cybercrime unit, financial intelligence unit, TRAI, RBI, SEBI, or other competent authority relating to your use of PayChat, QR profile sharing, or any SMS dispatch feature — including in connection with alleged financial fraud, phishing, impersonation, criminal intimidation, or other unlawful conduct — PayMyQR may disclose available app usage records, metadata, and any other information in its possession to the extent required or permitted by applicable law, and without prior notice to you where advance notice is prohibited, impractical, or could prejudice a lawful investigation. Nothing in this policy limits PayMyQR's ability to proactively report credible evidence of financial crime or serious misuse to appropriate authorities.

PayMyQR includes backup, export, and restore features that may write encrypted or user-readable files to your device or to storage locations you choose. If you back up to your own cloud drive, folder, or storage provider, you are responsible for access control and account security for that destination.

Because the app is largely local-first, much of your information remains on your device until you edit it, delete it, export it, clear app data, or uninstall the app. We retain server-side information only for as long as reasonably necessary. Specific retention schedules:

• DigiLocker audit logs — deleted after 1 year on a rolling basis.
• DigiLocker session tokens — deleted after 90 days of inactivity.
• BBPS payment order records — retained for 3 years for dispute resolution and financial reconciliation, then deleted.
• Claim Connect resolved/rejected claims — retained for 3 years, then deleted.
• Claim Connect revoked or pending employee links — deleted after 1 year.
• Splits cloud sync data (Firestore) — retained until you delete the group or disable cloud sync. Tombstoned (soft-deleted) records are removed on group deletion.
• CAS import data — transient; deleted from server infrastructure after parsing completes.

We use reasonable technical and organizational safeguards appropriate to the app’s design, including local-first storage patterns and encrypted backup mechanisms in relevant flows. No method of storage, transmission, or device security is completely risk-free. To the fullest extent permitted by law, PayMyQR does not guarantee absolute security and is not responsible for losses caused by device compromise, malware, rooted or jailbroken environments, insecure device settings, your failure to protect passphrases or accounts, or third-party platform failures. Nothing in this policy excludes liability where exclusion is not permitted by applicable law.

10. Your rights and regional notices

Depending on where you are located and subject to legal limits and technical feasibility, you may have rights to access personal data, request correction, request deletion or erasure, withdraw consent, object to or restrict certain processing, request portability where applicable, and complain to a regulator or data-protection authority.

For local-only information stored on your device, many rights can be exercised directly by editing or deleting content in the app, revoking permissions, deleting backup files, clearing app data, or uninstalling the app. For server-side records (DigiLocker audit logs, BBPS order records, Firestore split data, Claim Connect records), contact our grievance officer below. We may request reasonable verification before acting on a request and may deny or limit requests where permitted by law.

• India (DPDP Act 2023): PayMyQR aims to provide notice, honour consent and applicable legal bases, use reasonable security safeguards, and support grievance or rights handling subject to legal exceptions and technical realities. Grievance Officer: Pawan Verma, contact@paymyqr.in. We endeavour to acknowledge grievances within 48 hours and resolve them within 90 days of receipt. Most rights over on-device data are self-service via the app; server-side record requests are handled by the grievance officer.
• EEA and UK: where GDPR or similar laws apply, PayMyQR seeks to provide transparent notice of controller identity, purposes, legal bases, recipients, retention, international-processing implications, and available rights.
• California: if California law applies, you may have rights such as the right to know, delete, and receive equal treatment for exercising privacy rights, subject to the limits and exceptions allowed by law.

11. Children, international use, policy changes, and contact

PayMyQR collects date-of-birth (year only) during onboarding to determine whether a user is under 18. Users confirmed as under 18 are classified as minors: advertising is fully disabled and no ad request is sent to any ad network; a parental-consent notice is shown at onboarding asking a parent or guardian to review this Privacy Policy and complete setup on the minor's behalf. Parental consent for full feature access can be granted by a parent or guardian emailing contact@paymyqr.in from a verified adult email address.

If you believe a child has provided personal data contrary to applicable law, or if you are a parent or guardian who wishes to review, correct, or delete a child's data, contact us and we will review the request in line with applicable legal requirements, including the DPDP Act 2023 for Indian users.

If third-party services are involved, including app-store, billing, ad, device-platform, or user-selected cloud-storage services, information may be processed outside your country of residence, subject to the legal mechanisms and safeguards applicable to those providers.

We may update this Privacy Policy from time to time to reflect app changes, legal developments, or operational requirements. The updated version becomes effective when posted here unless a different date is stated.