Row-level security per store
Every tenant-aware table carries a stable store identity and has row-level security enabled. Isolation is enforced in the database, never by filtering in a screen.
Security and trust
Secure by construction, not by promise.
Via is built so the database refuses what a store, a role or a browser should not see or do. These are the rules the platform enforces today, stated the way we state them internally.
RPC-only tables
Browsers and storefronts have no direct table grants. Data is read and written only through reviewed database functions that resolve the caller's store and permission server-side.
No card data
Card numbers and security codes are entered on the payment provider's hosted page. Via never receives or stores them; it records the outcome and a masked reference.
Secrets by name
Integration credentials live in the server's secret store and are referred to by name, for example VIA_NOTIFICATION_EMAIL_API_KEY, GEIDEA_ODX_MAIN_MERCHANT_PUBLIC_KEY, VIA_META_APP_SECRET, VIA_MESSAGES_<STORE>_WHATSAPP_TOKEN. Admin shows whether a name is set, never its value. Nothing secret is in the code repository.
Append-only audit
Every staff, system and AI change is recorded with actor, action, entity, before and after, and time. Audit rows cannot be updated or deleted through the application.
Nine roles, least privilege
Roles grant exactly what a job needs. Customer PII, supplier costs, margins, payout data and integration secrets are separate permissions. A media buyer never sees customer details, costs or another store.
Opaque, hashed tokens
Guest carts, checkouts and quote requests use opaque tokens stored as SHA-256 hashes with expiry and revocation. A record id alone is never authorisation.
Authenticated, idempotent webhooks
Provider callbacks are verified by signature, bound to the payment attempt they claim, processed once, and safe to retry. An unverified event cannot change payment or order state.
Exact-origin gateways
The storefront gateway, the payment gateway and this site's own form accept requests only from configured origins, never from a wildcard. Rate limits and idempotency are enforced server-side.
Honest test data
Test orders are flagged at the source and excluded from revenue, attribution and reports, so rehearsals never inflate your numbers.
Staff sign-in
Each staff member signs in to Via Admin with their own account, invited by the owner. The browser holds only the public project key, never a service key.
Consent before events
Marketing events leave Via only after the visitor's consent is recorded, and what was sent is recorded too.
Where Via runs
Database
PostgreSQL 17 on Supabase in the EU (Frankfurt region). Schema changes ship only as reviewed migrations; every change is verified against production and re-checked with the security advisor.
Server functions
Edge Functions hold service credentials and provider secrets; the browser talks to them over HTTPS from allowed origins only.
Storefront and Admin
Static bundles behind a content security policy: no inline script, no third-party script, no analytics on this site.
Questions from your security or finance team are welcome before you start. We would rather show you the rule than describe it.
Ask us the hard questions.
Bring your security checklist to the call. Every answer above is something we can show you in the database.