# Opening Payment Page in a modal window {#en_PP_method_ModalWindow .concept} An article about opening Payment Page in a modal window 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_modal_overview} When opened in a modal window, the Payment Page payment form is displayed to the customer over the merchant's web service page.This interrupts the customer's interaction with the web service but keeps them engaged and focuses the customer's attention on the purchase without redirecting them to another page. ![](images/ecommpay/en_pp_general_2.svg) For opening the payment form in a modal window, 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. This 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 a modal window, 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_modal_via_in_house_solutions} To open Payment Page in a modal window 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_modal_via_javascript_library} To open Payment Page in a modal window 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. Since this option to open the payment form is the default one for the `merchant.js` library,no special parameters are required in the calls to the `EPayWidget` objectand complying with the following general conditionsis enough: 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 { 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( { 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_modal_customisation} When the payment form opens in a modal window and the customer is redirected to third-party services—such as the services of banks, payment systems, and providers—the window size is automatically adjusted to the size of the displayed pages. Along with that, it is possible to customise the size the services' pages for various cases \(with regard to the size of the screens of customers' devices, as well\) by specifying the desired dimensions. With such customisation, the pages of third-party services are displayed with the specified dimensions unless they are opened as separate HTML pages. 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 that follows. ``` {#codeblock_wyz_vyr_pyb .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.