Payment Page Security
Our payment pages are designed with multiple layers of security to protect sensitive cardholder data. This section explains how these protections work and why they keep your customers' information safe, even in challenging security scenarios.
Overview
When customers enter their payment information on Hyp-hosted payment pages, they're protected by a comprehensive security architecture that includes browser-level protections, input validation, and advanced encryption techniques. Understanding these protections can help you feel confident about the security of your payment processing.
Customization security: CSS vs JavaScript
What you can customize
We allow merchants to inject CSS only into the payment page to customize the appearance according to business needs. This lets you maintain your brand identity while keeping security intact.
Why we don't allow custom JavaScript
We specifically prevent JavaScript injection for security reasons:
JavaScript can access sensitive data like credit card numbers
Malicious scripts could steal information or manipulate the payment process
CSS-only customization provides styling flexibility without security risks
How we protect against injection
Our payment pages protect themselves through multiple mechanisms:
Browser-level policies that are automatically enforced
Input validation and sanitization for all data that enters the page
Content security policy (CSP) headers that prevent unauthorized script execution
Iframe security: built-in browser protection
When you embed our payment page using an iframe, you gain both seamless integration and robust security. The iframe lets you embed the payment form directly into your checkout flow while maintaining strict security boundaries.
Same origin policy protection
The browser's same origin policy creates a security barrier that prevents:
Code running outside the iframe from accessing data inside the iframe
Your website's scripts from reading credit card numbers or other sensitive information
External scripts from manipulating the payment form or stealing data
This means that even if your website has vulnerabilities, the payment data inside our iframe remains protected.
Why this matters for you
Seamless user experience – customers never leave your website
Automatic security – browser-level protection that doesn't require additional coding
PCI compliance benefits – sensitive data never touches your servers
Browser protection against compromised host sites
Even if the website hosting our payment iframe has security vulnerabilities, the payment page remains secure. Here's why:
Multiple layers of defense
Same origin policy prevents cross-frame data access
Content security policy blocks unauthorized script execution
Secure iframe attributes provide additional protections (note: clickjacking prevention requires the merchant page to implement CSP frame-src directives in the page hosting the Hyp iframe)
HTTPS enforcement ensures encrypted communication
Real-world attack scenarios
Even in these challenging situations, your customers stay protected:
If your site has XSS vulnerabilities – attackers can't access payment data in our iframe
If malicious scripts are injected – they can't cross the iframe boundary
If your site is compromised – payment information remains isolated and secure
Frame-ancestors: controlling where your payment page can load
What is frame-ancestors?
Frame-ancestors is a content security policy directive that controls which domains are allowed to embed our payment page in an iframe. Think of it as a whitelist that determines where your payment form can safely appear.
How it works
When our payment page loads in an iframe, it:
Checks the parent domain – identifies which website is trying to embed it
Compares against your approved list – verifies the domain is on your whitelist
Allows or blocks loading – only displays if the domain is authorized
Why this is required
Frame-ancestors protection prevents several types of attacks:
Clickjacking attacks – prevents malicious sites from embedding your payment page
Unauthorized embedding – stops fraudsters from using your payment form on fake sites
Domain spoofing – ensures your payment page only appears on legitimate domains
Setting up frame-ancestors
The domain list is defined within the frameAncestorURLs property inside the ppsJSONConfig object in your initial payment page setup request.
What you need to do:
Add your domains to the approved list during integration setup
Include all subdomains where you'll embed the payment page
Update the list when you add new domains or change your site structure
For detailed implementation instructions, see Add paymentPageData to your payment page request.
SSL pinning: extra protection against advanced attacks
What is SSL pinning?
SSL pinning is an advanced security technique where our payment page encrypts credit card information and other personally identifiable information (PII) with a specific public key before sending it to our servers. This creates an additional layer of protection beyond standard HTTPS encryption.
How it protects you
Even if an attacker carries out sophisticated attacks, your customers' data remains secure:
Protection against man-in-the-middle (MITM) attacks
Standard HTTPS encrypts data between the browser and server
SSL pinning adds another layer – data is encrypted again with our specific key
Even if HTTPS is compromised – attackers still can't read the payment data
Defense against SSL stripping
SSL stripping is an attack where malicious actors:
Intercept HTTPS connections and downgrade them to HTTP
Present fake certificates to make connections appear secure
Steal data that users think is encrypted but actually isn't
Here's how SSL pinning stops this:
Pre-encryption happens in the browser before any network transmission
Specific key validation ensures we're talking to the real Hyp servers
Data remains encrypted even if the transport layer is compromised
Why this matters
Defense in depth – multiple layers of encryption protect your customers
Advanced threat protection – guards against sophisticated attack techniques
Future-proofing – protection against new attack methods as they emerge
Security best practices for your web checkout
While our payment pages provide comprehensive security, you can enhance protection by securing your checkout environment:
Web checkout security
Use HTTPS everywhere – especially for all payment-related pages
Validate return URLs – enforce strict origin policies for payment redirects
Prevent tampering – protect against DOM manipulation and HTTP header tampering
Implement Subresource Integrity (SRI) – ensures scripts haven't been tampered with
Content security policy (CSP) configuration
Implementing a proper content security policy helps prevent client-side attacks and ensures iframe security:
Required CSP directive for iframe integration: Set the frame-src directive to only allow embedding iframes from Hyp CreditGuard's domains:
Why this matters:
Prevents injection attacks – blocks unauthorized iframe sources
Ensures legitimate iframe loading – only allows payment pages from verified Hyp domains
Complements frame-ancestors protection – works together with our server-side controls
Reduces attack surface – limits potential sources of malicious content
Additional CSP recommendations:
Combine with other CSP directives for comprehensive protection
Test your CSP configuration thoroughly before deploying to production
Monitor CSP violation reports to detect potential security issues
Integration security
Validate iframe sources – ensure payment iframes are loading from legitimate Hyp domains
Monitor for unexpected redirects – watch for signs of payment flow manipulation
Implement proper error handling – avoid exposing sensitive information in error messages
Use secure session management – protect customer sessions throughout the payment process
Ongoing security maintenance
Keep systems updated – regularly patch operating systems and applications
Run security assessments – perform vulnerability scans on a regular schedule
Monitor for threats – watch for suspicious activity across your endpoints
Enable strong customer authentication – use 3D Secure/PSD2 SCA where applicable to reduce fraud
Related documentation
For more information about security implementation, see:
Our multi-layered security approach ensures that your customers' payment information is protected at every stage of the process. If you have questions about these security features or need assistance with implementation, our information security team is here to help.
Last updated
Was this helpful?