The Payment Card Industry Data Security Standard (PCI DSS) v4.0 is a set of security requirements established by the PCI Security Standards Council to protect cardholder data. Any entity that stores, processes, or transmits cardholder data must comply with PCI DSS.
ClearRoute operates as a payment routing middleware. We do not store, process, or transmit full card numbers (PAN), CVV/CVC, cardholder names, or card expiry dates in any form — raw, encrypted, or tokenized. Transaction data flowing through ClearRoute passes through to your configured Payment Service Providers (PSPs), who handle all actual card data under their own PCI DSS compliance programs.
ClearRoute's PCI DSS compliance is documented in this statement. This document constitutes our formal attestation of compliance for the requirements applicable to our service scope.
Because ClearRoute does not store cardholder data (CHD), our compliance obligations are scoped to the requirements of SAQ-A (Self-Assessment Questionnaire A) — the least burdensome PCI DSS questionnaire, appropriate for merchants and service providers who outsource all payment processing and do not handle cardholder data directly.
The following table maps each PCI DSS v4.0 requirement to ClearRoute's implementation and responsibility assignment. "ClearRoute" indicates sole ClearRoute responsibility. "Shared" indicates ClearRoute shares responsibility with our infrastructure providers. "Customer" indicates the requirement falls primarily to ClearRoute's customers based on their own integration type.
| Req | Requirement | Owner | ClearRoute Implementation |
|---|---|---|---|
| 1 | Install and maintain network security controls | Shared | Render.com manages network-level firewalling and isolation. All services run behind Render's infrastructure network controls. ClearRoute configures application-level access controls; Render manages physical and network-layer controls. |
| 2 | Apply secure configurations to all system components | ClearRoute | All default passwords replaced. Unnecessary services and ports disabled. Neon PostgreSQL enforces TLS 1.2+ for all database connections. Container images built from minimal base images. |
| 3 | Protect stored account data | ClearRoute | ClearRoute does not store PAN, CVV/CVC, or cardholder names in any form — raw, encrypted, or tokenized. Transaction routing metadata (transaction ID, amount, PSP response, latency, cost) is stored and does not constitute cardholder data. PSP API keys are encrypted at rest (AES-256). No card data — including truncated PAN — is stored in our database. Requirements 3.1 through 3.6 (stored CHD protection) are not applicable to ClearRoute's service. |
| 4 | Protect cardholder data in transit | ClearRoute | All data in transit encrypted via TLS 1.2+. HTTPS enforced on all API endpoints, dashboard, and landing pages. Outbound connections from ClearRoute to PSP APIs use TLS. |
| 5 | Protect all systems and networks from malicious software | Shared | Render infrastructure provides automatic OS-level patching and malware protection at the host level. ClearRoute does not run any proprietary malware detection agents; this is handled by Render's managed infrastructure. |
| 6 | Develop and maintain secure systems and software | ClearRoute | Secure software development lifecycle. Code reviewed before deployment. Dependencies kept current; automated vulnerability scanning on dependencies. No custom software processes cardholder data. Application logs do not include PAN or CVV. |
| 7 | Restrict access to system components and cardholder data by business need to know | ClearRoute | Role-based access control enforced at the application layer. All database queries are customer_id scoped — cross-account access is structurally impossible. Service accounts used by application components operate with least-privilege database permissions. |
| 8 | Identify users and authenticate access | ClearRoute | Unique user accounts for all personnel with access to the ClearRoute service. User passwords hashed with bcrypt (cost factor 12). JWT-based session management with 7-day expiry. Multi-factor authentication (MFA) required for all dashboard and API access via TOTP or WebAuthn. All access attempts (successful and failed) are logged with timestamp, user identifier, and action. PSP integration accounts use scoped API keys with least-privilege access limited to routing operations. |
| 9 | Restrict physical access to cardholder data | Shared | Render and Neon manage physical datacenter security. ClearRoute does not have physical access to hardware. No paper or physical media containing cardholder data. |
| 10 | Log and monitor all access to system components and cardholder data | ClearRoute | All API requests logged with timestamp, customer_id, and action. Routing decision logs stored with PSP scores and outcomes. Access logs retained for 1 year per PCI DSS Requirement 10. Log integrity protected by append-only storage. No cardholder data in logs. |
| 11 | Test security of systems and networks regularly | ClearRoute | Vulnerability scanning runs quarterly. Render infrastructure handles network-level penetration testing. Application-level security testing performed before major releases. |
| 12 | Support information security with organizational policies and programs | ClearRoute | ClearRoute maintains an internal information security policy reviewed annually. All personnel with access to systems handling customer data receive annual security awareness training. Security contact: security@clearroute.app. ClearRoute maintains a formal incident response plan. |
PCI DSS v4.0 Requirement 8.4.1 requires MFA for all access to the cardholder data environment. ClearRoute enforces MFA for:
MFA is implemented using TOTP (Time-based One-Time Password) as the primary mechanism, with WebAuthn (FIDO2) as an alternative. MFA enrollment is required at account creation — users who have not enrolled MFA cannot access the dashboard or API.
Using ClearRoute does not exempt you from your own PCI DSS obligations as a merchant or service provider. You are responsible for completing and maintaining your own PCI DSS Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC), as required by your acquiring bank and the card brands. ClearRoute provides this statement as supporting documentation — it does not substitute for your own attestation to your acquirer.
Your obligations depend on your integration type:
Your cardholder data never touches your servers — the payment form is hosted by your PSP or ClearRoute. You likely qualify for SAQ-A. Confirm that your redirect or iframe implementation does not capture card data on your servers.
If your checkout embeds your PSP's hosted payment form via iframe where card data is captured directly by the PSP's frame, you may qualify for SAQ-A-EP (Entity Proxy). This is more rigorous than SAQ-A but less burdensome than SAQ-D. Confirm eligibility with your acquiring bank. Requirements include validating the iframe origin and ensuring no cardholder data transits your servers in any form.
If your servers handle card data directly — even briefly — you likely need SAQ-D or a full Report on Compliance (ROC). Contact your acquiring bank to confirm your required SAQ type.
For clarity on our PCI DSS scope:
If you become aware of a suspected or confirmed compromise of cardholder data in connection with ClearRoute:
ClearRoute conducts an annual review of our PCI DSS posture. Documentation relevant to this compliance statement — including our SAQ-A, network diagrams, and security policies — is available to customers and auditors under NDA upon written request to compliance@clearroute.app.
Questions about ClearRoute's PCI DSS compliance should be directed to: compliance@clearroute.app.