# Payment Page Security When your customers enter their payment info on our hosted payment pages, they're protected by a multi-layered security setup that works right in their browser. This page walks you through the different ways we keep that data safe — from built-in browser protections to advanced encryption — so you can feel confident about your payment processing. ## HTTPS enforcement Everything sent between your customer's browser and Hyp Pay is encrypted using **TLS 1.2 or higher**. This helps to: * **Stop "man-in-the-middle" attacks** by making sure data can't be intercepted or changed while it's traveling. * **Keep data private**, ensuring that cardholder info and customer details stay between the customer and our secure servers. ## Preventing injections Our payment pages are built to stay secure by making sure no unauthorized code can run on the page. This means that even if someone tries to interfere, your customers' data stays right where it belongs. We're very strict about not allowing any JavaScript or custom code injection for a few important reasons: * **JavaScript can "see" everything** on a page, including sensitive credit card numbers. * **Malicious scripts could steal info** or try to mess with the payment process. * **Strict isolation** ensures that the payment form always works exactly as we designed it, with all security controls locked in place. To keep things safe, our payment pages protect themselves using several different layers: * **Browser-level policies** that are automatically enforced by the user's browser. * **Input validation and sanitization** for every piece of data that enters the page. * **Content security policy (CSP)** headers that tell the browser to block any unauthorized scripts from running. ## Bot and fraud protection To keep your business and your customers safe from automated attacks, our payment pages have built-in bot detection and fraud prevention. We use **Google reCAPTCHA v2** to tell the difference between real customers and malicious bots. This protection runs quietly in the background, so it won't get in the way of a legitimate customer's checkout experience. The system creates a fresh security token every 90 seconds to make sure every transaction is verified in real-time. This built-in protection helps you by: * **Stopping "carding" attacks** where bots try to test thousands of stolen card numbers. * **Cutting down on fraud** by blocking automated scripts. * **Saving server resources** from being hit by a flood of bot traffic. ## Session and transaction integrity Every payment session is protected by a unique, encrypted transaction token called `SecTrans`. When a payment page is created, our server generates a `SecTrans` token that's tied to that specific transaction. This token is passed as a hidden field in the payment form and must be there when the form is submitted. Using a transaction token like this gives you a few big benefits: * **It prevents form tampering** by making sure the transaction details haven't been changed in the browser. * **It stops replay attacks** by ensuring each payment session can only be used once. * **It links the payment to your request**, so you can be sure the funds are correctly assigned to your account. ## Iframe security: protection from the host site If you decide to embed our payment page using an **iframe**, you get a seamless checkout experience along with some very robust security. The iframe lets you keep customers on your site while maintaining a hard security boundary between your site and the payment form. The browser's **same origin policy** creates a solid barrier that stops: * **Code outside the iframe** from reaching into the iframe to see what's happening. * **Your website's own scripts** from reading credit card numbers. * **External scripts** from messing with the payment form or stealing data. This means that even if your website has its own security gaps — like an **XSS vulnerability** or a malicious script — the payment data inside our iframe stays isolated and protected. Even in a worst-case scenario where your entire site is compromised, your customers' info stays safe and sound inside the iframe's boundary. ## Security best practices for your integration While our payment pages handle the heavy lifting, you're responsible for keeping your own website and API integration secure. We've put together a list of [security practices](/pay/getting-started/authentication-security.md#security-practices) you should follow to keep your customers' data safe. This includes things like always using HTTPS, setting up a Content Security Policy (CSP), and storing your API credentials securely. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developers.hyp.co.il/pay/security/payment-page-security.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.