LogoLogo
Explore with DeepWikiJoin Slack CommunityContact Us
  • About Hyperswitch
    • Introduction
    • Payments Suite
    • Payments Modules
      • Cost Observability
      • Revenue Recovery
      • Vault
        • Server to Server Vault tokenization
        • Vault SDK Integration
      • Intelligent Routing
      • Reconciliation
        • Getting Started with Recon
      • Alternate Payment Method Widgets
        • Hyperwidget Integration Guide
    • Roadmap - Q2 2025
      • Previous Roadmap - Q1 2025
      • Previous Roadmap - Q4 2024
      • Previous Roadmap - Q3 2024
      • Previous Roadmap - Q2 2024
      • Previous roadmap - Q1 2024
      • Previous roadmap - Q4 2023
  • Use-Cases
    • For SaaS Businesses
    • For B2B SaaS Businesses
    • For E-Commerce Businesses
    • For Marketplace/Platforms
  • Explore Hyperswitch
    • Payment Orchestration
      • Accept Payments
        • Connectors
          • Activate Connector on Hyperswitch
          • Try a Payment
          • Available Connectors
            • ACI
            • Adyen
            • Airwallex
            • Authorizedotnet
            • Bambora
            • Bank of America
            • Billwerk
            • Bluesnap
            • Braintree
            • Checkout
            • Coinbase
            • Cybersource
              • Apple Pay
              • Google Pay
            • dLocal
            • Fiserv
            • GlobalPayments
            • GoCardless
            • Klarna
            • Mollie
            • MultiSafepay
            • Nuvei
            • OpenNode
            • Paypal
            • PayU
            • Prophetpay
            • Rapyd
            • Shift4
            • Stripe
            • TrustPay
            • Volt
            • Worldline
            • Worldpay
            • Zen
            • Netcetera
              • Authenticating Payments via Netcetera Through HyperSwitch SDK
        • Setup Payment Methods
          • Cards
          • Wallets
            • Apple Pay
              • Web Domain
              • iOS Application
            • Google Pay
            • PayPal
          • Pay Later
          • Banks
            • Bank Debits
            • Bank Redirects
            • Bank Transfers
            • Open Banking
          • Crypto
          • Test Credentials
        • Payment Links
          • Configurations
          • Create Payment Links
          • Secure Payment Links
          • Setup Custom Domain
        • Save a Payment Method
        • Manual Capture
        • Incremental Authorization
        • Tokenization & Card Vault
          • Network Tokenisation
        • Supported Payment Workflows
        • Co-badged Cards
        • Webhooks
      • Process Payouts
        • Getting Started with Payouts
        • Using Saved Payment Methods
        • Smart Router for Payouts
        • Smart Retries in Payout
        • Payout Links
      • Smart Routing
        • Rule Based Routing
        • Volume Based Routing
        • Default Fallback Routing
      • Smart Retries
        • 3DS Step-up Retries
      • 3DS / Strong Customer Authentication
        • Setting up 3DS Decision Manager
        • Native 3DS Authentication
        • External Authentication for 3DS
      • Fraud & Risk Management
        • Activating FRM in Hyperswitch
        • Fraud Blocklist
      • Subscriptions
        • PG Agnostic Card Forwarding
        • Zero Amount Authorization
      • Split Payments
        • Stripe Split Payments
        • Adyen Split Payments
        • Xendit Split Payments
    • Checkout Experience
      • Customizable and Native Integrations
        • Web
          • Node And React
          • Customization
          • Error Codes
          • Node and HTML
          • Vanilla JS and REST API Integration
        • Android
          • Kotlin with Node Backend
          • Customization
          • Features
        • iOS
          • Swift with Node Backend
          • Customization
          • Features
        • React Native
          • React Native with Node Backend
          • Card Widget
          • Customization
        • Flutter
          • Flutter with Node Backend
          • Customization
        • Headless SDK
        • Server Setup
      • Click To Pay
        • Visa Click to Pay: V1 to V2 Migration
      • Payment Methods Management
    • Payment Operations
      • Managing Accounts and Profiles
        • ⚙️Control Centre Account setup
        • Hyperswitch Account Structure
      • Manage Your Team
      • Analytics & operations
        • Exporting payments data
      • Disputes / Chargebacks
      • Surcharge
        • Surcharge Setup guide
      • Multi-Tenancy
      • Data migration
        • Import data to Hyperswitch
        • Export data from Hyperswitch
    • Security and Compliance
      • PCI Compliance
      • Data Security
      • GDPR compliance
      • Identity and Access Management
    • E-commerce Platform Plugins by Hyperswitch
      • 🔌WooCommerce Plugin
        • Setup
        • Roadmap
        • Compatibility
        • FAQs
      • Saleor App
        • Setup
      • Automatic Tax calculation for Express Checkout wallets
  • Hyperswitch open source
    • Overview
      • Run Hyperswitch Locally Using Docker
        • Run Additional Services
      • Development Environment Setup
        • Backend
          • Configure and Run the Application
          • Try out APIs
        • SDK (Frontend)
        • Control Center
    • Deploy on AWS
      • Deploy on AWS using CloudFormation
      • Component-wise Deployment
        • Deploy app server
        • Deploy Control Center
        • Deploy web client
          • Production ready deployment
          • Integrate web client on your web app
          • Playground deployment for prototyping (optional)
        • Deploy Card Vault
          • Production ready deployment on AWS
          • Cloud setup guide
    • Deploy on Kubernetes
      • Deploy on GCP Using Helm Charts
      • Deploy on Azure Using Helm Charts
    • Exploration Guide
    • Account setup
      • Using Hyperswitch Control Center
      • Test a payment
      • Using postman
    • Troubleshooting
  • Testing Payments
  • Check list for Production
    • Going live
      • For SaaS Setup
      • For On-Prem Setup
        • Monitoring
        • PCI compliance
          • Get started
          • Completing the SAQ
        • Data Security
        • Updates
  • Learn more
    • API Reference
    • Connectors Supported
    • SDK Reference
      • React
      • JS
      • Custom Events
    • Hyperswitch architecture
      • Router
      • Storage
      • A Payments Switch with virtually zero overhead
    • Payment flows
    • Blog
  • Community Guidelines
Powered by GitBook

Compliance

  • Vulnerability Disclosure
  • PCI DSS 4.0
  • ISO 27001:2022

Community

  • Slack
  • Discord
  • GitHub Discussion
On this page
  • Handling Sensitive Data
  • 1. Accepting Card Data
  • 2. Storing Card Data (vaulting)
  • 3. Using Card Data for Analytics and Payment Operations
  • Data Encryption Overview
  • Key Management System (KMS) Encryption
  • Merchant-Specific Encryption
  • Data Encryption for each Merchant account
  • Concealing Sensitive Data in Logs

Was this helpful?

  1. Check list for Production
  2. Going live
  3. For On-Prem Setup

Data Security

Comprehensive measures safeguarding Data Integrity within Hyperswitch

Last updated 1 year ago

Was this helpful?

In this chapter, you will learn about the security principles employed in the design on the Hyperswitch application

Hyperswitch is engineered with a meticulous focus on safeguarding sensitive data aligning with PCI standards. The application employs a multi-layered encryption strategy that encompasses various stages of data handling.

The below sections highlight how Hyperswitch handles sensitive data such as master key, database passwords, RSA certificates, external API credentials and customer Personally Identifiable Information (PII).

Handling Sensitive Data

The Hyperswitch application employs multiple layers of encryption to safeguard sensitive card information during transmission between components as explained below. Our security framework is designed to meet PCI standards, ensuring maximum protection and confidentiality for all card-related data.

1. Accepting Card Data

Card information initially comes from the Hyperswitch SDK, where it's encrypted using the SSL/TLS protocol. This establishes end-to-end encryption between the SDK and the Hyperswitch backend.

2. Storing Card Data (vaulting)

When a payment is made using a saved card, the card details get stored in a secure storage system called the Hyperswitch Card Vault. The Hyperswitch App Server utilizes JWS and JWE to secure card data during its transmission to our Card Vault service, which is then decrypted and verified by Card Vault. The transfer and validation of this data involve a few steps:

Card Data Preparation: The card details undergo two important security measures:

  • They're signed using the private key of the hyperswitch app server to ensure the integrity of the data.

  • Then, the details are encrypted using the public key of the locker, ensuring their confidentiality during transmission.

Data Storage Process:

  • The card vault, after receiving the validated and encrypted data, further secures it by internally applying AES encryption.

  • Finally, the data, now doubly encrypted, is stored in the database, ensuring an added layer of security for the stored information.

3. Using Card Data for Analytics and Payment Operations

To provide transaction information and analytics, only partially masked card details (first 4 and last 4 digits) are sent to the Control Center from the Hyperswitch app server. This allows a high-level view of payments without revealing full customer information.

Data Encryption Overview

The application places a high priority on safeguarding sensitive information tied to external API credentials, customers, and card details and uses multi-layered encryption for the same.

During transmission, data remains masked and never gets permanently stored on the local system, ensuring added security.

Key Management System (KMS) Encryption

The current Hyperswitch setup only uses AWS KMS for storing and managing sensitive data and configurations. Support will be added for other 3rd party vault solutions (e.g., Hashicorp Vault) in the future.

  • Sensitive keys crucial for the application's operation undergo encryption at startup.

  • These encrypted keys are then stored securely in environment variables or configuration files using AWS's KMS service.

  • Examples of encrypted values include the master key, database passwords, and RSA certificates, ensuring their confidentiality.

Merchant-Specific Encryption

  • Each merchant account is assigned a unique data encryption key generated internally and stored securely.

  • This merchant-specific key undergoes encryption using AES-256 symmetric encryption via the master key, further securing it.

Data Encryption for each Merchant account

  • Data pertinent to individual merchant accounts, such as connector API keys, confidential merchant information, and any Personally Identifiable Information (PII) of customers, is encrypted using the same encryption method.

  • However, this encryption process utilizes the unique data encryption key specific to that particular merchant, ensuring that each set of data remains protected and accessible only to authorized parties associated with that merchant.

  • By employing a multi-layered encryption approach involving KMS encryption for critical keys, unique encryption keys for each merchant, and data-specific encryption, the application ensures robust security measures are in place to safeguard sensitive information at various levels.

Concealing Sensitive Data in Logs

  • For masking sensitive data, the application framework is designed with a wrapper type that categorizes all sensitive data as Secret.

  • This approach capitalizes on the advantages of Rust - a strongly typed language. Creating a wrapper type like Secret<T> offers a robust way to handle sensitive data.

  • Instead of logging the actual sensitive content, such as passwords or personal information, this approach logs the data type itself (e.g., *** alloc::string::String ***).

  • This practice of masking the data at source ensures that sensitive information remains protected and prevents inadvertent exposure in logs or debug outputs.

Database at rest Encryption

In the cloud-hosted version of Hyperswitch, we've encrypted the DB instances to offer an added layer of security, safeguarding the data from unauthorized access. For merchants self-hosting Hyperswitch, we highly recommend adopting similar practices to ensure robust protection for their data.

For more details on how the locker internally handles the encryption and decryption you can visit the Github repository

juspay/hyperswitch-card-vault