Privacy Policy

This Privacy Policy explains how CATHOLICORE LLC, the operator of Cashless Cafeteria, handles information through the public website, school administration portal, cafeteria point-of-sale tools, family portal, household wallets, payments, communications, support, and related services.

CATHOLICORE LLC, 51 Orange St, Stamford, Connecticut, USA. Privacy email: info@catholicore.com. Telephone: +1 475-300-6334. Support hours: Monday-Friday, 8:00 AM-5:00 PM Eastern Time, excluding company holidays. Expected acknowledgment: Within one business day. Security incidents: info@catholicore.com. Questions concerning school-controlled student, household, cafeteria, or education records should normally begin with the relevant school. Do not provide passwords, payment credentials, or unnecessary student records by email or telephone.

Schools generally determine why and how school, student, guardian, household, staff, cafeteria, and education-related records are used. Cashless Cafeteria processes those records to provide the service under the school’s instructions and applicable agreement.

CATHOLICORE LLC independently determines limited processing needed for its own account administration, subscription billing, security, fraud prevention, legal compliance, support, and service operations. The applicable school agreement and law determine whether CATHOLICORE LLC acts as a processor, contractor, school official, service provider, or independent business for a particular activity.

Required school roster fields: school and internal student identifiers, first and last name, grade, enrollment and active status, and household link.

Optional or school-configured profile and lifecycle fields: email address, date of birth, gender, profile photo, account link, withdrawal date, reason and responsible staff identifier, school-created notes, and created/updated timestamps and responsible staff identifiers.

Cafeteria and account records: lunch-card and barcode identifiers; meal selections; items, quantities, prices, timestamps, serving line, purchases and order history; household wallet balance, holds, allocations, top-ups, adjustments, refunds, disputes, and safe payment references.

Access and communications: invitations, guardian and household relationships, roles and permissions, notice acknowledgments, authorization or consent status, notification preferences and delivery status, privacy requests, and support communications.

Technical and security information collected automatically: IP address or minimized/hashed IP-derived identifiers, approximate location derived from IP, device type, browser, operating system, authenticated session and login records, timestamps, sanitized page paths and referrers, persistent session or security identifiers, rate-limit records, audit logs, and error or performance information.

Other user and school information may include school and account details; guardian and staff names, email addresses, telephone numbers, language and timezone preferences; roles and permissions; school configuration; imported files; support and demo inquiries; and payout-account verification details.

Operational information may include cafeteria catalogs, items, prices, menus, service lines, orders, purchases, wallet balances, holds, allocations, top-ups, adjustments, payment status and references, payout records, notification preferences and delivery status, support and demo requests, privacy requests, security incidents, audit records, and generated reports.

We receive information from schools and authorized staff, guardians and household users, students with authorized access, public website visitors, account and invitation workflows, file imports, cafeteria transactions, Stripe, email delivery systems, and the technical systems used to operate and secure the service.

Schools should provide only information they are authorized to manage and should review imported records, student access, and household relationships before making them active.

We use information to create and secure accounts; scope access by school, role, permission, and household; identify cafeteria buyers; operate checkout; manage wallets and pending holds; process and reconcile top-ups, subscriptions, and payouts; show history; deliver notifications; support lunch cards; generate reports; respond to inquiries and privacy requests; investigate incidents; prevent abuse; and maintain the service.

Student information is limited to these necessary operations: provide, secure, maintain, troubleshoot, and support the contracted cafeteria service; detect fraud, misuse, and account-security threats using minimized information; produce school-authorized reports and meet legal obligations; debug and improve service reliability and accessibility for the contracted service; measure reliability, capacity, accessibility, and feature use with aggregate or appropriately de-identified information subject to re-identification prohibitions. Identifiable Student Data is not available for general experimentation or general product analytics.

Information is not considered de-identified merely because names are removed. De-identification must address student, school, household, guardian and user identifiers; small cohorts and rare grades; exact timestamps and transaction patterns; photos, notes, email, date of birth, IP and device identifiers; free text; and linkability to source records. Cross-school analysis requires aggregate or appropriately de-identified information, minimum cohort controls, and contractual prohibitions on re-identification and recombination.

Access is scoped by school membership, assigned permissions, account status, household relationships, and the active school or portal context. Guardians, students, and household-linked users should see only records associated with their authorized relationships.

A person may hold multiple relationships, such as both staff member and guardian. The service uses each authorized relationship to determine which tools, household records, notifications, and transaction details the person can access. Schools are responsible for keeping those relationships and staff permissions current.

Stripe processes card and bank-account collection, saved payment methods, top-ups, subscription payments, connected payout accounts, disputes, and payment events. Cashless Cafeteria stores provider identifiers, safe payment-method details such as brand or last four digits, amounts, fees, statuses, timestamps, and reconciliation records.

To establish a school payout account, an authorized representative may provide legal business name, address, telephone number, tax identification number, representative name, title, contact details, full date of birth, government identification or Social Security information, ownership information, and identity-document images. These details pass through secured Cashless Cafeteria server routes to Stripe for verification. Cashless Cafeteria does not intentionally store full identity-document images or full tax or government identification numbers in its application database, but Stripe retains verification information under its terms and legal obligations.

Cashless Cafeteria does not intentionally receive or store full card numbers, card security codes, full routing numbers, or full bank account numbers. ACH top-ups remain recorded as processing without increasing the wallet until settlement succeeds.

We use Resend and in-app notifications for invitations, verification, password recovery, security events, purchases, low balances, account activity, payment results, support, contact inquiries, and demo requests. Resend processes recipient addresses, message content, action links when required, and delivery metadata.

For ACH top-ups, eligible household recipients receive email when the top-up succeeds, fails, or is canceled. We do not send a separate ACH-processing email. Users may control eligible optional notifications, but essential account, security, legal, or transactional messages may still be sent.

In production, we use Vercel Web Analytics for aggregated page and feature measurements and Vercel Speed Insights for performance measurements. Before custom analytics events are sent, the application removes query strings, URL fragments, and supported dynamic record identifiers and restricts values to approved categories. We do not intentionally send names, email addresses, school IDs, student IDs, household IDs, invitation tokens, payment references, or free-form text as analytics properties.

We use Sentry for sampled error and performance monitoring with default transmission of personally identifiable information disabled. Error context can still contain technical request or application details, so access, sampling, and redaction are controlled.

The service uses cookies or comparable authenticated-session mechanisms for sign-in and uses browser storage for language, timezone, guided-tour progress, and functional preferences. Audit-view results are cached only in the current browser tab session and expire after approximately five minutes.

During school onboarding, a resumable draft may be stored in the browser’s local storage and can include the administrator’s name, email, profile image, school name, address, logo, and settings. Passwords are excluded. The application removes a completed or expired draft when onboarding next runs; users can remove it sooner by clearing site data.

The staff student roster is kept in application memory and responses containing roster or student-detail information use private no-store controls; the complete roster is not written to localStorage or sessionStorage. Student pages and student audiences do not use product analytics or advertising storage. Stripe payment components used by adults may create provider-controlled security and payment-interface storage.

Authentication cookies: Supabase session identifiers and refresh material. Purpose: Keep the user signed in and rotate authenticated sessions. Lifetime: Provider-configured session lifetime or earlier sign-out/expiration. Deletion event: Sign-out, session expiration, or clearing site data.

Active-school cookie: The current school identifier. Purpose: Scope authenticated requests to the selected school. Lifetime: Until replaced, expired, or cleared. Deletion event: Cleared on sign-out or site-data clearing; replaced on school switch.

Language, timezone, and functional preferences: Locale, timezone, and display preferences. Purpose: Present localized dates, language, and interface settings. Lifetime: Until changed or site data is cleared. Deletion event: Preference reset or clearing site data.

Guided-tour, checklist, and onboarding state: Minimized-checklist markers and a resumable school-onboarding draft; the draft may include administrator and school setup fields but excludes passwords. Purpose: Resume setup and avoid repeating completed guidance. Lifetime: Until completion/expiry cleanup or site-data clearing. Deletion event: Completion, expiry cleanup, school switch/sign-out where applicable, or clearing site data.

Short-lived read and authorization-context caches: Audit-view results and minimized staff, dashboard, and family read-context tokens. Purpose: Avoid duplicate authorized requests and support reliable reads. Lifetime: Current tab with bounded expirations, generally five minutes or less. Deletion event: Physical removal on expiry/read, school switch, tab close, sign-out, or clearing site data.

Cafeteria catalog session cache: School menus, menu slots, item categories, items, prices, styles, and update timestamps. Purpose: Avoid an immediate duplicate catalog request. Lifetime: Current tab for approximately two minutes. Deletion event: Physical removal on expiry/read, school switch, tab close, sign-out, or clearing site data.

Country and state option cache: Public country and state names and codes; no student records. Purpose: Populate address-option lists without repeated requests. Lifetime: Current tab for up to 24 hours. Deletion event: Physical removal on expiry/read, tab close, or clearing site data.

Point-of-sale and line state: Selected serving line and in-progress operational state. Purpose: Keep the authorized POS workflow on the selected line. Lifetime: Current tab/session until reset, sign-out, or configured expiry. Deletion event: Workflow reset, school switch, sign-out, tab close, or clearing site data.

Authentication and checkout handoff flags: A password-recovery readiness flag and a safe local subscription-completion path; no password or payment credential. Purpose: Complete the requested recovery or subscription workflow. Lifetime: Current tab; subscription handoff expires after approximately 30 minutes. Deletion event: Workflow completion, expiry/read cleanup, sign-out, tab close, or clearing site data.

Operational analytics deduplication flag: A one-bit marker that an approved event was sent in the tab; no student or event property is stored in the marker. Purpose: Avoid sending the same approved operational metric twice in one tab. Lifetime: Current tab only. Deletion event: Sign-out, tab close, or clearing site data.

Stripe component storage: Provider-created anti-fraud, session, and payment-interface values. Purpose: Securely present and operate Stripe payment components. Lifetime: Controlled by Stripe and browser/provider settings. Deletion event: Provider expiry or clearing browser/site data.

We share information with the school or organization that manages the relevant account and with authorized users within the applicable school or household relationship. We also use: Stripe for payments and payout verification; Supabase for database, authentication, and storage; Vercel for hosting, Web Analytics, and Speed Insights; Resend for transactional email; Upstash for server-side caching, rate limiting, and idempotency; and Sentry for error and performance monitoring.

Stripe: Family payments, saved payment methods, refunds and disputes, school subscriptions, payout-account verification, and payment reconciliation. Information involved: Payment amount, status, household or customer reference, safe instrument details, and transaction context. Card and bank credentials are collected by Stripe.

Supabase: Database, authentication, sessions, row-level access controls, private file storage, and server-side data operations. Information involved: The student, household, cafeteria, authorization, account, audit, request, and operational records needed for the service.

Vercel: Application hosting, server execution, deployment infrastructure, operational logs, aggregated Web Analytics, and Speed Insights. Information involved: HTTP and device metadata and minimized operational measurements. Student pages and student audiences are excluded from product analytics.

Resend: Transactional delivery of invitations, account, security, balance, purchase, payment-result, privacy, and support messages. Information involved: Recipient email, safe display name, school and necessary message content, action link, and delivery metadata.

Upstash: Server-side rate limiting, idempotency, and bounded operational caching. Information involved: Minimized tenant-scoped identifiers and operational values with short expiration periods; sensitive key values are hashed.

Sentry: Sampled error reporting, release diagnosis, and performance monitoring. Information involved: Minimized technical context. Default PII transmission is disabled, and student records, request bodies, credentials, and free-text notes are prohibited.

Each provider receives only the categories needed for its defined function, subject to minimization, access, retention, deletion, security, and contractual use limits. We may also disclose information when legally required; to protect users, schools, the service, or others; to investigate fraud or security incidents; during a protected business transaction; or with documented authorization.

We do not sell student, guardian, household, staff, cafeteria, or transaction information. We do not use student personal information for targeted advertising, behavioral advertising, or advertising profiles, and we do not permit service providers to use school-provided student information for their own advertising.

Identifiable student information also will not be used for targeted or behavioral advertising or marketing directly to children; cross-service tracking, provider-owned profiling, or commercial profiles unrelated to the school contract; sale, rental, licensing, data brokerage, or eligibility and decision-making unrelated to cafeteria service; general-purpose or unrelated artificial-intelligence model training, or prompting a third-party AI service without approval for a defined contracted function; developing products unrelated to the contracted cafeteria service; combining identifiable student information with external or other-customer datasets for unrelated purposes. Service providers are contractually restricted from those uses and from keeping student information after the defined service purpose and deletion period end.

Cashless Cafeteria is designed for school-authorized cafeteria operations. Where FERPA applies and a school uses the school-official exception, the school must maintain the required direct control, identify the legitimate educational interest, and impose applicable use and redisclosure limits. CATHOLICORE LLC uses education-record information only for authorized service purposes and applicable legal obligations.

Schools generally provide student records for cafeteria operations. Where COPPA applies, CATHOLICORE LLC remains responsible for its duties as the operator. School authorization is valid only where legally permitted, after the required Direct Notice and Data Processing Agreement requirements are satisfied, and only for the school-authorized service. Separate verifiable parental consent may still be required because of the student, school, jurisdiction, feature, data use, or material change.

A student’s invitation acceptance, Privacy Policy acknowledgment, or Student Privacy Notice acknowledgment is never parental consent. A parent’s notice acknowledgment is not verifiable parental consent unless the parent separately completes the authenticated consent workflow. A school’s notice acknowledgment is not qualified authorization until the legal-basis, signer-authority, scope, Direct Notice, and DPA requirements are satisfied.

A parent, guardian, school, or eligible student may request review or access, correction, portable export, deletion or anonymization, portal-access closure, withdrawal of consent, or a stop to further collection or use where applicable. Closing portal access does not itself delete financial, security, authorization, or school records that remain subject to a valid retention duty.

Contact the school or CATHOLICORE LLC at info@catholicore.com and identify the school and requested action without sending passwords, payment credentials, or unnecessary student records.

The request is logged and assigned a tracking record.

Identity, authority, and the relationship to the student are verified. Cashless Cafeteria may coordinate with the school before disclosing or changing school-controlled records.

The school determines applicable instructions for school-controlled records, and Cashless Cafeteria performs the applicable platform access, correction, export, deletion, anonymization, collection-stop, or access-closure action.

The verified requester receives a completion report describing actions taken, deletion or anonymization, retained exceptions and reasons, affected providers, and the expected backup-expiry cycle.

We use measures intended to protect information, including authenticated sessions, school scoping, row-level database controls, role-based permissions, server-only privileged credentials, encrypted network transport, Stripe secure payment collection, audit logs, rate limiting, controlled APIs, monitoring, and incident workflows.

No system can guarantee absolute security. Users should use strong credentials, protect invitation and recovery links, sign out of shared devices, and promptly report suspicious activity. Schools should regularly review staff access, household relationships, lunch-card status, and security records.

Retention depends on the record and purpose. Current application policies generally delete expired rate-limit and verification records after short operational windows; terminal invitations and onboarding sessions after approximately 30 days; family access requests after approximately 90 days; archived notifications after approximately 180 days; and sanitized payment-webhook audit summaries after approximately 400 days.

Unanswered guardian consent requests expire after seven days and are deleted 90 days after expiry when no consent or refusal evidence or legal hold applies. Encrypted privacy exports expire after seven days.

School account, student, guardian, household, cafeteria, photo, and education-related records are retained while needed to provide the school-authorized service and then require school or legal review for export, deletion, or anonymization. After a verified school termination or deletion instruction, CATHOLICORE LLC begins that review within 30 days and completes an approved deletion or anonymization within 90 days unless the school agreement, a legal hold, or a nonwaivable recordkeeping duty requires a different period. Security audit, legal-acknowledgment, accounting, and financial-operation records may be retained for up to seven years because they support access accountability, reconciliation, disputes, and legal obligations.

Children’s personal information may not be retained indefinitely merely because it belongs to a student record. When it is no longer reasonably necessary for the documented school-authorized purpose, the school and CATHOLICORE LLC must initiate the applicable deletion or anonymization process, subject to legal holds and nonwaivable recordkeeping duties.

Backups, Stripe records, email delivery records, hosting logs, and other service-provider systems may retain information for additional periods controlled by provider settings, contracts, and legal requirements before deletion cycles complete.

Users may update available profile fields, language, timezone, notification preferences, and payment settings. Authorized schools can correct records, manage status and relationships, process privacy requests, and run approved retention workflows.

Requests may begin with the school or info@catholicore.com. We log the request, verify identity and authority, coordinate school-controlled records with the school, execute applicable platform actions, and provide a completion report covering deletion or anonymization, retained exceptions, provider action, and backup expiry. We will not discriminate against a person for making a request where prohibited by law.

CATHOLICORE LLC and its service providers may process information in the United States and other locations where they operate. When cross-border privacy rules apply, the responsible parties must use the contractual and transfer protections required for the relevant school and service-provider relationship.

We may update this Privacy Policy when the service, data practices, service providers, contracts, or legal requirements change. The version, effective date, and last-updated date identify the notice presented to the user.

We will provide reasonable notice of material changes and request acknowledgment or consent when applicable law or the nature of the change requires it. We will not apply a material expansion of children’s data use without the authorization or consent required for that change.

CATHOLICORE LLC, 51 Orange St, Stamford, Connecticut, USA. Privacy email: info@catholicore.com. Telephone: +1 475-300-6334. Support hours: Monday-Friday, 8:00 AM-5:00 PM Eastern Time, excluding company holidays. Expected acknowledgment: Within one business day. Security incidents: info@catholicore.com. Questions about a specific student, household relationship, cafeteria purchase, or school-controlled education record should normally be directed to the school first. Requests are logged and escalated to the school, privacy owner, or security owner as appropriate. Do not provide passwords, payment credentials, or unnecessary student records.