Opening Payment Page in a modal window

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.

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 available at https://paymentpage.ecommpay.com/shared/merchant.css.

   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. Define the events that will trigger the opening of the payment form (for example, the purchase button click).
3. Set up the payment form to open upon the required events by using your in house-solutions or the JavaScript library from ecommpay available at https://paymentpage.ecommpay.com/shared/merchant.js.

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: Parameters for opening payment form and Signature generation and verification.

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.

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 object can be made according to and complying with the following general conditions is 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 <pay_button_id> 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. 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: Parameters for opening payment form and Signature generation and verification.

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 (details).

   The information about such handler functions is provided in the article Handling customer behaviour events on Payment Page.

EPayWidget.bind('<pay_button_id>', configObj, method);

EPayWidget.run(configObj, method);

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')

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.

<html>
<head>
<!-- Adding ecommpay libraries -->
  <link rel="stylesheet" href="https://paymentpage.ecommpay.com/shared/merchant.css">
  <script src="https://paymentpage.ecommpay.com/shared/merchant.js"></script>
  <script type="text/javascript">var EP_HOST = 'https://paymentpage.ecommpay.com';</script>
<!-- Other parts -->
</head>
<body>
  <!-- JS command to open Payment Page -->
  <script type="text/javascript">
      EPayWidget.run({ project_id: 42,
                       customer_id: '17008',
                       payment_id: '18641868',
                       payment_amount: 8855,
                       payment_currency: 'USD',
                       signature: 'YWb6Z20ByxpQ30hfTI' });
  </script>
  <!-- Other parts -->
</body>
</html>

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.

When the payment form opens in a modal window and the customer is redirected to third-party services, the window size is automatically adjusted to the size of the displayed pages. Along with that, it is possible to specify the desired dimensions of the third-party services pages—with such customisation, the specified size is used unless the pages 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:

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 the height (redirect_window_height) and width (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), according to the structure in the example that follows.

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.