# Opening Payment Page in an iframe element of an HTML page {#en_PP_method_Embedded .concept} An article about opening Payment Page in an iframe element with the use of the JavaScript library from Ecommpay and in-house solutions. **Parent topic:**[Options for opening Payment Page](en_PP_Integration.md) ## Overview {#en_pp_opening_iframe_overview} When opened in an iframe element, the Payment Page payment form is embedded in the merchant's web service HTML page.This option may not necessarily focus the customer's attention on the purchase but keeps the customer in the context of the web service, without interrupting their interaction with it and redirecting them to a different page. ![](images/ecommpay/en_pp_general_1.svg) **Note:** For the payment form to be displayed correctly, the minimum dimensions of the iframe element should be 320 and 600 pixels in width and height accordingly—if smaller dimensions are specified, the form does not fit into the element. For responsive display on desktop computers, the minimum width of the element should be 480 pixels. The restrictions on the maximum size are not imposed. For opening the payment form in an iframe element, the following should be performed on the web service side: 1. Link the CSS library from Ecommpay on the client side of the web service for the payment form to be displayed correctly. The library is available at `https://paymentpage.ecommpay.com/shared/merchant.css`. 2. Configure the Content Security Policy by specifying the source URLs required for the correct operation of the payment form in the `Content-Security-Policy` HTTP header \([details](en_pp_interaction_organisation.md#section_jth_vnh_qjc)\). ``` {#codeblock_ejr_n4k_mjc} Content-Security-Policy: script-src https://paymentpage.ecommpay.com https://applepay.cdn-apple.com; style-src https://paymentpage.ecommpay.com; img-src https://applepay.cdn-apple.com; frame-src https://paymentpage.ecommpay.com https://applepay.cdn-apple.com ``` 3. Define the events that will trigger the opening of the payment form\(for example, the purchase button click\). 4. Set up the payment form to open upon the required eventsby using your in house-solutions or the JavaScript library from Ecommpay available at `https://paymentpage.ecommpay.com/shared/merchant.js`. **Warning:** Keep in mind that to ensure correct behaviour of the payment form, you must link the Ecommpay CSS library via the CDN \(Content Delivery Network\). Storing this library locally is not allowed. When processing Apple Pay payments via Payment Page with the option to open the payment form in an iframe element, register your merchant domains with the Apple Pay service \([learn more](en_dbl_projects.md)\). ## Opening Payment Page via in-house solutions {#en_pp_opening_iframe_via_in_house_solutions} To open Payment Page in an iframe element with the help of the merchant's in-house solutions, prepare the corresponding script that will ensure the payment form opening with the required parameters specified and signed. The information about the parameters that can be used to open Payment Page and about the signature generation is provided in the following articles: [Payment Page API specification](en_PP_Parameters.md) and [Signature generation and verification](en_platform_signature.md). ## Opening Payment Page via the Ecommpay JavaScript library {#en_pp_opening_iframe_via_javascript_library} To open Payment Page in an iframe element with the help of the JavaScript library `merchant.js` from Ecommpay, link this library on the client side of the web service and use the corresponding calls to the `EPayWidget` object. In these calls, the identifier of the iframe element must be specified in the `target_element` parameter of the `configObj` object. Without this parameter, the payment form opens either in a modal window or as a separate HTML page \(if this has been set up via the `redirect` or `redirect_on_mobile` parameters\). **Note:** If the request for opening the payment form contains the parameters to open Payment Page in a separate tab and in an iframe element, opening the form in a separate tab is given the priority. Apart from these aspects, in case of opening the form in an iframe element via the `EPayWidget` object, the work with this object is carried out according to the following general conditions that are also relevant for other options to open the payment form: 1. Each call can be made via one of the two methods: - `bind` \(`EPayWidget.bind`\)—if the payment form should be opened with a button click \(with the button identifier `` specified\). - `run` \(`EPayWidget.run`\)—if the payment form should be opened upon any other event in the user interface. 2. Each call must contain the JavaScript object `configObj`with the parameters of the payment form opening and the signature for these parameters. The information about the parameters used and signature generation is provided in the following articles: [Payment Page API specification](en_PP_Parameters.md) and [Signature generation and verification](en_platform_signature.md). 3. If necessary, any call can also contain an HTTP request method \(`method`\)—POST or GET. If nothing is specified, the GET method is used by default. 4. Additionally, any call can contain functions to handle the information about customer's actions. The information about such handler functions is provided in the article [Handling events in Payment Page](en_pp_ui_monitoring.md). ```language-javascript EPayWidget.bind('', configObj, method); EPayWidget.run(configObj, method); ``` ```language-json EPayWidget.bind('pay_button_id', // Button identifier { target_element: 'widget-container', // Element identifier project_id: 42, // Project identifier customer_id: '17008', // Customer identifier payment_id: '18641868', // Payment identifier payment_amount: 8855, // Payment amount payment_currency: 'USD', // Payment currency code signature: 'YWb6Z20ByxpQ30hfTI' }, // Signature 'post') ``` ```language-json EPayWidget.run( { target_element: 'widget-container', // Element identifier project_id: 42, // Project identifier customer_id: '17008', // Customer identifier payment_id: '18641868', // Payment identifier payment_amount: 8855, // Payment amount payment_currency: 'USD', // Payment currency code signature: 'YWb6Z20ByxpQ30hfTI' }, // Signature 'post') ``` When either of the methods \(`bind` and `run`\) is used, the HTML code of the web service page looks as follows. ```language-xml
...
``` ## Customising the size of third-party services' pages {#en_pp_opening_iframe_customisation} To set up the dimensions of the pages used for customer redirection to third-party services, the request for opening the payment form should contain the `payment_methods_options` parameter with the required values of height and width of such pages. These values are defined as `redirect_window_height` and `redirect_window_width`. These parameters can be specified as follows: - Directly in the `payment_methods_options` parameter, for all third-party services unless specified otherwise. - As the parameters for separate payment methods, which are specified via the codes \(from [the reference](en_pm_codes.md)\), according to the structure in the example below. Note that the specified parameters are not applied when the pages of third-party services are opened in separate tabs. ```language-json payment_methods_options:"{ "redirect_window_height":1200, "redirect_window_width":1200, "card":\{"redirect\_window\_height":600, "redirect\_window\_width":900\}, "neteller-wallet":\{"redirect\_window\_height":900, "redirect\_window\_width":1200\} \}" ``` In the provided example, you can see the dimensions that should be used for all third-party services by default and the dimensions for separate payment methods. These dimensions are applied as follows: - For all methods except `card`and `neteller-wallet`, the height and width are 1200 pixels each. - For the `card` method, the height and width are 600 and 900 pixels accordingly. - For the `neteller-wallet` method, the height and width are 900 and 1200 accordingly.