Trust starts with clear boundaries.
See how DineQube approaches authenticated access, tenant/property boundaries, payment providers, guest data and AI usage across the platform.
Authenticated access
Merchant operational areas are designed for authenticated business access.
Property context
Restaurant or Hotel data should remain tied to the relevant account/property context.
Payment providers
Payment processing responsibilities are shared with configured third-party providers.
AI boundaries
Qube AI should only operate on data and workflows exposed to the relevant product context.
Practical trust principles for a live hospitality platform.
Account access
Operational dashboards should require authenticated merchant access and session controls.
Server-side secrets
Production API keys and sensitive credentials should remain server-side and outside public website source.
Payment handling
DineQube may integrate with external payment providers; payment data handling depends on the configured payment flow and provider.
Guest data minimisation
Guest/customer information should be collected only where a product flow requires it and handled according to the Privacy Policy.
Operational privacy
Room, table, order and request context should be visible only to the intended merchant/product context.
Delivery location controls
Customer or rider location should be requested only for the delivery workflow, scoped to the relevant order and handled according to the Privacy Policy.
No invented certifications
This page does not claim SOC 2, ISO or other certifications unless DineQube has actually obtained and published them.
Need a security or privacy conversation?
Use the contact form and describe the information your team needs.
Contact DineQube