Security
Practical controls for hotel information
AYZYNX uses layered controls appropriate to the current managed hotel service. This page describes current practices without claiming a certification AYZYNX does not hold.
Tenant and account access
Client workspace requests are authenticated and scoped to the hotel linked to the user. AYZYNX administration uses a separate staff boundary. Server-side APIs enforce the selected tenant rather than trusting a browser-supplied tenant identifier.
Provider and webhook security
Stripe and Twilio webhook requests use provider signature validation. Invalid or expired Stripe signatures and unsigned Twilio requests are rejected. Provider events use idempotency controls to reduce duplicate processing.
Credentials and payment data
Production secrets are stored as deployment secrets rather than committed to source control. AYZYNX does not receive full Stripe card details. Telephone destinations are masked in normal operational records.
Data minimisation
The service is designed for routine hotel information and asks guests not to submit payment details or sensitive booking information. Test and demo activity is classified separately and excluded from client metrics by default. Raw call audio is not stored by AYZYNX by default.
Monitoring and change control
Production services expose operational health and record relevant failures, retries and last-success state where implemented. Material changes are tested before deployment and deployed versions provide a rollback point. A status label is not treated as proof of an untested workflow.
Report a concern
Report a suspected vulnerability or security incident to contact@ayzynx.com with the subject ‘Security report’. Do not include passwords, secret keys, full payment-card data or unnecessary guest information. AYZYNX will acknowledge and triage credible reports.
Last updated 1 September 2026 · Questions: contact@ayzynx.com