Data Security
Tripzygo OMS holds two things that matter: your buyers’ delivery details and the credentials that let us act on your marketplace accounts. This page states how each is protected, where it lives, and what we do when something goes wrong.
Everything below describes controls that are in place today. Where a practice is a commitment rather than an implemented control, it is labelled as one.
AES-256 encryption on the database, file storage and backups.
TLS 1.2 or higher for all browser and marketplace API traffic.
India only. Hostinger data centres located in India, with no replication abroad.
Never in plaintext. OAuth tokens encrypted before storage, decrypted only in memory.
Every connection to oms.tripzygo.in is served over HTTPS using TLS 1.2 or higher. Plain HTTP requests are redirected to HTTPS, and HTTP Strict Transport Security is enabled so browsers will not attempt an unencrypted connection after the first visit. Older protocol versions and weak cipher suites are disabled at the server.
The same applies outbound. Every call Tripzygo OMS makes to a marketplace API, a courier API or our payment provider is made over TLS with certificate verification enabled. Communication between our application servers and the database is encrypted and restricted to private network paths, not exposed to the public internet.
Generated labels, manifests, invoices and report exports are delivered over the same encrypted channel and are served only to authenticated users within the account that owns them.
Data at rest is encrypted using AES-256. This covers the primary database holding orders, inventory, returns and settlement records; the file storage holding generated documents and imported settlement reports; and every database backup.
Sensitive fields are additionally encrypted at the application layer before they reach the database, so a copy of the database alone does not yield readable credentials. Encryption keys are managed separately from the data they protect and are rotated on a defined schedule and immediately if a compromise is suspected.
Backups are encrypted, retained for a rolling 30 days, and destroyed after that window. Restores are performed only to recover from failure or data loss, by authorised staff, and are logged.
Marketplace channels are connected through each marketplace’s own authorisation flow. You authenticate at the marketplace, not with us, and approve the scopes the integration requests. We never ask for your seller-panel username and password, and there is nowhere in the product to enter one.
The access and refresh tokens returned by that flow are encrypted with AES-256 before storage and are never written in plaintext to any database, file, log, error report or support ticket. Decryption keys live in a managed secret store, separate from the encrypted values, and are not reachable from the application interface by any user or by our staff.
A token is decrypted in memory only at the moment an authorised API call is made on your behalf, and is discarded from memory afterwards. Refresh happens automatically inside the same protected path. We request only the API scopes the OMS features require, and no more.
You can disconnect a channel from inside Tripzygo OMS at any time, which deletes the stored tokens and, where the marketplace supports it, revokes them at source. You can also revoke our access directly from your marketplace seller account; the integration then stops immediately and the failure is surfaced to you rather than retried silently.
Your Tripzygo OMS account password is stored only as a salted one-way hash using a modern password-hashing function. It cannot be read or recovered by us. Sessions expire after a period of inactivity and can be signed out from all devices by the account owner.
Inside your account, access is governed by roles you assign: owner, operations, warehouse and accounts. Each role sees only the modules and fields its work requires, and buyer contact details are restricted to roles that need them to fulfil an order. Role changes take effect immediately and are recorded in the audit log.
Every data query in the application is scoped to the account of the signed-in user, so one customer cannot reach another customer’s orders, inventory, credentials or settlements.
On our side, administrative access to production infrastructure is limited to the small number of staff whose role requires it, granted on a least-privilege basis and protected by multi-factor authentication. Access is reviewed periodically and revoked when a person changes role or leaves. Our staff do not browse customer data; access for a support investigation is initiated at your request and logged. Every action that changes an order, inventory, return or settlement record is captured in an append-only audit log with the acting user, timestamp and prior value, and account owners can review their own log.
Tripzygo OMS runs on infrastructure provided by Hostinger, in Hostinger data centres located in India. Your order data, inventory data, encrypted credentials, generated documents and backups are stored in those Indian data centres. We do not replicate or fail over this data to regions outside India.
Hostinger is our only infrastructure subprocessor with access to hosted seller data, and it holds that data as our provider, not for any purpose of its own. If we add another subprocessor with such access, our Privacy Policy will name it and account owners will be notified by email before the access begins.
Data leaves India only in the direction it must: when we send an order update to a marketplace or courier API, that request goes to the endpoint the provider operates. We send only the fields the operation requires.
We maintain a written incident response procedure and a named owner responsible for running it. If we detect or are informed of a security incident affecting your data, we commit to the following.
Contain first: isolate the affected component, revoke or rotate any credentials that may be exposed, and stop further data movement.
Assess scope: determine which accounts and which data categories are affected, and preserve logs and evidence for the investigation.
Notify affected account owners by email with what happened, what data was involved, what we have done, and what you should do. Notify the relevant marketplaces where their API data or credentials are implicated, and report to Indian authorities including CERT-In where reporting is required.
Complete a root-cause review, implement the corrective fix, and share a written summary with affected customers on request.
We will not withhold notification because an incident is embarrassing or because the impact is still being quantified. Partial information delivered on time is more useful to you than a complete report delivered late.
Operating system packages, runtime versions and application dependencies are patched on a regular cadence, and out of cycle when a vulnerability is rated high or critical. Dependencies are scanned automatically for known vulnerabilities as part of our build process, and a build that introduces a high-severity issue is not deployed until it is resolved or documented as not exploitable in our configuration.
Code changes are reviewed before release. Development and production environments are separate, and production data is not copied into development or test environments. Where test data is needed, it is synthetic.
Our remediation targets, measured from confirmation of a vulnerability, are 7 days for critical, 30 days for high, and 90 days for medium and low severity issues. Where a fix depends on an upstream provider, we apply available mitigations in the meantime.
Reporting a vulnerability
If you believe you have found a security vulnerability in Tripzygo OMS, write to gaurangpatel@tripzygo.in with the details and steps to reproduce. We acknowledge reports within 3 business days and will keep you informed until the issue is closed. We ask that you do not access, modify or retain data belonging to other users while testing, and that you give us reasonable time to fix an issue before disclosing it. We will not pursue legal action against researchers who follow these terms.
Encrypted backups are taken on a regular schedule and retained for a rolling 30 days. Restore procedures are documented and tested, so recovery is a rehearsed operation rather than an improvised one.
Application health and integration health are monitored continuously. When a marketplace API is unavailable or rejecting requests, the affected orders and updates are queued and retried, and the failure is shown in the integration log rather than dropped.
Planned maintenance that requires downtime is scheduled outside Indian business hours where possible and announced to account owners in advance by email.
If you need answers to a security questionnaire, a data processing agreement, or written confirmation of any control described on this page, write to us and we will respond. Marketplace and platform reviewers can use the same address.