Security
QorPay operates its own processing platform, so security is not a vendor questionnaire we forward; it is infrastructure we run. This page describes how QorCommerce handles cardholder data, who can touch what, and what happens when something breaks.
How is cardholder data handled?
Card numbers are tokenized at the point of capture. The raw primary account number (PAN) is exchanged for a token, and the PAN itself lives encrypted in the QorCommerce vault, a segmented environment inside our PCI DSS Level 1 boundary. Downstream systems, reports, and API responses carry the token, not the card.
For integrators, this is the point: if you use hosted checkout or secure embedded forms, card data goes from the customer's browser to our vault without transiting your servers. That keeps your PCI scope at the SAQ A end of the spectrum instead of a full assessment. Stored credentials for recurring billing use card tokens and ACH tokens, so repeat charges never require re-handling the PAN.
What infrastructure does QorCommerce run on?
QorCommerce runs on [TODO: cloud provider/regions], with the cardholder data environment segmented from general-purpose workloads. Data is encrypted in transit (TLS) and at rest. Production, test, and development environments are separated; the public sandbox never touches live card data.
[TODO: confirm redundancy/failover architecture, backup cadence, and DR objectives before publishing specifics.] We would rather leave a placeholder here than publish an invented number.
How is access controlled?
Access to production systems follows least privilege: role-based permissions, granted per function, reviewed on a recurring schedule as required by PCI DSS. Administrative access to the cardholder data environment requires multi-factor authentication and is logged. Customer access to the QorCommerce portal is scoped the same way: users see the merchants, transactions, and reports their role allows, and nothing else.
API authentication uses per-application key pairs, so a compromised key can be revoked and rotated without touching other integrations.
How do you handle incidents?
In public. Platform availability and incident history are published at status.qorcommerce.io. When an incident occurs, the status page carries the timeline: detection, impact, mitigation, resolution. Because QorPay operates the full stack, the engineers responding are the ones who built the affected system; there is no upstream processor to wait on.
Security incidents involving cardholder data follow the response procedures required by PCI DSS and our sponsor bank agreements, including notification obligations. [TODO: confirm published notification commitments.]