Payment Page is a payment form by ecommpay: it is a flexibly configured software module with user interface designed to process payments and perform other actions involving various payment methods. Payment Page can be used in web services and mobile applications and allows processing card payments even if the merchant does not have the PCI DSS compliance certificate.

Payment Page is opened via the API, and the merchant can use the API itself or special components that can facilitate its usage: a pluggable JavaScript library, SDK for projects developed in various programming languages, and plug-ins for websites based on a range of the widely used CMS. This diversity of techniques allows efficiently configuring Payment Page for very different projects.

Payment Page is opened on the customer's device as a separate browser tab, a modal window or an iframe object embedded into the HTML pagewith the standard or a customised design applied. Payment Page display mode, the way of handling intermediate actions and showing information about the result can be configured in the request for opening the payment form. Therefore, this variety of options allows efficiently configuring Payment Page for different user stories.

Figure: Payment Page displayed as an iframe object embedded into the HTML page

Figure: Payment Page displayed as a modal window

Figure: Payment Page displayed as a separate browser tab

This section contains the overview of capabilities of Payment Page and interaction process through it as well as the emulator showing its functioning in accordance with different scenarios.

Interaction model

When Payment Page is used, all interactions between the payment platform, on the one side, and, on the other side, the customer's device and the server side of the web service are handled with the use of HTTP, version 1.1 or higher, and TLS, version 1.2 or higher. Payment Page supports the latest versions of such browsers as Chrome, Safari, Opera, Firefox, Microsoft Edge, QQ, MIUI, Samsung Internet, 360 and others. For more detailed information about using Payment Page in different technical environments, contact the ecommpay technical support (support@ecommpay.com).

In terms of the interaction diagram, the customer, the front end and the back end of the web service, the payment platform, Payment Page and the payment environment are all seen as separate parts.

Figure: Interaction diagram

Generally interaction process through Payment Page is handled as follows:

  1. In the user interface of the web service the customer invokes the payment form by clicking payment button or using some other pre-configured method of invoking the payment form.
  2. A set of Payment Page invocation parameters is formed on the client side and then transferred to the server side.
  3. On the server side verification and addition of the parameters are performed if needed. The signature for the final set of parameters is formed, and after that the signed data is transferred back to the client side. It is the final set of the parameters that must be signed, containing all parameters required by the API and information about preferred way of opening the payment form; otherwise the request will be incorrect.
  4. On the client side request for opening Payment Page is generated and sent to the payment platform.
  5. On the side of the payment platform Payment Page is configured in accordance with the Payment Page invocation parameters. The data is transferred to the customer's device for the payment form to be opened.
  6. The payment form is displayed in the user interface.
  7. The customer makes necessary steps on the payment form: selects the payment method (if it is not specified in the request for opening the payment form), enters payment information and other requested details and confirms payment or another operation (for instance, card verification).
  8. A request to perform the required action including all data specified by the customer is sent from Payment Page to the payment platform.
  9. In the payment platform the payment is registered and all technical activities are performed, including transferring the required data to providers and payment systems.
  10. In the payment environment the required systems process the payment, and information about the payment result is transferred to the payment platform.
  11. The information about the result is processed in the payment platform, and a callback is sent to the URL specified by the merchant (the same is true for other interfaces of the payment platform as well).
  12. Information about the result is transferred from the payment platform to Payment Page.
  13. Information about the result is displayed in the user interface on Payment Page itself or on the page to which the customer is redirected, according to the configuration.

The diagram shows the key points of interaction process through Payment Page on the side of the merchant. However, in particular cases intermediate actions among the customer, Payment Page, the payment platform and the payment environment (steps 7–10) can be different. For instance, during 3‑D Secure authentication or payment processing confirmation in alternative payment system, additional steps may be required, or if Payment Page is used for saving payment data, the payment is not registered (step 9) and step 10 is omitted. The variety of options taking place on steps 7–10 can affect user stories, and, on the one hand, no additional actions are required on the side of the web service when these steps are performed; on the other hand, the set of parameters that is formed on steps 2–3 can significantly affect the subsequent user story. In order to meet the needs of a specific project, it is possible to use Payment Page capabilities described below and configure the required scenario in cooperation with the ecommpay technical support.

The basic usage scenario is the following:
  1. The customer selects the option to make a purchase, opens Payment Page, and selects the payment method.

    (Steps 1–6 and partially step 7 in the interaction diagram)

  2. The customer specifies the required payment data, confirms the purchase and waits for information about the result.

    (Steps 7–12 in the interaction diagram)

  3. The customer receives the information about the payment result.

    (Step 13 in the interaction diagram)

Technically, it is possible to use ecommpay components as well as technologies preferred by the merchant to open Payment Page and process program notifications. These ecommpay components are:

  • Pluggable JavaScript library. It is connected to the client side and supports various ways of opening Payment Page (step 4) and event processing in the user interface.
  • Software development kits (SDK) for web services developed in different programming languages.
  • Software development kits for mobile applications based on Android and iOS. They are connected to the client side of application and allow using payment platform which is compatible with mobile interfaces (support for steps 2 and 4 with no need for using browser on steps 6–13).
  • Plug-ins based on a range of the widely used CMS. They are enabled through administrative panel of the CMS and provide all necessary actions both in the client and in the server side with no need for programming by the merchant.

In addition to the described features, the merchant can monitor Payment Page functioning. By default, the merchant is not notified about the opening of Payment Page; however, this option can be configured. Using the ecommpay JavaScript library the merchant can collect and process information about the opening of Payment Page or about an error while opening Payment Page (if an error occurs), about confirmation of operation by the customer or about closing the payment form, and about other actions in the interface of the payment form. After operation is confirmed in Payment Page and the payment is registered in the payment platform, it is possible to obtain information about the payment status by sending a request through Gate and Dashboard.


Support for various required actions

Payment Page allows performing the following required actions:

  • Payment processing. Payment processing, especially processing one-step purchases, is the most common way of using the payment form. One-step purchase means that during one Payment Page session a one-time transfer of funds from the customer to the merchant is made; for instance, this option can be used for payment for an item of goods.
  • Authorization hold. When authorization hold is performed, in terms of one Payment Page session the payment amount is deducted from the customer's account, and after that the merchant can either charge the held amount or, alternatively, release the funds (using Gate, Dashboard, or automatically after a specific time lag). For instance, this option is relevant when the customer books a hotel or rents a car.
  • COF purchases registration. When building lasting customer relationships, it can be convenient to be able to process COF purchases without requiring the customer to enter payment information or make any steps at all (for instance, this is relevant for subscription payments). The payment platform supports COF purchases processing, and using Payment Page the merchant can register all types of COF purchases — regular payments, automatic payments and express payments (OneClick), by specifying correspondent parameters in the request for opening the payment form.
  • Payment instrument verification. This option is designed to verify the payment instrument (most commonly, payment card), for instance, for performing payouts to the customers. In terms of one Payment Page session the payment instrument is validated by either transferring a dummy (zero) amount from the customer to the merchant or by authorizing a specific amount (non-zero) on the customer's card or account and then voiding the transfer or the authorization.
  • Tokenization. During tokenization no payment operations, including transfer of dummy amount, are performed, but information about the payment instrument is registered, and a secure identifier (token) for the customer's payment instrument is created. Tokenization is applicable to payment cards and serves for saving customer's payment information, for instance, during customer's registration on the web service, and then using this payment information for facilitated processing of payments and payouts.

The required action is configured by specifying corresponding parameters in the request for opening the payment form and defines the way of using the payment form. For different scenarios various features are available, including entering and saving payment information, collecting additional information and using other options described below.

Support for different data input options

Payment Page supports various ways of selecting payment method and entering payment information.

Payment method can be selected as follows:

  • On the payment form, out of all available methods. This is the basic option which means that the customer selects the payment method out of all methods available for the merchant in terms of the project.
  • On the payment form, out of the specified methods. In some cases it may be necessary to show only some of all available payment methods. For instance, this option is especially convenient when specific regional features should be taken into account. The required payment methods are specified by using corresponding parameters in the request for opening the payment form, and the customer selects one of the methods from the defined list.
  • Outside the payment form, before the payment form is opened. Payment method can also be selected on the web service side before Payment Page is opened (for instance, in an “Add to Cart” section). In this case the payment method is specified in the request for opening the payment form, and user input starts from the step of entering the payment information, without selecting the payment method.

Payment information can be entered as follows:

  • On the payment form, by completing the fields. In this case the customer completes all the fields on the payment form.
  • On the payment form, with an option to use saved payment information. If the customer's identifier is specified in the request for opening the payment form, the customer can either choose one of the saved payment instruments or enter new payment information; the new payment instrument can also be saved for subsequent purchases.

    In addition to selecting payment instrument, for some payment instruments entering verification code is required (such as CVC, CVV or CID for card payments).

  • Outside the payment form, with an option to use saved payment information. In this case the customer selects specific card in the web service, the token of this card is specified in the request for opening the payment form, and, when the payment form is opened, it already contains all required payment information, except for verification code (CVC, CVV, CID) which the customer is required to enter on the payment form.

Along with these options that require the customer to complete the fields, Payment Page supports MO/TO payments which mean that the data is entered by merchant's employee. The type of the order (Mail Order/Telephone Order) is specified in the request for opening the payment form and affects the scenario of using the payment form.

Support for additional features

In addition to basic scenarios (with each of them containing an option to select payment method, enter payment information and perform other necessary steps), Payment Page also supports the following features:

  • Collection of additional information about the customer. Additional fields can be placed on the payment form in order to collect additional information about the customer, for instance, their address, telephone number and date of birth. The fields can be selected out of those available in the payment platform and can be marked as mandatory and optional for the customer to complete.
  • Additional attempts to enter payment information. If this option is used, in case of an error while performing required action the customer gets an error message (for instance, indicating insufficient funds) and has an option to repeat the attempt. After that, if the customer agrees to repeat the attempt, the customer can select a different or the same payment method with no need to enter the data that was filled in during the previous attempt.
  • Cascading. This feature resembles the option of making additional attempts to enter the payment information: if something goes wrong, the customer can repeat the attempt to process the payment. However, this feature is aimed at preventing errors that occur on the side of providers and payment systems and not as a result of incorrect data input. In this case, in accordance with the configurations, additional attempts to process the payment are performed through stand-by providers and payment systems.
  • Sending notifications to the customer. This option allows sending notifications about payment processing to the customer's email. It is possible to configure the content and format of the email messages and use different patterns for different types and statuses of the operations (this is especially relevant for success and decline statuses).

All these features are enabled and configured in cooperation with the ecommpay technical support by agreement with ecommpay Key Account Manager, which makes it possible to find and implement the best solution for every particular case.

Support for auxiliary procedures

In some cases payment processing may require auxiliary procedures, such as authentication on the issuer's side. Generally, the need for such procedures depends on protocols and rules of payment providers and payment systems, but in some cases merchant's preferences can also be taken into account (these preferences should be discussed with ecommpay Key Account Manager).

These auxiliary procedures do not require any additional actions on the merchant's side. However, it may be useful to know what features are available and if they require the customer to make any steps.

Payment Page supports the following auxiliary procedures:

  • 3‑D Secure authentication. 3‑D Secure (Three-Domain Secure) authentication is applied to card payment processing in order to prevent fraud.

    In terms of 3‑D Secure authentication, either the customer is transferred to the service of the issuer where the customer needs to complete authentication using the code received by SMS or performing other required steps, or loading page is displayed (while issuer confirms authentication with no customer effort required).

  • Authentication on merchant's request. This type of authentication is supported by some providers and, at merchant's option, can be used to replace 3‑D Secure authentication or in addition to it. For instance, authentication on merchant's request can be appropriate if authentication methods used by the issuer are not secure enough.

    In terms of authentication on merchant's request, an additional page is displayed and the customer needs to enter special verification code received by SMS or in a bank statement; this type of authentication involves a temporary hold of the agreed amount on the customer's account.

  • Address Verification Service check. Address Verification Service (AVS) check is aimed at providing additional anti-fraud protection during card payment processing. AVS check consists in matching the address specified by the customer during payment processing with the address specified for the cardholder on the side of the card issuer. Address Verification Service check is mandatory for payments committed in the UK and optional in the USA, Australia, Canada and New Zealand.

    To complete AVS check, the customer needs to specify their address and post code.

  • Providing additional payment information. This procedure allows processing payments when payment system or payment platform require additional data that otherwise is not required. This data may be needed due to particular regional requirements, additional anti-fraud check or other circumstances.

    When providing additional information is required, corresponding notification and fields to be completed are displayed on the payment form. The fields should be completed on the same page of the payment form, and once they are, the procedure continues in the ordinary way.

In case of any questions about auxiliary procedures check the corresponding section of documentation or contact the ecommpay technical support.

Support for different ways of displaying information about the result

The information about the payment processing result can be displayed on the payment form as well as in the merchant's web service.

  • When information is displayed on the payment form, standard final page of the payment form is used with a message saying that the action is completed (success status) or declined (declined status) and a button leading to the web service, if needed.
  • When information is displayed in the web service, the final page of the payment form is not used, and the customer is redirected to the merchant's web service to receive information about the result in any format at merchant's option.

The way of displaying information about the result can be configured by using corresponding parameters in the request for opening the payment form, and for redirecting the customer to the web service, either the default URLs or the URLs specified in the request for opening the payment form can be used. The URLs can be similar or different for success and decline statuses.

This diversity of options provides the required flexibility and allows showing different final pages for different required actions, regions, groups of customers when it is needed.

Monitoring payment form usage and required actions result

Payment Page user experience is monitored primarily by the ecommpay payment platform; however, it is also possible to monitor user experience on the merchant's side using the following features:

  • Monitoring the payment form events. Using ecommpay JavaScript libraries, the merchant can collect and process information about opening Payment Page or an error during this step (if an error occurs), about confirmation of the required action by the customer or closing the payment form, and about other payment form events.

    This feature allows to efficiently react to important payment form events on the client side. Thus, the customer can be asked about the reason of closing the payment form or additionally notified about the expiring time lag to enter the payment information. These monitoring options also provide the merchant with a basis for the further analysis of Payment Page user experience in different user stories.

  • Time limit for entering payment information. Specific time lag for the customer to enter the payment information can be configured at opening Payment Page. In this case the timer is displayed on the payment form, and if the customer does not confirm the required action during the configured time lag, an error message is displayed.

    This feature allows to avoid “freezing” of the opened payment form for a long or indefinite time and controlling delivery of services to the customer (for instance, this may be especially applicable to sale of tickets, goods and other events relevant during specific time).

  • Result monitoring. There are different features that allow the merchant to check the result of interaction process through Payment Page. These include:
    • Notifications that are sent automatically to the specified URLs upon result of performing required actions and contain detailed information about the result. With these notifications automatic monitoring can be handled on the server side.
    • Special requests that are sent to Gate API and Data API and allow receiving detailed information about specific payments and groups of payments when it is necessary on the web service side.
    • Features of Dashboard that allow monitoring and analysing the process by merchant's employees, including specific payments as well as common rates.

These features allow the merchant to monitor almost all aspects that can be important when the payment form is used.

Support for customisation

The visual appearance of Payment Page can be flexibly customised. It is possible to customise the following:

  • Payment form opening mode. Payment Page can be opened by clicking a button or using other interface events. To configure the mode of opening the payment form, the merchant can either use the pluggable ecommpay JavaScript library that contains the required methods, or configure required functions in the web service.
  • Payment form display mode. Payment Page can be displayed as follows:
    • as a separate browser tab
    • as a modal window
    • as an iframe object embedded into the HTML page

    The merchant can use the most appropriate option for specific type of device and user story by specifying the required option in the request for opening the payment form.

  • Options of redirecting the customer. Performing required actions sometimes involve redirecting the customer to the third-party services, for instance, in order to perform 3‑D Secure authentication or confirm payment processing on the payment system side. To perform redirection to the third-party service, a separate HTML-page (in a current or a new browser tab) or an iframe object embedded into the HTML page can be used. Redirection option is configured by the ecommpay technical support with consideration to merchant's preferences.
  • Template customisation options. Standard or customised design of the payment form can be used—depending on the needs and preferences of the merchant. To configure a customised version of the payment form, the merchant can use the Payment Page Designer. If there are any questions or suggestions regarding customisation that is beyond the scope of the designer, the merchant should contact their ecommpay account manager.
  • Language configuration of the payment form. The interface of Payment Page can be displayed in various languages. The required language can be specified in the request for opening the payment form. If this parameter is not specified, the payment form is displayed in the language selected automatically (by the browser language, by the region, or by default). In addition, it is possible to configure a drop-down list of languages and therefore give the customer an option to select the language of the payment form. This functionality is configured by the ecommpay technical support.

Configuration of all these features allows to efficiently incorporate Payment Page in almost any web service, thus highlighting its unique character.


This emulator demonstrates sample web service, Payment Page and third-party services (ACS) and the possible scenarios of using them when performing various targeted actions using payment cards. You can select different settings and compare different scenarios.

Note that the exact performance of the scenarios provided in the emulator (with accuracy to each character and detail) is not guaranteed in production. The purpose of these scenarios is to show Payment Page in general and the steps that may be required of the customer in different cases.


Cookies are required for the emulator to function properly. The emulator won't load without cookies.

The load time of the emulator may vary depending on communication channel, device and browser. The typical load time is 30–50 seconds. If the load time is much longer or if an error occurs, it is recommended to reload the page.