01
Authenticate
Use the current Supabase session to establish the user identity.
Security and privacy
What the application protects—and what your school still owns.
Review the controls visible in the current product, the providers used for identity and payments, and the questions that still require written confirmation during procurement.
Verified product boundaries
See what each control checks and which evidence to request.
These descriptions reflect application behavior present in the current codebase. They do not represent an external certification.
Interactive security control explorer
Boundary question
Who can reach this workflow?
Supabase Auth establishes the signed-in identity. Application routes then evaluate school membership, permission codes, approved household relationships, and the active school before returning protected records or allowing an action.
02
Authorize
Evaluate the required permission, school membership, or approved family relationship.
03
Constrain
Validate the active school, household, line, or student again on protected requests.
Useful review evidence
- Permission-code matrix
- Two-school access demonstration
- Invitation and access-removal workflow
Identity and access controls opened.
Current implementation
Public control facts, stated without marketing shorthand.
Identity
Supabase Auth establishes the signed-in user.
Implemented behavior
Protected workflows read the authenticated session before resolving application access.
Important boundary
Signing in does not grant access to every school or household.
Authorization
Staff access uses school membership and permission codes.
Implemented behavior
The active school and required permission are checked for protected staff routes. Family views use approved household relationships.
Important boundary
Schools control who is invited, which role is assigned, and when access is removed.
Payments
Stripe components collect supported card and bank details.
Implemented behavior
The application uses provider references, payment status, amounts, and safe method summaries. Signed webhook events drive payment lifecycle updates.
Important boundary
Processing money remains separate from posted wallet value until the successful event is reconciled.
Audit and request safety
Covered sensitive actions create school-scoped audit evidence.
Implemented behavior
The audit view requires permission, returns redacted metadata, and supports controlled export. Sensitive endpoints also use rate limits or idempotency where applicable.
Important boundary
Audit coverage should be tested against the exact actions your school considers critical.
Confirm before signing
Four items require written answers, not assumptions.
The public product experience cannot replace your contract, data-processing terms, or school-specific policy decisions.
Incident response
Who is contacted, how severity is defined, and what response and notification times apply?
Retention and deletion
Which records are retained, for how long, who approves deletion, and what history must remain?
Providers and assurances
Which subprocessors apply to your deployment, and which current reports or certifications can be supplied?
Contract exit
Which data can be exported, in what format, on what timeline, and how is remaining data handled?
Questions schools ask
Use the overview to start verification—not end it.
This overview explains product behavior visible in the current application. It does not claim an independent audit, certification, legal conclusion, or a contractual service level.
Is this page a certification or compliance claim?
No. It is a public overview of design boundaries and operational practices. Schools should request the documentation and evidence required for their own security, privacy, legal, financial, and procurement review.
Does Cashless Cafeteria store full card or bank account numbers?
Supported payment flows use provider-hosted collection. The application works with provider references and limited operational details needed for status, reconciliation, support, and safe display rather than full payment credentials.
How is access kept within the correct school or household?
Protected workflows evaluate authenticated identity together with school membership, assigned permissions, approved household relationships, and active context. Records referenced by an action should remain within that authorized scope.
What security evidence should a school request during evaluation?
Ask for evidence appropriate to the question, such as a product demonstration, role and permission definitions, protected-route behavior, payment-flow boundaries, audit-event coverage, incident ownership, retention processes, and named follow-up items.
Which security responsibilities remain with the school?
Schools remain responsible for decisions such as approving users and family relationships, assigning appropriate roles, removing access, applying local policies, reviewing exceptions, and involving the right security, privacy, legal, procurement, and financial stakeholders.
Review security with the exact workflows your school will use.
Bring your roles, school structure, payment methods, incident questions, and retention requirements.