Opening Payment Page in an iframe element of an HTML page
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.
For opening the payment form in an iframe element, the following should be performed on the web service side:
-
Link the CSS library from ecommpay on the client side of the web service. The library is 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. The library is available at
https://paymentpage.ecommpay.com/shared/merchant.css
. - Define the events that will trigger the opening of the payment form (for example, the purchase button click).
- 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
.
Opening Payment Page 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: Parameters for opening payment form and Signature generation and verification.
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.
Opening Payment Page via the ecommpay 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).
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:
To open Payment Page in an iframe element with the help of the JavaScript library merchant.js
from ecommpay, link this library and use the corresponding calls to the EPayWidget
object. These calls, among other parameters in the configObj
object, must contain the target_element
parameter with the iframe element identifier. Apart from this, the following general conditions should be met:
- 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.
- 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.
- 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. - 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.
When either of the methods (bind
and run
) is used, the HTML code of the web service page looks as follows.
Customising the size of third-party services' 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 below.
Note that the specified parameters are not applied when the pages of third-party services are opened in separate tabs.
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
andneteller-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.