Description of interaction methods

Payment by bank card for goods and services via the Internet can be carried out with
the transfer of full card details to the payment gateway, using bindings as
well as using external payment systems.

Payment mechanism (one-phase and two-phase)

The store can use a one-stage or two-stage payment acceptance mechanism.

• One-phase payment is an operation to pay for goods/services made via the Internet using bank cards that does not require additional confirmation (one request initiates blocking and debiting funds from the card immediately).
• Two-phase payment is an operation to pay for goods/services made via the Internet using bank cards, requiring additional confirmation. The two-phase mechanism of operation enables to divide the process into checking the solvency of a bank card (authorization) and debiting funds (financial confirmation). The first request initiates checking the solvency of the bank card and blocking funds on the client's account, the second request initiates debiting.

Patterns of interaction with the payment gateway

Various connection patterns are available to the store for integration with the payment gateway, depending on the mechanism (one-phase or two-phase) and the payment instrument. The current document describes the following connection patterns.

• The Single-phase payment with the indication of card data on the payment page section describes a scheme in which the client enters their card details on the payment page to pay for the order, from where the card data is transmitted to the gateway for one-phase payment.
• The Two-phase payment with the indication of card data on the payment page section describes a scheme in which the client enters their card details on the payment page to pay for the order, from where the card data is transmitted to the gateway for two-phase payment.
• The Payment using a binding on the payment page section describes a scheme in which the client's card is linked to the client ID in the store's system, which allows you to offer autofill of card data fields on the payment page for authorized users.
• The scheme described in the One-phase autopayments section assumes that the client makes the initial payment on the payment page with the consent to activate the Autopay service. After that, the store independently tracks the date when it is necessary to make the next payment, and initiates the payment without additional input of card data (without the participation of the client).
• The scheme described in the Two-phase autopayments section assumes that the client makes the initial payment on the payment page with the consent to activate the Autopay service. After that, the store independently tracks the date when it is necessary to make the next payment, and initiates the payment without additional input of card data (without the participation of the client).
• The Using Alfa-click to pay for an order section describes a payment pattern that is available only to clients of Alfa-Click online banking. With this scheme, the payment details are entered on the side of the external PayByClick system.
• The Using UPOP to pay for an order section describes a payment scheme that is only available to China UnionPay cardholders. With this scheme, the payment details are entered on the side of the external China UnionPay system.
• The Payment using Apple Pay section describes the payment scheme available to owners of Apple mobile devices through the Apple Pay system.
• The Payment using Samsung Pay section describes the payment scheme available to owners of Samsung mobile devices through the Samsung Pay system.
• The Payment using Google Pay section describes the payment scheme available to owners of Android mobile devices through the Google Pay system.

• The Free Amount Payment section describes the payment scenario using the free amount payment page placed in the payment gateway.
  Depending on the interaction scheme used by the store, you need to use a specific set of requests. In the scenarios descriptions listed above, it is indicated at which step of the scenario which request should be used, and also a link to the section with the request specification is given.
  Possible interfaces for interaction with the payment gateway are presented in the next section.
  

Interfaces for interaction with the payment gateway

The store can use one of the interfaces to interact with the payment gateway – the interface on the WebServices or REST.
To authorize the store's access to the payment gateway system, any request from the store must contain the store's name and password received when registering the store in the system. Detailed information about the authorization of requests is provided below.

Implementation of interaction through the Web-Service interface
Description (WSDL) of the service is located on the test server, which is available without restrictions.
The name and password values are passed in the format described in the WS-Security specification, userName token authorization type. The header with such authorization will look something like this (see below).

        <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-
secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-
%20wssecurity-utility-1.0.xsd"> 
    <wsse:UsernameToken wsu:Id="UsernameToken-87"> 
         <wsse:Username>aa</wsse:Username> 
         <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-
          token-profile-1.0#PasswordText">123456</wsse:Password> 
    </wsse:UsernameToken> 
 </wsse:Security>
    

If errorCode = 0, in the response to the request, it means that the request was processed by the payment gateway without system errors. At the same time, errorCode does not display the order status.
To get the order status, use the getOrderStatus or getOrderStatusExtended request (one of these methods must be implemented when integrating the RSO with the payment gateway).

Implementation of interaction through the REST interface
Interaction is implemented as HTTP requests by the POST method to certain URLs.
The result of processing the request is returned as a JSON object. For example: {"errorCode":"12","errorMessage":"Empty amount"}
The name and password values are passed in the following parameters (see the table below).

All text fields must be Unicode (UTF-8) encoded.
Special characters in the REST request must be escaped according to the URL code. The symbol table is located at the following address: https://wm-school.ru/html/html_url_acsii.html. For example, the password qwe?rt%y should be passed as qwe%0Frt%25y.
If errorCode = 0 in the response to the request, it means that the request was processed by the payment gateway without system errors. At the same time, errorCode does not display the order status.
To get the order status, use the getOrderStatus.do or getOrderStatusExtende.do request (one of these methods must be implemented when integrating the RSO with the payment gateway).

Connection coordinates

When registering a store, a representative is provided with a login/password pair, which should be used in the protocols.
The description of the test service (WSDL) is located at:
https://tws.egopay.ru/api/ab/webservices/merchant-ws?wsdl

The description of the test service (WSDL) for the FPS is located at:
https://tws.egopay.ru/api/ab/webservices/sbpc2b-ws?wsdl

URL for accessing REST methods: