Security
Last updated · August 8, 2026
Orqex sits between customer systems and their payment providers. Our security approach focuses on minimising sensitive data, restricting access, verifying communications, preserving transaction integrity, and designing flows to withstand errors and third-party failure. This page is a public overview, not an audit attestation or service-level agreement.
1. Shared responsibility
Orqex secures the platform and components it operates, authenticates and authorises Orqex access, protects stored secrets, signs or verifies supported webhooks, separates tenants and environments, and maintains platform controls. Customers secure their own applications, networks, devices and provider accounts; assign roles and remove obsolete access; store keys in an appropriate secret manager; verify Orqex webhooks and implement idempotency; separate sandbox and production; and ensure their transactions, data, and integrations comply with law.
2. Card-data minimisation
Orqex is not designed to receive or store full card numbers, card security codes, PINs, or magnetic-stripe data. Card details should pass directly from the payer to the selected payment provider through hosted pages, tokens, or approved provider components. Customers must never include raw card data in metadata, logs, webhooks, free-text fields, support requests, or sandbox.
3. Authentication and access control
Controls include signed user tokens, mandatory multifactor authentication for internal staff access, role- and permission-based access within organisations and projects, project ownership checks before resource access, distinct user, internal, secret-key, and publishable-key access paths, rate limiting on sensitive entry points, and administrative activity records. Internal personnel may access customer data only as needed to provide support, respond to incidents, comply with law, or protect the platform.
4. API keys and secrets
Secret API keys contain a random secret, are shown in full only at creation, and are stored as a non-reversible SHA-256 hash. They can be disabled, expired, restricted by IP allowlist, and rotated with a short transition window. Publishable keys have deliberately limited rights. Provider credentials, webhook secrets, and staff multifactor secrets stored by Orqex are protected through application-level encryption and masked or permission-restricted where displayed.
5. Tenant and environment separation
Each project is a logical data boundary for provider accounts, routing rules, customers, transactions, refunds, payouts, keys, and settings. Production and sandbox keys, accounts, transactions, and aggregates are environment-scoped. A sandbox key must not authorise a production operation. Customers should avoid real sensitive data in sandbox.
6. Secure communications and webhooks
Production interfaces and configured webhook endpoints must use HTTPS. Supported inbound provider webhooks undergo signature verification and event deduplication. Outbound Orqex webhooks are signed, validate destination TLS certificates, do not automatically follow redirects, and use controlled retries with backoff. Customers must verify signature, timestamp, and event identity before acting.
7. Transaction integrity
Orqex uses idempotency keys for state-changing API operations, atomic locking for concurrent captures on one intent, attempt limits, explicit transaction states, unique identifiers, provider-event deduplication, conservative failover conditions, and delayed verification of asynchronous results. Customers must still implement idempotent handlers and reconcile their records.
8. Fraud and abuse controls
Orqex may use IP address, device, country, attempt history, irreversible instrument fingerprints, velocity, and other signals to identify automation, card testing, blocked instruments, abnormal volume, fraud patterns, or provider anomalies. Internal instrument fingerprints use contextual HMAC SHA-256 so comparisons do not rely on the raw value. Customers remain responsible for configuration, human review where needed, and business consequences.
9. Logging and sensitive-data handling
Orqex records events needed for diagnosis, security, audit, and transaction delivery. Logging controls mask commonly sensitive fields such as authorisation headers, API keys, passwords, tokens, OTPs, secrets, and card fields. This does not replace the customer's duty not to submit secrets in unsupported fields. Webhook logs are retained for 30 days under the reference configuration. Generated exports expire after 7 days and use time-limited signed download links.
10. Secure development and operations
Reference practices include review before production deployment, automated tests for access rules and payment invariants, boundary validation, separation of service responsibilities, dependency and patch management according to risk, environment-managed production secrets, scheduled expiration and cleanup, and monitoring of errors, queues, deferred processing, and critical services. Attack-enabling implementation details are not published.
11. Providers and dependencies
Orqex uses infrastructure, monitoring, communication, and payment providers whose access should be limited and contractually controlled. Payment providers connected by the Customer remain third-party systems. Their outage, compromise, or API change may affect transactions. Orqex uses failover and recovery controls where a flow permits but cannot guarantee another provider will accept an operation.
12. Incident response
For a suspected incident, Orqex aims to classify and contain the event, protect affected keys and data, preserve evidence, remediate the cause, restore safely, determine affected customers and obligations, notify affected customers without undue delay when required, and document corrective actions. Customers must maintain emergency contacts and cooperate promptly, including with key rotation or actions on their systems.
13. Resilience
Persistent states, queues, controlled retries, deferred verification, and idempotency are designed to support recovery and avoid duplicate execution after interruption. Contractual availability, backup, recovery-point, or recovery-time objectives apply only if stated in a signed Order Form or service-level agreement.
14. Certifications
Reducing card-data scope is an architectural objective, not a certification. Unless a valid attestation and its scope are expressly identified in a contract or trust centre, Orqex does not claim PCI DSS, ISO 27001, SOC 1, or SOC 2 certification. Customers must not represent Orqex as certified based on this page alone.
15. Responsible disclosure
Report vulnerabilities confidentially to security@axazara.com with the affected asset, clear description, minimal reproduction steps, potential impact, and non-destructive evidence. Use only your own accounts and test data. Do not access or alter third-party data, disrupt the Service, conduct denial of service, use social engineering, install malware, retain access, or publicly disclose before a reasonable remediation period. Stop immediately if third-party data or a secret is encountered.
16. Researcher expectations and contact
Orqex aims to acknowledge a report within three business days and provide reasonable updates based on severity. This is an operational objective, not an SLA. This policy is not a paid bug-bounty programme. Good-faith research within these rules will not trigger an action initiated by Axa Zara, subject to applicable law and third-party rights. Security questionnaires and architecture requests may also be sent to security@axazara.com and may require a confidentiality agreement.
