Security & Trust
Scorpaq is being designed to keep your business information separate, give team members access appropriate to their work and verify payment results. The aim is to help you manage service while retaining control of your data and payments.
Security is treated as a system boundary across the product, not as a front-end feature.
This page describes product design principles while Scorpaq is in development. It does not claim an independent audit, certification or a fully activated production service.
Business and workspace data is designed to remain separated. Access is resolved within the authorized workspace and scope.
Every data request needs an authorised business context; knowing a record identifier must not be enough to read it. Cross-business access must be rejected at the enforcement boundary, not merely hidden in the interface.
Least-privilege authorization and role separation support Owner, Manager, Waiter and Kitchen responsibilities.
Roles should follow actual tasks: preparation, service, management and ownership. A staff member should not receive sensitive settings or business-wide data simply because the screen is accessible.
Payment truth is server and provider verified. A browser payment-success page is not treated as authoritative proof.
An interrupted return to the browser must not change payment truth. Uncertain results need to stay pending until the supported provider and server checks resolve them.
Hosted payment is preferred so raw card data does not need to enter Scorpaq application logic, logs or analytics.
Card details belong on the supported provider’s payment page, not in contact messages. Hosted checkout is a data boundary, not a claim that every provider configuration has been certified.
Scorpaq does not custody or redistribute guest funds. The provider-to-business money flow remains outside the platform.
The business’s provider relationship determines how guest funds are handled. This is separate from the business’s Scorpaq subscription and does not make Scorpaq the merchant holding those funds.
Data minimization, no mandatory guest account and no persistent cross-business guest identity baseline are part of the design.
The marketing website and future guest platform have different data flows. Review this site’s Privacy Notice for form fields, referral information and your optional marketing choice; do not infer a production guest policy from it.
The design includes TLS, managed secrets and OIDC/JWKS identity-verification principles where applicable.
Credentials must remain outside public source code and client bundles. These are engineering principles, not a published inventory of hosting regions or a guarantee about every deployment’s configuration.
Idempotency, replay protection, durable transaction state and safe uncertain-state handling support recovery where required.
A repeated technical request should reuse its transaction identity rather than create a new operation. Recovery must preserve what is known and identify what still needs verification instead of silently treating uncertainty as success.
Required transaction state and operational events are designed to be durable and auditable.
Relevant state changes need their business and transaction context so a problem can be investigated. This principle does not establish a public retention period or promise that every user can see every internal event.
Analytics should describe observed data honestly. Missing or weak data is not presented as certainty. Guest free text is not a default advertising or profiling input.
Example dashboards illustrate the approach, not customer measurements. Incomplete cost data cannot support a complete profitability claim, and data-quality limits should remain visible alongside any insight.
Questions can be sent through the existing Contact page.
Use the privacy/data-request topic for information rights or describe a security concern with the affected page and behaviour. Do not include passwords, full card details or identity documents in the initial message.