search

4.2 Security

Security in Hyperswitch is built as a foundational layer and since the system operates directly on the critical payment path and handles highly sensitive financial data, the architecture is designed to minimize exposure, enforce strict data boundaries, and apply encryption at every stage of the data lifecycle.

hashtag
PCI-SSS Certified (Not Just PCI-DSS)

Hyperswitch is PCI-SSS (PCI Secure Software Standard) validated. This goes beyond infrastructure-level PCI-DSS compliance and validates the software itself against stringent secure development and software lifecycle standards defined by the PCI Security Standards Council.

PCI-SSS certification ensures:

  • Secure software development practices

  • Controlled cryptographic implementations

  • Protection against common software vulnerabilities

  • Secure configuration and deployment guidelines

This gives merchants confidence that the payment software layer itself adheres to globally recognized payment security standards.

hashtag
Reduced Exposure of Sensitive Information

A key security principle in Hyperswitch is minimizing the exposure of sensitive payment data across the system.

Sensitive information is carefully controlled across:

  • Application Logs

  • Merchant Control Center (Dashboard)

  • API Responses

Card numbers, CVV, expiry, and other sensitive fields are masked or redacted before being logged, surfaced in dashboards, or returned in responses. Only masked representations (such as last4) are visible where required.

In addition, asynchronous post-facto scanning mechanisms using regex-based pattern detection help identify and flag any accidental leakage of sensitive data in logs or events. This provides an additional safety net beyond preventive controls.

The goal is simple: sensitive data should never travel further than absolutely necessary.

hashtag
Encryption at Every Stage

Hyperswitch enforces encryption both in transit and at rest, ensuring protection across the entire data flow.

Data-in-Transit Encryption

All communication between components is encrypted using:

  • TLS encryption for secure transport

  • JWE/JWS encryption for payload-level cryptographic protection

When card data is accepted through the Client SDK (web/mobile), it is encrypted before transmission. Communication between the client, backend services, vault, and external connectors is secured using SSL/TLS. In certain flows, JWE/JWS adds an additional layer of application-level encryption.

Data-at-Rest Encryption

Once stored, sensitive data remains encrypted using multiple layers:

  • Application-level AES encryption

  • Database-level encryption

  • Multi-layer encryption inside the PCU Card Vault

  • Encrypted Vault database with master/replica storage

Card data is isolated within the Card Vault service and never stored in plaintext in application databases. Even internal services only operate on encrypted representations or tokens.

Secure Data Flow Design

The overall design ensures:

  1. Card data is accepted securely via the Client SDK.

  2. It is encrypted in transit to the backend.

  3. It is stored in the dedicated Card Vault service.

  4. The vault database enforces additional encryption layers.

  5. Downstream services operate on tokens, not raw card data.

This layered approach ensures compliance with strict regulatory and industry standards.

Previous4.1 Fault, Capacity and Change

Last updated