Privacy Policy

This Policy applies when Noshva handles personal information through the Services. It can apply to website visitors, prospective Restaurants, Restaurant owners, administrators, managers and staff, scanner operators, restaurant Customers, pseudonymous and Google-linked Rewards users, and people who contact support.

Noshva

The service or trade name used for the Services.

Restaurant

A participating restaurant or restaurant organization that uses or provides experiences through Noshva.

Business User

A Restaurant owner, administrator, manager, staff member, or other authorized person using Restaurant tools.

Customer

A restaurant guest, public visitor, or person using a Noshva Rewards experience.

Location

A Restaurant location configured in the Services.

Rewards

Restaurant-configured digital stamp, reward, and redemption experiences supported by Noshva technology.

Services

Noshva websites, public restaurant pages, digital menus, Rewards experiences, Restaurant Dashboard, scanner and operator experiences, Pilot access requests, and related support and web services.

Restaurant Content

Information, media, settings, links, offers, and other material a Restaurant supplies or configures.

“Personal information” means information about an identifiable individual or information treated as personal information under applicable law. Information can remain personal information even when it uses a code rather than a name. This Policy should be read with the Terms of Service.

The information Noshva handles depends on the feature, the person’s role, and how a Restaurant configures its workspace. Categories can include:

• Account and profile information: account identifiers, email address, display name, profile image, authentication provider, account status, and account timestamps.
• Restaurant and team information: Restaurant and Location details, role and permission scope, memberships, invitations, inviter or accepter identifiers, device and operator records, and administrative activity.
• Pilot access-request information: name, contact email, business name and type, role, Restaurant location, referral source, links, and optional notes submitted in a request.
• Rewards identity and activity: public customer code, a hashed server-side verifier, linked account identifier, pseudonymous or saved status, last-seen and merge information, stamp balances, lifetime totals, event history, corrections, reward and redemption details, Restaurant staff or device actor information, and loyalty activity statistics.
• Restaurant Content: menu information, item and category details, prices, dietary or allergen labels, images, branding, public links, location information, hours, and Rewards settings.
• Usage and analytics information: page and action counts, table or QR context, menu item and category interactions, time buckets, operational Rewards counts, and generated aggregate or customer-level insights.
• Security and technical information: session and access tokens, device records, sign-in and operator-attempt information, status and expiry values, error and security events, and browser, device, network, request, or log information handled by Noshva or its providers.
• Support information: the message and contact details a person chooses to provide by email or, when offered, support chat.
• Conditional billing information: organization and billing-owner identifiers, billing status and audit details, and provider customer, subscription, product, or price identifiers in authorized test billing flows. Live Stripe billing is not currently implemented.

Where information comes from

Noshva receives information directly from people who use the Services; from Restaurants and authorized Business Users; from authentication, hosting, anti-abuse, support, and other providers; and from operation of the Services. Noshva also generates records such as identifiers, permissions, ledger events, counts, status values, and security records. Some feature inputs stay on the device as explained below.

Public Restaurant registration is currently Google-first, and Customers can use Google to save and recover Rewards. Google/Firebase processes authentication credentials and tokens. Noshva receives the account identifier and profile information needed to provide the Services, which can include email address, display name, profile image, provider information, and account status.

An eligible Restaurant account created with Google can later add password access. When that user signs in with a password, the credential is processed transiently through Noshva’s login infrastructure and sent to Google/Firebase for validation. Noshva does not store a raw password in its application records. Firebase authentication can persist in the browser, and Noshva uses a separate session cookie to operate the signed-in web session.

Signing out clears the Firebase browser authentication state and Noshva session used by the sign-in flow. It does not revoke a person’s separate Google account session and does not remove the local Rewards proof described next.

Starting Rewards without Google can create a pseudonymous customer record, code reservation, card, balance, event history, and activity statistics. The browser keeps a public code and proof in local storage so it can reconnect to the record. The displayed staff-scanning QR contains the public code, not the secret proof, and a public code alone does not restore the card on another device.

The local Rewards proof remains on the device after signout unless browser storage is cleared or another applicable control is used. A guest-expiry value does not automatically delete the record. Saving Rewards with Google can make them recoverable on other devices and may merge a pseudonymous record into the linked record. Source records, cards, statistics, event history, and merge lineage can remain for integrity rather than being erased by the merge.

Some redemption mechanics require Rewards to be saved to a Google-linked account before a temporary redemption QR can be created. Restaurant staff then use that temporary or presented code to perform the authorized Rewards action.

Noshva uses information as reasonably needed to:

• create and operate accounts, sessions, Restaurant workspaces, Locations, roles, devices, and operator access;
• present public Restaurant pages, menus, Restaurant Content, links, and Rewards experiences;
• record stamps, corrections, balances, redemptions, merge activity, and related Rewards integrity records;
• produce Restaurant-scoped operational views, usage measurements, and analytics;
• review Pilot access requests and communicate about a submitted request;
• provide support when a support channel is configured and used;
• authenticate users, prevent abuse and fraud, investigate errors, secure the Services, and enforce authorized access;
• maintain, troubleshoot, improve, and administer the Services; and
• meet legal obligations and establish, exercise, or defend legal rights where applicable.

A materially new or incompatible purpose may require additional notice, choice, or consent under applicable law. Noshva does not rely on this Policy as permission for every possible future use.

Authorized Restaurant users can see information needed to operate their workspace. Depending on role and feature, this can include pseudonymous customer identifiers, whether Rewards are pseudonymous or saved, first and recent activity, operation and redemption counts, recent event types and times, balances, and lifetime activity for the relevant Location.

When a Customer presents a valid global public code to an authorized scanner, the scanner can show that code, a Google display name when linked, and limited account or saved-status information even if the Customer has no card at that Location. Balances and Rewards history returned through that lookup are scoped to the scanner’s current Location; it does not expose another Restaurant’s balances or history through that view.

Restaurants control their own Restaurant Content, team access, devices, operator names, and Rewards program settings. A Restaurant is separately responsible for the information it independently collects, decides to enter, displays, or uses, including complying with its own notice, consent, food-service, employment, and customer obligations. The legal allocation between Noshva and a Restaurant can depend on the activity and applicable law.

Help Me Choose

Appetite, dietary, spice, category, and free-text allergen choices in Help Me Choose are evaluated through deterministic menu-matching logic in the browser and held in transient page state. Those answers and the allergen text are not sent to Noshva’s server. The feature can send generic opened and result-clicked counters, without the answer text.

My Picks

My Picks stores selected menu item keys in local storage for the relevant Location until they are cleared, overwritten, or browser storage is removed. The feature includes a clear control.

QR camera

When an authorized user chooses camera scanning, camera media is processed in the browser to decode a QR value. The photo or video stream is not uploaded to Noshva; the decoded QR text is used to continue the requested scanner action. Browser and operating-system permission controls still apply.

Noshva first-party measurements

Noshva records contextual interaction counts for public restaurant experiences, such as page, action, table or QR, menu item and category, and Rewards activity. The application analytics payload is designed not to include a Noshva user ID, customer ID, email address, IP address, or user-agent value. Infrastructure providers may still process request, network, device, or log information when delivering the event.

Counts can be stored by hour or other context and used in Restaurant Dashboard views. Some loyalty insights suppress small ranking or return-gap cells, but other contextual counts can be as low as one. “Aggregate” does not necessarily mean anonymous, particularly where a small group or table context could be inferred.

Google Analytics for Firebase

Google Analytics for Firebase can initialize in a supported browser when the relevant configuration is present. If operating, Google may process browser, device, network, interaction, cookie, or similar information under the applicable configuration and Google’s practices. Its operation, identifiers, cookie behaviour, settings, and retention depend on the applicable configuration.

Noshva and its providers use browser or device storage for different purposes. Depending on the feature, this can include cookies, local storage, session storage, and software-development-kit persistence.

• Authentication and security: Firebase browser persistence, Noshva account sessions, scanner-device and operator sessions, anti-abuse state, and temporary authentication or save-card intents.
• Rewards access: the persistent public-code and secret-proof pair used to reconnect the browser to a pseudonymous or saved Rewards card.
• Preferences and functionality: My Picks, theme preference, Dashboard context, product-tour state, billing-watch state, and progressive-web-app update or reload state.
• Measurements and performance: first-party analytics deduplication and Dashboard analytics cache, plus conditional provider analytics described above.

Some storage is essential to the feature a person chooses; other storage supports preferences or measurement. Clearing browser storage can sign a person out, remove preferences or a local Rewards proof, prevent reconnection to a pseudonymous Rewards card, or otherwise reset a feature. Browser controls may not remove corresponding server records.

Noshva uses or has implemented connections to the following providers and services:

• Google/Firebase for authentication and core application infrastructure, including account and application records, media storage, and server processing.
• Vercel for hosting and delivery of the main web application, request processing, and related operations.
• Cloudflare Turnstile, when configured, on certain login and request forms to help prevent automated abuse. Cloudflare may process challenge, browser, device, and network signals; Noshva receives the verification result.
• Telegram, conditionally, when access-request notifications are enabled. Telegram then receives a limited notification containing substantive submitted contact, business, role, Location, referral, link, note, and source fields, as applicable—not the complete stored record.
• Tawk.to, conditionally, if support chat is offered and a person chooses to open it. The chat script loads after that action and may process chat content and browser, device, network, or cookie information under its practices.
• Stripe, test-only, as a billing foundation. Live Stripe billing is not implemented. If an authorized test flow is invoked, Stripe can receive verified billing contact and organization information; payment details are entered on a Stripe-hosted page rather than into Noshva application fields.

Restaurants may also provide links to independent maps, websites, social networks, review services, messaging services, or other destinations. Following a link is user-directed navigation to that destination; it does not by itself make the destination a Noshva service provider. The destination’s own terms and privacy practices apply.

Some Firebase server functions are configured for Montréal. That configuration does not establish the deployment or location of all functions, databases, authentication, storage, hosting and content-delivery systems, logs, support access, backups, or onward provider processing. Provider, account, and deployment configurations can affect where processing occurs.

Noshva does not apply one period to every record. Information is kept only for as long as reasonably needed for the purposes described in this Policy, subject to applicable law. Relevant criteria include the life of the account, Restaurant relationship, feature, session, or Pilot; the need to operate and secure the Services; Rewards and ledger integrity; fraud and abuse prevention; troubleshooting; dispute handling; recordkeeping and legal obligations; and whether deletion, de-identification, or aggregation is reasonably available.

Different records can therefore have different lifecycles. Session, live-signal, and some audit records have expiry or retention settings, while many account, Rewards, analytics, content, billing, and operational records currently have no automatic deletion rule. A displayed analytics history window, invitation expiry, redeem-token expiry, or guest-expiry value is not necessarily a server-deletion period.

When information is no longer reasonably required, Noshva handles it as appropriate to the information and applicable law, which may include deletion, de-identification, or aggregation.

Signing out, ending access, removing a Location, merging a Rewards identity, or deleting selected Restaurant resources does not necessarily delete every related customer, ledger, analytics, reservation, audit, upload, support, security, backup, or provider record. Noshva should not be understood to promise immediate or complete deletion where no such process is available or where retention is permitted or required.

Noshva uses technical safeguards and access controls designed for the nature of the Services. Current safeguards include permission and role checks, tenant and Location scoping, server-side data access, restricted public database and media rules, hashed server-side customer and device verifiers, limited-duration sessions, host-only and HTTP-only account session cookies, and local camera processing.

No system, transmission, browser storage, provider, or security control is completely secure. Noshva cannot guarantee that information will never be accessed, used, lost, or disclosed improperly. Users should protect accounts, devices, PINs, QR links, Rewards proofs, and sessions, and should report a suspected compromise through any support option currently made available.

Depending on where a person lives and the circumstances, applicable privacy law may provide rights to ask whether Noshva holds personal information, request access or correction, obtain certain portable information, withdraw consent for a consent-based use, request deletion or other treatment where legally available, or raise a question or complaint.

These rights are not absolute. Noshva may need to verify identity and authority, identify the relevant Restaurant or Rewards record, protect another person’s information, preserve information required for legal, security, fraud, ledger-integrity, or dispute purposes, or apply another lawful exception. Withdrawing a necessary permission can affect the related feature.

No self-service account-closing, export, correction, or deletion tool is currently offered. To make a privacy request, use an available support method in the Contact section and provide enough non-secret context to identify the relevant service and record. Do not send a password, PIN, or Rewards proof.

The current Services do not ask for date of birth and do not implement a general age gate, age-verification process, or dedicated guardian-consent workflow. No universal minimum age is set in this Policy; capacity and consent requirements depend on jurisdiction and context.

A person who requires parent or guardian authorization under applicable law should use the Services only with that authorization. A parent or guardian who believes a minor’s information has been handled through Noshva can use an available support method below to describe the concern without sending sensitive credentials.

The current Services do not include a Noshva-operated third-party advertising network or a feature designed to sell personal information to third parties for their own targeted advertising. Noshva does use service providers, contextual interaction measurements, Restaurant-selected external links, and conditional provider analytics as described in this Policy. Whether a particular practice has a defined legal label depends on the facts and applicable law.

Noshva does not currently offer an email, SMS, or push-marketing campaign sender. A Restaurant’s communications outside Noshva are the Restaurant’s responsibility unless Noshva is separately involved in the sending or handling.

Noshva may preserve, use, or disclose information where reasonably necessary to comply with applicable law or valid legal process; respond to a lawful request; investigate and prevent fraud, abuse, security incidents, or unauthorized access; protect users, Restaurants, Noshva, providers, or the public; enforce applicable terms; or establish, exercise, or defend legal rights. Noshva will limit these actions where applicable law requires.

Noshva may update this Policy prospectively as the Services, practices, or legal requirements change. The page will show a new “Last updated” date. Noshva will provide additional notice of a material change where appropriate or required by law and will seek additional consent where applicable law requires it. An update does not authorize incompatible handling that requires a separate legal basis or consent.

This Policy was last updated on August 15, 2026.