Each store isolated
Orders, products, and customers operate inside a selected tenant context. Tenant tables use PostgreSQL RLS, and the runtime application account cannot bypass those policies.
Trust · Clear boundaries and reviewable actions
Trust is not a claim of invulnerability; it is correct boundaries, tested
Shop Tek processes store, order, and customer data, so the word “secure” is not enough. This page explains what the product builds for isolation, permissions, and money correctness; what remains a shared operating responsibility; and what needs an external provider or approval before it becomes live.
Data isolationTeam permissionsInteger currencyExport and retention
The trust floor
Four layers that can be explained and reviewed
Store protection does not depend on one wall. Shop Tek combines application tenant context, database policy, role permissions, and records of sensitive actions, alongside production practices that must be completed operationally.
Access shaped by the task
Owner, Manager, Staff, Driver, and Viewer split access. A driver does not see the entire store, and a viewer cannot alter prices, inventory, or sensitive settings.
Money without floating-point drift
Every market currency is stored as integer minor units with its decimal scale snapshotted on the order. Tax settings and order lines retain the values in force at purchase.
Audit and export
Sensitive price, stock, and refund operations leave a reviewable record. The merchant can export store data before final termination under the retention policy.
How isolation works
A front-end filter is not the only security boundary
When a request reaches a store host, the tenancy layer establishes tenant context before domain work runs. Queries use that context, then PostgreSQL RLS policies enforce it on tenant-scoped tables. The daily runtime account is separate from the table-owning migration account and receives no BYPASSRLS privilege.
Multi-tenant tables are covered by cross-tenant denial tests: data is created in one store context and access is attempted from another. This does not remove the need for code review or infrastructure security, but it turns isolation from a developer convention into a testable database constraint.
Roles then define the boundary between people in the same store. Creation, editing, refund, and setup actions pass through explicit permission checks. Operational support access, when needed, should be limited, reason-based, and audited rather than a permanently open shared account.
Provider boundaries
Product readiness is not third-party authorization
The platform uses replaceable provider managers for payment, e-invoice, and messaging. This reduces lock-in, but it cannot bypass a provider’s terms, approval, or availability.
Cash on delivery
Live and availableStatus, fees, cap, refusal, and restocking operate in-product without an external gateway.
Dynamic CliQ QR
Live and availableThe product creates QR and order reference; transfer matching needs operational verification until an approved bank integration exists.
Live WhatsApp messages
Activation requiredThe flow sits behind a provider interface; live delivery needs an account and approved templates.
Live JoFotara submission
Activation requiredThe invoice interface exists, while official submission needs ISTD credentials and activation approval.
Live card gateway
Not currently availableCards are not presented as available until an approved provider is configured and monitored.
Automated carrier network
Not currently availableDelivery zones and own-driver mode work now; a live carrier network needs an approved provider.
Shared responsibility
The platform protects boundaries; the merchant protects usage
A product cannot fix a shared owner password, prohibited goods, or an unclear returns policy by itself. These practices complete technical controls and prevent common day-to-day incidents.
A separate account for each member
Use invitations and roles instead of sharing the owner login. Remove access when duties change and review which drivers remain active.
The minimum customer data
Do not copy a buyer address or phone into public groups. Use the order and status page, and never place payment secrets or identity documents in free-form notes.
Provider accounts owned correctly
Keep messaging, payment, and invoice provider accounts and credentials with the right organization. Do not send keys through a public support form or unsafe chat.
Published store policies
Write clear returns, privacy, and COD policies for buyers. Shop Tek provides the publishing surface; the merchant remains responsible for lawful and accurate content.
Data and retention
What is processed, why it is needed, and how it ends
Shop Tek processes account, store, product, order, and customer data needed for the service. Examples include name, email, phone, delivery address, and order history. Personal data is not sold, and optional storefront measurement should not run before visitor consent.
Data remains during subscription and for legally required periods. The merchant can download a copy. Suspension for non-payment does not mean immediate deletion, but final termination may lead to deletion under the retention policy, so export should happen before that point.
The privacy policy explains the general basis for processing, access, correction, and deletion, while the terms define merchant responsibility for products, content, law, tax, and acceptable use. This page does not replace either legal document.
Review, then test
Begin with demo data, then bring store data in confidently
Use trial to inspect roles, export, and the order path, and send provider or privacy questions to the team before live activation.
Start an isolated store trialSend a trust or privacy question
No absolute immunity claim · Testable boundaries · Providers disclosed